Privacy policy

Applies to the site and to the application, both at snapfork.app. Last updated 13 September 2026.

What the server stores

Only what sign-in, synchronisation and correspondence with the developer cannot work without:

What happens to your diary

Your diary lives both on your device and on the server — but on the server it is encrypted. Entries, photo previews and weight records live in your browser's storage, and a sealed copy travels to the server: the key to it exists only on your device. The server can see that entries were added and when — and cannot see what you ate, how much of it, or what you weigh.

We cannot read your diary either. That is not a promise to behave well; it is how the system is built — we do not have the key. Which brings the price you should know in advance: lose your recovery code along with your device and nobody can bring the diary back, us included. There would be nothing to restore it from. The code is shown in Settings, under “Data” — write it down and keep it somewhere other than your phone.

The server also keeps conflicting versions — and that is in your favour. If one entry was edited on two devices, the newer edit wins, and the one that lost is not thrown away: it stays on the server for a month, sealed just the same, and the application can show it to you. Otherwise «it fixed itself» would be our word against your memory. We cannot read it either, of course — it is in the same envelope as everything else.

Settings go to the server only if you turn their sync on. Goals, profile (sex, year of birth, height, activity), water goal, meal shares, diary features, quick actions, units, the share card theme and two switches — a hidden product score and a disabled open-database search — travel in one envelope, sealed with the same key as the diary. It is turned on by a separate switch in the «Data» section; until you do, settings are not sent anywhere. You turn it off in the same place — the server copy is erased at once, and sync is turned off on all your devices. The server sees that the envelope exists, when it changed, how large it is and when sync was turned off — and not what is inside. App theme, language, reminders, the Apple Health connection and your own recognition provider key never leave the device: they belong to the device, not to you.

A backup file is still exported by you and kept by you. It is not encrypted, and it is the only way to read your diary without the code.

No first name, surname or profile picture: sign-in providers are asked for one thing only, confirmation of the email address.

Your device's own backup

This is about the application for iPhone. It is not in the App Store yet, and what follows describes how it will behave once it is out. The website has nothing of the kind: in a browser there is no app container and no such backup.

An iPhone backup takes app data to iCloud — that is how the backup works, not something our app does. Whether your diary goes into it is your decision, and by default it does not. You are asked on first run, and you can change the answer at any time: Settings → “Data” → “Diary in the iCloud backup”.

What is described here is the mechanism, not the outcome, and that is not evasiveness: once you have answered, the sentence “my diary is in iCloud” is true for some readers and false for others. Say yes and the backup is made and kept by Apple under Apple's rules — it is their copy, not ours: we neither see it nor can open it. Say no, or say nothing at all, and the app's folder is marked as excluded from the backup, so the diary does not travel there.

None of this touches the backup file you export yourself: that one you make and keep wherever you like.

Where data does go

Photographs of meals are sent to be recognised, and where they travel depends on whose key signs the request. There are two routes, and the choice is yours:

The application starts on your own key and moves to ours only after yours has failed. That is the default, and a checkbox in settings turns it off — and then the photograph never goes through our server under any circumstances.

Your product search string — if you tapped “Search the open database”. The application has a Products door: it searches your own products and the catalogue downloaded onto your device, and all of that happens with no network at all. When the catalogue does not hold what you are looking for, a “Search the open database” button appears under the list. On that tap — and only on it — what you typed into the search field leaves your device for Open Food Facts, bypassing our server: we neither see that string nor store it. There is no autocompletion as you type and no background request: without the tap, nothing leaves.

Nothing else travels with that string: no diary entries, no photographs, no weight, no account identifier — the request needs none of them, and the application attaches none. From there the terms of Open Food Facts apply, not ours. A checkbox turns it off: Settings → Products by barcode → “Search the open database on a tap”; switched off, it removes the button itself, and nothing leaves at all. Looking a product up by the code on its pack, and searching the downloaded catalogue, never go online — neither with the checkbox on nor with it off.

Sign-in code emails go through the mail provider chosen by the service owner. Beyond what is listed here, nothing is passed to anyone: there is no analytics, no advertising and no third-party script on the site or in the application.

Into the letter itself the provider adds an open counter — a small image loaded from its server when the letter is opened. From that it learns that the letter was opened and when; mail clients that fetch images directly also show it the address the letter was read from. This cannot be turned off on our plan. The letter as we compose it carries no image and no link at all.

The visit counter

The site counts visits itself, without cookies and without anyone else's scripts. What reaches the database is daily numbers: page, language, where the visit came from. Neither IP address nor User-Agent is stored in any form — they are turned into a key with a daily salt, and the salt itself is written nowhere, so even we cannot line two days up against each other. The Sec-GPC header is honoured: with it, nothing is counted at all.

Correspondence with the developer

The application's settings contain a “Support” section: you can write about something broken or something missing, and get an answer in the same place. This is a conversation rather than a form — which means it is stored on the server: otherwise there would be nowhere to answer.

