Skip to content
Frontfiles

Privacy Policy

Version 2.2, published 2026-10-23. It takes effect on 2026-11-07; until then, version 2.1 applies.

Every claim on this page describes the platform as it actually runs. Features that exist in code but are switched off are labelled as such, not omitted.

1. Who we are

Frontfiles is a provenance-aware editorial platform where journalists and creators store, review, and publish their work. The controller is Frontfiles, Lda, a company incorporated in Portugal. Our entity name, VAT number, country of establishment and contact address are stated in the site footer and on the contact page; our registered office address is available on request from the contact address published there. Privacy contact: privacy@frontfiles.news. Frontfiles is established in the European Union, so no EEA representative under GDPR Art. 27 is required.

2. What we collect

We collect only what the platform actually uses:

2.1 Account and profile data

  • Email address (used for sign-in and transactional email; never shown to other users: database access controls restrict email to server-side service access only).
  • Username and display name (public).
  • Optional profile fields, public on your profile: an avatar image you upload, professional title, biography, base location, and an “Available for Work” status you can switch on or off at any time.
  • Founding-member status, if your account was created through the founding-signups mechanism (a permanent flag on your account).
  • Terms/privacy acceptance records: at signup you must explicitly attest (checkbox, server-enforced); we record the document version, the language of the page you accepted on, and a server-side timestamp. Accounts created before 2026-05-28 predate acceptance recording; those users are asked to accept the current documents once, at their next sign-in after publication (see the Terms, §2).
  • Authentication is provided by Supabase (email/password) and Google OAuth (if you sign in with Google, we receive your Google account email and profile picture). Sign in with Apple is configured but not active.
  • Tax residence (creators who want to be paid). The country you declare as your tax residence, and when you declared it. We use it to work out whether tax must be withheld from payments to you, and at what rate, and to choose a payout method that can reach you. This is required to meet our tax obligations (GDPR Art. 6(1)(c)). We keep each declaration, with the previous value, as the record we may need to show the tax authority.

2.2 Content and embedded metadata

  • Files you upload (photos and plain-text files at this stage), including metadata embedded in the file by your camera or editing software (EXIF/IPTC/XMP): capture date/time, GPS coordinates if present, camera make/model, creator/byline fields.
  • We read this embedded metadata at upload to pre-fill your asset’s editable details. Privacy-sensitive embedded fields (GPS coordinates, camera serial number, editing-software identifiers, edit history) are stripped from the publicly served derivative images; your original file retains its metadata and is delivered only to you. The precise capture location extracted from your file is never shown publicly unless you choose to show it: where this control is available on your account, each file carries its own switch for an exact capture point, and while it is on the point appears only on that file’s own public page, at a precision of about 11 metres. Switching it off removes the point from the page and deletes the published point we stored. Public surfaces carry a city-level label, and, where a file appears on the public map, a coordinate coarsened to roughly a kilometre. That coarsening is one-way: the precise point cannot be recovered from what we publish on the map.
  • Text files you upload are compared with text files uploaded by other creators, to find passages they share. The comparison uses fingerprints computed from the words, inside Frontfiles; your text is not sent to any other service for it. When two creators’ files share a substantial part, our staff review the pair and may read the published text of both. Nothing follows automatically: a match changes nothing about your file, and creators are never shown each other’s names.
  • The licence selection you attach to an asset (including a Creative Commons licence choice where you make one) is stored with the asset and shown publicly on published work.
  • AI-proposed metadata about your content (captions, keywords, location labels): see the AI Processing Disclosure. Nothing AI-proposed is published without your explicit review and approval. One exception, and it is most of what is on the site today: the archive we imported on 4 August 2026 was published in bulk as part of the import, without passing through that review step. As of 2 September 2026 that covers 9,393 of the 9,499 published files. The rule has held for every file published since, and if one of the imported files is yours, you can edit or unpublish it from your account.

2.3 Community, messaging, and sharing data

  • Direct messages: if you use messaging, we store the message content you send, the participants, and timestamps. Messages are visible to their participants; they are not public. Message reports and user blocks you make are stored to operate the safety features.
  • Connections: connection requests and the resulting mutual-connection graph (who you are connected to) are stored to operate the feature.
  • Feed interactions: posts, comments, and likes you make on the feed are stored and attributed to your account; posts and comments are visible per the feature’s visibility rules.
  • Collections: collections you create and the assets you add to them are stored; visibility follows the collection’s settings.
  • Share links: when you share content through the share features, we record the share event needed to operate the link.

2.4 Founding list (non-account interest list)

