Privacy notice

Only what the site needs in order to work:

• An email address, so an account can be recovered and verified. The password itself is never stored; the authentication provider holds a hash of it and FRAME never sees the original.
• The profile fields you write: username, display name, avatar, biography, where you are based, a website, and the gear you choose to list. Every one of them is free text you decide to enter, and every one of them is optional except the username and display name.
• The photographs you upload and the EXIF inside them: camera and lens, focal length, aperture, shutter speed, ISO, the capture date and, where the camera recorded one, a GPS coordinate.
• Appreciation records: which account appreciated which photograph. Appreciation is one per member, and that cannot be enforced without keeping the record of who it was.
• Reports: the thing reported, the reason chosen, any note written, and the reporting account where the reporter was signed in.
• Place submissions: the name, city, country, coordinate and note proposed for a new location.
• Rate-limit counters, keyed to the account taking the action.

Not collected: an advertising identifier, a behavioural profile, cross-site tracking, or a record of what anyone searches for. FRAME has no analytics vendor embedded in it.

Published, meaning visible to anyone including people with no account: your display name, username and avatar; your biography, based-in line, website and listed gear; the month you joined; the photographs you have published, with their titles, alt text, descriptions, categories and capture settings; the places you submitted that were approved; your public collections; and the appreciation count on each photograph.

Not published: your email address; the exact day you joined, which is why a profile shows a month only; your drafts and anything still processing; your private collections; which photographs you appreciated, as distinct from the totals; the reports you filed and the fact that you filed them; and your rate-limit counters.

A photograph you remove, or that a moderator removes, stops being served immediately. Caches and other people’s browsers may hold a copy for a short while afterwards, which is a property of the web rather than a decision FRAME makes.

EXIF is read in your browser as you choose a file, so the upload form can offer the camera and the settings back to you instead of asking you to type them. You can change or clear any of it before publishing.

A GPS coordinate found in EXIF is never published automatically. It is used for one purpose: to ask whether you want to pin the photograph to a place. If you do not answer, nothing is pinned. A coordinate that stays in the file you uploaded is not served to anyone, because what FRAME serves are generated derivatives with the metadata stripped out.

Where you do publish a place, the coordinate is rounded by policy to about 11 m — enough to find a doorway, not enough to point at a window. Where a moderator has marked a place as privacy-sensitive it is coarsened further, to about 1.1 km, and where even that would be unsafe no coordinate is published at all. The map and the page both say when a point is deliberately approximate.

Precision is only ever reduced, never widened: a coarsened point stays coarsened, and there is no stored copy of the finer value that a later change could expose. If you published a place and now regret it, ask and it will be coarsened or removed.

An IP address identifies a connection at a moment, not a person. It is shared by everyone in a household, an office, a university or a café, it is shared at much larger scale by mobile carriers, and it changes — sometimes several times a day.

So FRAME keys its limits and its records to an account rather than to an address. Treating an address as a person gets it wrong in both directions: a crowded café is throttled as though it were one very busy member, while somebody determined to abuse the site only has to reconnect.

The exceptions are the requests that arrive before a session exists — signing up, signing in, asking for a password reset — where the limit can only be applied to the attempt itself. Those counters are short-lived and are not used to build a profile.

A hosting provider records the IP address of every request as part of serving it. That is true of any website. FRAME does not read those logs to identify a member, does not join them to account records, and does not use them for anything other than keeping the service running.

• Account and profile: for as long as the account exists.
• Published photographs and their generated sizes: until you remove them, or until the account is deleted.
• Drafts: until you publish or discard them. A draft that is never finished is still yours.
• Appreciation records: while both the account and the photograph exist.
• Reports and moderation decisions: kept after the thing they concerned has gone, because the reason something was removed is the only answer to the same claim arriving twice. They are attached to the moderator who decided, not to the person who reported.
• Rate-limit counters: hours, not months. They are cleaned up as they expire.

Backups will hold a copy of deleted content for a period after deletion. A specific retention window for backups has to be set, and stated here, before launch.

Most of this you can do yourself, which is the point: edit any profile field, remove a photograph, make a collection private, or delete the account outright.

Deleting an account removes the profile, the photographs, the generated sizes and the collections. Two things survive it. Moderation decisions are kept with the account reference removed wherever that is possible, for the reason above. And where the account belonged to a moderator, the audit trail it authored cannot be left without an author, so such an account is demoted and retained rather than erased — a point worth knowing before anybody is made a moderator.

You can ask for a copy of what is held about you, and for a correction of anything that is wrong. The contact route for those requests, and the supervisory authority a complaint can be taken to, must be named here before launch.

FRAME is a small application standing on four services:

• The database and authentication provider (Supabase, Postgres and its auth service) holds accounts, profiles, photographs, appreciation, reports and the email address and password hash.
• The image storage provider (Supabase Storage, or Cloudflare R2 where that is configured instead) holds the uploaded file and the sizes generated from it.
• The map tile provider supplies the style and tiles for the map. Your browser requests those tiles directly, so that provider sees the request, including your IP address, the way any website you visit does. FRAME ships with no tile provider configured and deliberately falls back to no map rather than to somebody’s evaluation server.
• The hosting provider runs the application and logs requests as described above.

A deployment with no database configured shows a bundled sample dataset instead, and says so on every page. The sample photographs in that mode are served from Unsplash under the Unsplash licence and describe nobody real.

Each of those providers needs to be named specifically, with a data-processing agreement in place, before FRAME handles anybody’s real data. See the terms for what is still outstanding.