What is stored is the text of your messages and the developer's replies, attached to your account. They are read only by those whose confirmed addresses the service owner has put on the developer list: the list is closed, it lives in the server's settings, and nobody else sees the correspondence. Neither an email address nor a name sits next to it — the server does not hold them in plain text anyway, and the conversation is held with a diary, not with a person.

Device details are attached only if you tick the box, and before sending you are shown exactly the text that will travel: the version of the application and of the database, platform and browser, language, window size, the screen you are writing from and the code of the failure if you came from one, how many entries and weigh-ins you have as plain numbers, whether the device was online, whether the app was opened from its icon or in a browser tab, whether debug mode is on and whether a platform key is set — “yes” or “no”, never the key itself. Not a single diary entry, photograph, weight record or profile field goes there.

The notification email that reaches the developer contains neither the text of the message nor your identifier: only “there is a new message in the thread”. The contents of the correspondence never reach the mail provider and never appear in the server logs.

Invitation links

The application can give you a permanent invitation link. If someone signs up through it, both of you get extra recognitions with our key — nothing else changes, and nobody gains access to anyone else's diary.

What is stored is the fact that one account arrived through another's link: which link, when, and whether the reward has been earned. That is a record about a connection between two people, so it is kept to the minimum and shown to nobody: the person who invited sees numbers only — how many came, how many came back, how many recognitions were received. Not a name, not an address, not a moment of signing in. We do not say who accepted, because that would be telling a third party that a particular person started keeping a food diary.

The link itself carries a code and nothing about you. Opening it is counted by the visit counter as its own campaign — the label only: the code never reaches the counter, otherwise the daily numbers would turn into a table of whose links work.

Deleting an account removes the link and the record of where that account came from; the reward entries stay with the account identifier stripped, because the limits on how much can be given away are counted from them.

Top-up entries behave the same way: deleting an account leaves them in place but stops them naming anyone. The reason is not bookkeeping but you — a bank can dispute a payment a month after the account is gone, and with no amounts left there would be nothing to answer such a dispute with. Any remaining balance is burned on deletion, and that is written as its own entry: money for which no service was rendered stays visible as exactly that, instead of dissolving into revenue.

Friends

If you invite a friend and they accept, something derived from your diary starts leaving your device — and it is exactly two facts per day for the last seven days: whether you logged anything at all and, if you shared that separately, whether you stayed within your own goal. Plus how many days in a row you have logged. Not what you ate, not how many calories, not your weight — none of that leaves, at any level of sharing.

Sharing is the same in both directions: your friend sees exactly as much about you as you see about them, and it cannot be made one-sided. Consent is asked per friendship and per level, and we record which text you agreed to: if the meaning of that text changes, we ask again rather than quietly extend it. You can undo it any day, and there are two buttons: “stop sharing” keeps the friendship, “delete friendship” removes the connection and erases what each of you saw of the other.

There is a third button for when ending it is not enough: a refusal. After that, a further invitation from that person will not go through — otherwise “delete friendship” would only mean “until the next invitation”. For this the server keeps a list of the people you have refused: identifiers and a date, no reason and not a word from you; it lasts until you undo it. We do not tell the other side — someone refused sees exactly what they would after an ordinary ending: there is no friendship. That list is deliberately kept out of the “What the server holds about you” export: it is a file you can forward to someone.

We cannot read any of it — provided the key is genuine. The contents travel sealed with a key we do not have, every envelope is the same length, and even the size gives away nothing about how many days are inside. But some things we do see, and we say so plainly:

What we do not see: what is inside, how much is in there, what you called your friend on your own device, and who looked at whose week.

That caveat about the key is not a figure of speech. The keys you exchange travel through our server — which means that, in theory, we could swap them. You can check this: eight digits computed from both public keys must match for you and your friend. We offer that check rather than require it — and until you have made it, you are trusting the server to have handed over the real key. The friendship screen always shows whether it has been verified.

The key that seals your week is kept on your device and never travels — not to us, not into your backup. So on a new device, friendships have to be confirmed again.

How long things last: an unaccepted invitation lives 30 days and works once; your week sits on the server until the next one and is erased at once when a friendship ends; notes live seven days; the connection lasts until it is ended or the account is deleted. Social features are not offered to anyone whose profile says they are under 16.

You can have no more than 50 friends, and that ceiling is ours rather than the product's: the longer the list, the more connections the server knows about. Invitations are capped for the same reason — five live at a time, ten a day.

Cookies

Exactly one on the whole domain: the sign-in session. It is technical, is set only when you sign in, lives up to 180 days from the last sign-in, and is visible to nothing but the application. Before you sign in there is none — and afterwards it travels with every page here, this one included, because the site and the application answer at one address. There is no banner because consent is not asked for the cookie without which signing in cannot work, and there is nothing else to ask about: no analytics, no advertising.

How long things are kept