The founding list is a pre-launch interest list. Its sign-up form was on our home page until 11 August 2026, when we removed it. The form now appears only on our pre-launch holding page, which we do not serve while the site is open, so there is no page on the live site where you can join today. The list itself is still switched on: the address the form submits to still accepts registrations, even though nothing on the live site submits to it. We describe it here because it is live, not because it is reachable. If you do join, we store the email address you give us, along with your name and location if you choose to add them. You are on the list only once you open the link we email you to confirm it. If you never confirm, we delete the entry within seven days. We use those details to reserve your founding place and to send that one confirmation email; we do not send you marketing. Confirmed entries are kept until launch, and you can ask us to delete yours at any time.

2.5 Operational records

  • Audit log: security- and consent-relevant events (for example, consent grants and revocations including the IP address and browser user-agent at the moment of consent, email delivery outcomes, AI-processing cost events).
  • Funnel events (server-side): account created, onboarding completed, upload committed, asset published, and search performed. For searches we record only the length of the query, never the query text.
  • Download events: when an original file is delivered, we record the requesting account, the asset, the outcome, and the requester’s IP address and browser user-agent.
  • Error capture: we use Sentry to capture application errors, on our servers and in your browser. Client-side error capture records the technical context of an error (what failed, browser and page state at the moment of failure). Sentry session replay is disabled.
  • “Report a problem” reports: if you use the “Report a problem” button, we receive the message you write and, if you choose to give one, an email address to reply to. We attach diagnostic context automatically so the report is useful without you having to describe it: the page you were on, your browser and screen size, and the build you were running. If you had already accepted analytics, we also attach a link to your existing session recording; if you had not, no recording exists and no link is attached. We rely on our legitimate interest in diagnosing and fixing defects (Art. 6(1)(f)); the message and the optional email address are volunteered by you. We keep these reports for 30 days.
  • Product analytics and session recording, only if you press “Accept analytics” in our cookie banner. We use PostHog (EU Cloud) as a first-party product analytics tool. With your consent it records the pages you view, the elements you click, and a replay of your session on this site: the layout of the pages, your interactions with them, and network timing. The replay masks the text on the page and anything you type, so it shows where things are, not what they say. It records that a network request happened and how long it took, but not the contents: request and response headers and bodies are not captured. Recording is switched off in your messages, at checkout and on receipts, on your account and onboarding pages, in your vault, and on staff pages, and the identity verification panel is never recorded, wherever it opens. If you are signed in, we identify you to PostHog by your account identifier so that usage can be tied to your account. When you sign out, the analytics identifiers in your browser are replaced, so later activity in that browser is not tied to your account. We run no advertising or cross-site trackers, and we do not sell or share this data. Recordings are retained for 30 days and analytics events for 12 months. Nothing here runs before you consent, and you can withdraw consent at any time through the “Cookie preferences” control, which stops capture immediately. It is in your settings menu when you are signed in, and in the page header or footer when you are not. The exact storage keys and lifetimes are listed in our Cookie Policy.
  • Standard server logs operated by our hosting provider.

2.6 Cookies

Session cookies for authentication (Supabase auth), a cookie recording your language preference, and a cookie recording your cookie choices. No advertising or cross-site tracking cookies. We show a cookie consent banner on your first visit, because we use non-essential analytics storage: nothing beyond what is strictly necessary is written until you choose, and refusing is one click. Once you have accepted analytics, the product-analytics events we send from your browser include the address of the page you are on. On a search results page that address would contain the words you searched for, so the query is replaced with a fixed placeholder before the event is sent, and a search you run from the search box is sent only as the number of characters you typed. Section 2.5 therefore holds on both sides: neither the record our servers keep nor the one your browser sends carries the query text. Session recording is the exception, because a recording carries the address of the page it replays. Refusing or withdrawing analytics consent stops all of it. The full inventory is in our Cookie Policy.

2.7 Buying a licence

When you buy a licence, we collect what we need to issue your invoice, keep the tax record of the sale and record what was agreed:

  • Billing details: your legal name, whether you buy as an individual or as a company, your street address, postcode, city and country, and your VAT or tax number if you give one. We keep them on your buyer account, where you can change them, and a copy is fixed on the record of each sale as it was when you paid.
  • The publication: the one publication you will use the file in, and its type. Both are recorded on your licence.
  • Your confirmations: before you pay, you confirm four things: that you have reviewed each file’s validation declaration, that you agree to the licence terms, the total you will pay, and your billing identity. You also ask for immediate delivery, which ends your 14-day right of withdrawal. We record each in our audit log, worded as you saw it, with the time, the licence terms version, the amount and the file. These records hold none of your billing details.
  • The record of the sale: the amounts, the VAT charged and why, the licence and its terms version, the payment reference and, if you gave a VAT number, the answer of its VIES check (section 4.1). Your card details go directly to Stripe (section 3).

3. What we do not collect at this stage

No card numbers or bank details: payments run through Stripe, which collects them directly, and we never see or store them. No raw government identity documents: where identity is verified, the document goes to Veriff and we receive only the outcome and the country that issued it (section 4.1). No third-party advertising data, no advertising or cross-site tracking cookies, no face recognition or biometric identification, and no analytics of any kind for visitors who have not pressed “Accept analytics”.

4. Processors and infrastructure

4.1 Active processors and other recipients

  • Veriff (identity verification): where a creator verifies their identity, the identity document is submitted to Veriff (EU) and stays with them. We store the outcome, the provider’s session reference, and the country that issued the document. We do not receive or store the document itself.
  • Supabase (database, file storage, authentication): production data is hosted in the European Union. Supabase’s standard data-processing agreement applies (reference recorded in our vendor DPA register).
  • Vercel (application hosting, image resizing and optimization): serverless functions pinned to an EU region; public preview images pass through Vercel’s image optimizer.
  • Google Cloud (Vertex AI, Cloud Vision) (AI-assisted metadata proposals, search-ranking embeddings): processed inside a fixed geographic boundary per creator: within the European Union for EU creators and within the United States for US creators; the system defaults to the European Union when a creator’s region is unknown. Google’s “data not used for training” terms apply via the Vertex AI path.
  • Resend (transactional email delivery and delivery-outcome webhooks): delivery outcomes (delivered, bounced, complained) are recorded in our audit log. No marketing email is sent.
  • Google (OAuth) (sign-in with Google): only if you choose it.
  • Sentry (error capture, server and client): client error capture without session replay (Sentry replay is disabled).
  • PostHog (product analytics and session recording, EU Cloud): only for visitors who press “Accept analytics”. Receives pageviews, clicks, session recordings, and, when you are signed in, your account identifier.
  • Upstash (rate limiting, Redis): receives your IP address and, when you are signed in, your account identifier, as the keys of counters that throttle abusive traffic. Each counter is deleted automatically within three days. The counters are hosted in the European Union.
  • Google Geocoding (turning coordinates and place names into a location): when a file you upload carries GPS coordinates and no place name, those coordinates are sent to Google’s geocoding service to resolve a city-level location. A place you type for one of your files is sent to it too (with the file’s coordinates when the place you typed is only a country, to find the city), and so is a place named in an Explore search while Context Source is open. This endpoint is global, not EU-pinned, unlike the Vertex AI and Cloud Vision paths above.
  • Brave Search (Context Source web search): while Context Source is open beside an Explore search, the words of each search are sent from our servers to Brave’s search service in the United States, with a country and language when the search names a place. This works whether or not you are signed in. Brave receives the search words, not your IP address or your account details.
  • Stripe (payment processing): live keys are configured and Stripe’s script loads on checkout pages, where Stripe receives device and browser signals for fraud prevention. When you buy a licence, your card details go directly to Stripe and never touch our servers; we store the record of the sale (section 2.7), not card numbers. With each payment we send Stripe your billing details and the publication you named and, if you gave a VAT number, the answer of its VIES check, so that the payment carries the details of the sale it pays for. Payouts to creators run through Stripe Connect when payouts open. We contract with Stripe Payments Europe, Limited, in Ireland, and Stripe may also process this data in the United States. Those transfers rest on the EU-US Data Privacy Framework, on whose list Stripe, LLC appears, and on the standard contractual clauses in Stripe’s data processing agreement.
  • European Commission (VIES) (checking a VAT number): when you give a VAT number to buy a licence, make a bid or save it on your buyer account, we send its country code and number to the European Commission’s VAT Information Exchange System, which answers whether it is valid and, where the country provides them, the name and address registered to it. We keep the answer with the record of the sale; on your buyer account we keep only whether the number was checked.
  • Frontfiles metadata service (first-party) (extracting embedded file metadata and generating derivatives at upload): our own service, run on Google Cloud Run; listed for transparency, it is our infrastructure, not a third party receiving your data for its own purposes.

4.2 Configured but not active (dark)