Session — up to 180 days from the last sign-in. Email code — 10 minutes. Daily counter numbers — indefinitely, but they contain nothing about a person. Account — until you delete it. Correspondence with the developer — exactly as long as the account: it goes together with it and has no separate term. We chose not to name a separate term deliberately: it would be a promise to erase on a schedule, and there is no schedule — so the promise would be false from the first time anyone checked.

Diary entries on the server — as long as the account lives. They have no separate term, and that is a decision, not an omission. The server keeps a sealed copy of the diary for the sake of your second device — and a copy that vanishes by itself is of no use to a second device: it would have nowhere to get back what the server forgot, and the diary on it would quietly turn out shorter than on the other one. Entries go together with the account and only with it: delete it, and the sealed copy of the diary leaves the server's database at once, and its backup copies as they rotate out — how soon is said at the end of this section. The diary on the device itself remains yours and is erased separately.

The thirty days named below are not about the entries themselves, and the two terms should not be confused. Thirty days is the life of photo previews (both on the device and on the server) and of entry versions that lost a sync conflict. Both lie BESIDE an entry rather than instead of it: what goes is a picture or a previous draft of the line, while the entry itself stays where it is. Both terms count in the server's working database; in its backup copies a picture or a version can outlive them by up to 14 days — see the last paragraph of this section.

Meal photo previews — 30 days. The application keeps a small copy of the picture beside the entry and deletes it from the device thirty days after the picture was taken. The entry itself stays: only the picture goes. We do name this term, precisely because here a schedule exists — the sweep runs every time the application opens and immediately after a backup is restored — and you can check it by opening an old day. The full-size photograph never enters the diary at all: the entry holds only this preview.

On the server the preview lives by the same term — no longer than thirty days. It travels there sealed, along with the diary, so that it can appear on your second device; we cannot open it, any more than we can open the entries. The server counts the term from the day the picture arrived, not from the day it was taken: it does not know the day it was taken — that is inside the ciphertext. So the preview goes from the device first and from the server after, and the sweep runs on a schedule, once a day, rather than “eventually”.

Entry versions that lost a sync conflict — no longer than thirty days. When you edit an entry you replace its previous version; the server does not throw that previous one away at once but keeps it aside — so that “it fixed itself” is not our word against your memory. You can see them and bring them back in the application, in the conflicting-versions card. They lie there sealed, like the entries: we cannot open them either. The sweep runs on a schedule, once a day — and that is why we name the term here.

Such a version can go sooner than the term, and it is more honest to say so plainly: per entry the server keeps at most twenty of them, and the twenty-first displaces the oldest. That is an engineering limit against runaway code, not a promise to keep twenty. The current version of an entry is touched by neither the term nor the limit: it is your diary, and it goes only together with the account.

Server backups — up to 14 days. Once an hour the server copies its whole database — insurance for the day a failed disk or a broken update would otherwise take everyone's accounts with it. Copies from the last 48 hours are kept one per hour, older ones one per day, and a copy older than 14 days is deleted at the next hourly rotation. Copies are deleted only by a running server: while it is switched off, every copy stays, and once it is back the expired ones go at once. One caveat: the newest copy always stays — even when expired, if new copies have stopped succeeding — until the next successful one, because an old copy is more use than an empty shelf. A copy holds exactly what the database held at that hour, and in the same form. What is sealed with your key — the diary, previews, settings, conflicting versions — stays sealed in the copy, and we have no key to it; what the server sees openly — the correspondence with the developer, who is friends with whom — it sees in the copy as well. This is why every term above is a term in the working database: whatever was erased there — by the sweep or together with the account — stays in the backup copies no longer than 14 days after that, save in the cases above. Fourteen days is an upper bound, not a promise to keep: a copy can go sooner, for instance when the disk runs short of space.

Deletion

In the application: settings → “Delete account”. That erases the account, all of its sign-in methods, all sessions and the whole correspondence with the developer; for Apple sign-in it also revokes access on Apple's side. What the server kept for synchronisation goes with the account too: the sealed copy of your diary, the photo previews, the sealed copy of your settings, the journal of conflicting versions and the list of your devices — none of it is left in the server's database. The hourly backup copies still hold it for up to 14 days, in the same form, and then it is gone from them too (provided the server was running and new copies were succeeding); how the copies work is described under How long things are kept. The daily numbers of the visit counter stay: they contain nothing about a person, and they cannot be removed per account, because there is no account in them. The diary on your device is erased by a separate button — it is yours alone, and we will not decide its fate for you.

Changes

This policy changes along with the service; the date at the top of the page is the date of the last edit. Substantial changes are announced here rather than by email: the server keeps no address it could write to — only a fingerprint of one.

Contact

The data controller — whoever decides what is stored here and answers for it — is a private individual, not a company: Snapfork has no legal entity behind it. That individual is Oleksandr Trifonov. Everything about the service, including requests concerning your own data, goes to the address below. What that arrangement means in practice is set out on the page about who is behind this.

Questions, access to your own data and deletion — through the questions page or by writing to hello@snapfork.app.

Terms of use · Open the application