The following services exist in the codebase behind keys or feature flags that are off. They receive no user data today. If any is activated, this policy is updated in the same change.

  • Apple Sign-In: configuration only.
  • Serper, Firecrawl (creator profile research): paused since 3 October 2026, and while it is paused none of the services named here receives anything from us. When it runs, it works like this: when you ask us to draft your profile from your published work, your name is sent as a search query to Serper, and Firecrawl reads any personal site address you give us and some of the articles that search finds under your name. Your name is also looked up in Wikidata’s public query service and Bluesky’s public account search and, when the results mention an award, prize or fellowship, on the public websites of the Pulitzer Prizes, the International Women’s Media Foundation and the International Center for Journalists. These services receive your name and web addresses to read, not your files. It runs only on your request, and it is described in full in our AI Processing Disclosure.

Cross-border image-identity lookups (“Tier C” web, landmark, and logo detection at a global Google endpoint) are disabled: the feature flag is off and all prior opt-ins have been revoked with audited revocation records.

5. Why we process (lawful bases)

We rely on the following legal bases (GDPR Art. 6(1)):

  • Account creation, authentication, profile, publishing, storage, derivative generation: contract (Art. 6(1)(b)), operating the service you signed up for.
  • Community features you use (posts, comments, likes, messages, connections, collections, sharing, Available-for-Work): contract (Art. 6(1)(b)).
  • AI-assisted metadata proposals on your own uploads (with per-account opt-out): contract (Art. 6(1)(b)), as a built-in service feature you can switch off.
  • Drafting your creator profile from your published work (paused since 3 October 2026; when it runs, it sends your name to Serper and to the public services named in section 4.2, and web addresses to Firecrawl): contract (Art. 6(1)(b)), a service feature you ask us to run.
  • Resolving a city-level place name from coordinates embedded in files you upload, or from a place you type for them, via Google Geocoding: contract (Art. 6(1)(b)), part of filing the work you uploaded.
  • Context Source web search, which sends the words of your Explore search to Brave Search and a place it names to Google Geocoding: legitimate interest (Art. 6(1)(f)), running the open-web search you asked for, whether or not you are signed in.
  • Comparing the text files creators upload, to find passages two creators share, for review by our staff: legitimate interest (Art. 6(1)(f)), knowing when a file we license may not be the uploader’s own work. You can object to this at any time (section 8).
  • Showing a file’s exact capture point on that file’s own public page, where you switch it on for that file yourself: consent (Art. 6(1)(a)), given per file and withdrawable at any time by switching it off.
  • Security, audit logging, download logging, error capture, abuse prevention, and rate limiting (which processes the caller’s IP address and, for signed-in requests, their account identifier): legitimate interest (Art. 6(1)(f)), keeping the service secure and demonstrating compliance.
  • Product analytics and session recording (PostHog): consent (Art. 6(1)(a)), given through the cookie banner and withdrawable at any time through the “Cookie preferences” control, which is in your settings menu when you are signed in and in the page header or footer when you are not. We do nothing with this data unless you have consented; withdrawing stops capture immediately and also clears the analytics identifiers already stored in your browser.
  • Server-side funnel events (counts, never query text): legitimate interest (Art. 6(1)(f)), understanding aggregate service usage.
  • Founding list: consent (Art. 6(1)(a)), double opt-in, withdrawable any time.
  • Any future optional AI feature offered per-creator (for example, a revived Tier-C): consent (Art. 6(1)(a)), explicit opt-in.
  • Marketing (none today): consent (Art. 6(1)(a)), only if ever introduced.
  • The tax residence you declare to be paid: legal obligation (Art. 6(1)(c)), working out whether tax must be withheld from payments to you, and at what rate.
  • Your billing details, the record of each sale and the VIES check of a VAT number: legal obligation (Art. 6(1)(c)), issuing the invoice and keeping the tax record.
  • Your confirmations at checkout, and sending your billing details to Stripe with the payment: contract (Art. 6(1)(b)), taking the payment and recording what was agreed for the licence you buy.

6. Retention

  • Unreviewed upload drafts are eligible for deletion after a retention window (currently 7 days), but nothing deletes them automatically today: the reaper that would do it is deliberately not scheduled, so drafts past the window are kept rather than removed. We hold them until you delete them yourself or ask us to. Incomplete upload batches close after a window (currently 48 hours). Both windows are operator-configurable. If we start deleting drafts automatically, we will say so here first.
  • “Report a problem” reports are kept for 30 days.
  • Unconfirmed founding-list entries are deleted within seven days; orphaned authentication accounts (sign-up never completed) are reaped automatically and the reaping is audit-logged.
  • Text comparison: a text file’s fingerprints are kept for as long as we hold the file. The record of a staff review is kept for 24 months after the review and is then deleted.
  • Published content persists until you delete or unpublish it. After you delete or unpublish a file, a preview or embed of it that was already served can stay in caches for up to an hour.
  • Audit-log entries and download records keep the IP address and user-agent they contain for 12 months on a rolling basis; after 12 months those fields are removed from the records. Acceptance and consent records are kept for the life of your account so we can demonstrate consent existed; on account deletion they follow the erasure mechanism’s rules.
  • The record of each sale, including the billing details fixed on it and the answer of a VIES check, is kept for 10 years, to meet our tax obligations. Deleting your account does not delete it: the account it points to is anonymised, but the billing details an invoice needs stay on the record for those 10 years.

7. If you had an account on the Frontfiles beta

Frontfiles moved to a new platform. If you had an account on the earlier Frontfiles beta, your account and the work you uploaded were carried across to this one. The company behind both is the same: Frontfiles, Lda. We process that imported data to continue the relationship you already had with us, which is the ‘contract’ basis described in section 5.

  • Where it came from. The beta platform’s own database and file storage, which we operated.
  • What we brought across. Your account details (email address, name, username, the profile text and links you wrote, your city and country), your photographs and the technical information saved inside them by your camera, your collections, and the prices you had set.
  • What we deliberately did not bring. Your old password (you set a new one), payment and billing identifiers, identity-document files, and the beta’s own ‘verified’ marks. Verification is earned again here, not inherited.
  • Location data. Photographs often carry the exact coordinates where they were taken. Those exact coordinates are visible only to you, unless you choose to show a file’s exact capture point on that file’s own public page. What appears on the public map is a coarsened point, accurate to roughly a kilometre, never the exact one.
  • What is public, and why. Every imported file arrived private. Files that sat in collections you had set to public on the beta were then published here on 4 August 2026, so that the choice you made there carried across rather than being silently undone. Everything else you uploaded stayed private, and nothing further is published unless you publish it.
  • The working copy. Running an import needs a staging copy of the source data. We delete that copy 30 days after the last account-recovery email goes out.
  • The email you received. We did not bring your old password, so we send one message with a link to set a new one. Without it your imported account is unreachable. It is not marketing and carries no promotional content.

Your rights in section 8 apply to imported data exactly as they do to anything else. If you would rather we deleted it, write to privacy@frontfiles.news.

8. Your rights

You have the rights EU data-protection law gives you over your data: access, rectification, erasure, restriction, portability, and objection (GDPR Articles 15 to 22). To exercise any of them, email privacy@frontfiles.news; we respond within one month. You also have the right to complain to a supervisory authority; in Portugal that is the CNPD (www.cnpd.pt). If you are outside the EEA, we apply the same rights to your data by default.

What exists mechanically today, described factually:

  • Profile fields are user-editable, and AI suggestions can be disabled per account (see the AI Processing Disclosure); consent revocations are audited.
  • Account deletion (right to erasure): the platform has a built erasure mechanism that deletes your account and personal data, withdraws your published assets, and scrubs identifying metadata, retaining only records we are legally required to keep (and telling you so). Today it is available to you directly: the data and privacy controls in your account settings let you export your data and delete your account. The same operation can also be run on request through a documented internal runbook with a one-month response discipline.

9. Security

Column-level database access controls (for example, your email is unreadable by other users’ sessions at the database layer), row-level security as the primary authorization boundary, Bearer-token identity verification for all creator API operations, content delivered through a governed delivery API rather than direct file URLs, and cryptographic checksums (SHA-256) recorded for original files.

If a personal-data breach occurs that is likely to put you at high risk, we will tell you without undue delay, and we notify the competent supervisory authority within 72 hours of becoming aware of a notifiable breach (GDPR Articles 33 and 34).

10. Children

Frontfiles is not directed at children. You must be at least 16 to use the service and at least 18 to publish as a creator. We do not knowingly process children’s data; if you believe a child is using the service, contact privacy@frontfiles.news.

11. Changes to this policy

Acceptance is versioned per account (we record which policy version you accepted and when). For material changes we give at least 15 days’ notice by email and in-product notice before the new version takes effect, and existing users are asked to accept it. The version and date you accepted are recorded on your account.

12. Contact

Privacy contact: privacy@frontfiles.news. We have not appointed a Data Protection Officer: at our current scale and processing profile we assess that one is not mandatory, and we will revisit this as the platform grows. Frontfiles is established in the EU; no EEA or UK representative is designated.

Questions about your data, contact us.

← Back to Frontfiles