Privacy policy
Effective 13 September 2026. This is the first version.
Diet Handbook is an iPhone app for keeping recipes and planning meals around dietary
restrictions. It is run by Ivan Shakhorski as an individual developer. This policy covers
the app, the service behind it at
api.diet-handbook.shakhorski.com, and this website.
Questions, requests, or anything this page doesn’t answer: ivanwanwas@gmail.com.
The short version
- Your account holds what you type in: recipes, meal plans, shopping lists, and the diet profiles that say what you avoid.
- Diet profiles are health data. They are the most sensitive thing here and they are treated that way.
- There is no analytics SDK, no crash reporter, no advertising, and no tracking of any kind — across apps, across sites, or otherwise. Nothing is sold or shared for marketing.
- You can export everything, and you can delete the account. Deletion is scheduled with a grace period so it can be undone by mistake, not just by regret.
What is stored, and why
| Kind | What it is | Why |
|---|---|---|
| Account | An account id, and the identity Apple or Google gave when you signed in — an opaque subject, sometimes an email address, sometimes a display name. An Apple private-relay sign-in may leave us no address at all. | To know whose handbook is whose, and to let you add a second sign-in method to the same account. No mail is ever sent to it. |
| Diet profiles (health data) | Allergen hard stops, dietary systems, macro targets, who you are cooking for — often a household member’s first name — and a private model of what you tend to cook. | This is what the app does. It is used to filter recipes for you and for nothing else. |
| What you write | Recipes, ingredient lines, steps, photographs, notes, and reports you file about somebody else’s recipe. | To keep your handbook, and to run the public catalogue if you publish to it. |
| Planning | Meal plans, saved plan shapes, shopping lists, and the cupboard. | To plan a week and shop for it. |
| Engagement | Likes, ratings, collections, and what you cooked when. | Shown back to you, and — for likes and ratings — counted on public recipes. |
| Household | Households you are in, who else is in them, and outstanding invitations. Invite codes are stored as hashes. | So several people can cook from one handbook. |
| Sessions | One row per signed-in device: a hash of its refresh token, the app build, a device label you typed, and a coarse region worked out from where the request came from. The address itself is not stored. | Security. So that “signed in from somewhere I have never been” is a question you can answer. |
| Operational | A short-lived record of requests already handled, so a phone with bad signal can’t create the same recipe twice; rate-limit counters keyed on a secret hash of an address rather than the address; moderation leases. | Keeping the service working and abuse-resistant. |
| Audit | That a privileged action happened — a moderation decision, a role grant, a change to ingredient safety data — by account id, never by name. | Safety-relevant decisions have to stay attributable. |
Health data
“Avoid peanuts” stored against a named person is health data, and this app is built around storing exactly that. It is declared as health data in the App Store privacy labels. It is never used for advertising, never shared with anybody outside the service, and never sent to a third party for analysis. Within the service, it is read only to decide which recipes to show you.
If you join a household, the members of that household can see the diet profiles shared into it — that is what a household is for. Leaving one removes those rows from your device immediately, and stops the sharing in both directions.
Photographs
A photo of dinner carries the coordinates of the kitchen it was cooked in. Every uploaded image is re-encoded before it is stored, which drops that metadata: no EXIF reaches the storage bucket, let alone the public catalogue. Images are never publicly readable — each view goes through the service, which checks who is allowed to see the recipe.
What is deliberately not collected
- No device identifiers. No IDFA, no vendor id, no fingerprinting.
- No analytics. There is no analytics SDK in the app and no event pipeline in the service.
- No crash reporting yet. If that changes, this page changes with it.
- No location. The app never asks the device where it is.
- No advertising, and no sale of data. There is nobody to sell it to and it is not for sale.
Who else sees it
| Who | What they get |
|---|---|
| Hetzner Online GmbH (Germany) | Everything, as the hosting provider: the servers running the service, the database, and the storage holding recipe photographs. They are a processor acting on our instruction and do not use any of it for their own purposes. |
| Apple and Google, for sign-in | What they learn from their own side of the sign-in exchange. Nothing about you is sent to them by this service: it verifies the identity token you bring against their published keys, which is a request for keys and not for anybody. |
| A website you ask the importer to read | A request from our server for a page you named. Your own address is never forwarded — the fetch is ours, from our address — so the site learns the page was imported, not by whom. |
| USDA FoodData Central | Nothing. It is read when ingredient reference data is built, never in the path of anything you do. |
A public recipe is seen by everybody, which is what publishing means. Nothing else you write is visible to anyone outside your household.
How long it is kept
- Most of it, for as long as the account exists.
- A deleted recipe or profile leaves a tombstone for 180 days, so other devices learn it is gone, and is then removed outright.
- A draft untouched for 90 days is deleted automatically, and then follows the same path.
- A session ends when it is revoked, or 60 days after it was last refreshed — whichever comes first.
- Replayed-request records: 7 days. Rate-limit counters: 24 hours past their window.
- Audit entries are kept indefinitely. A record that expires cannot answer the question it exists for.
- Backups: up to 14 days. The database is dumped nightly and a dump is deleted once it is a fortnight old. Backups are not edited to remove a deleted account — rewriting history inside a backup is how a restore silently loses unrelated data — so a dump taken before a deletion still holds those rows until it ages out. This is the real number, which is why it is the one stated here.
Getting your data, and deleting it
Export
Settings → export produces a machine-readable file containing everything held against your account, section by section. It is generated on request from the live database rather than from a copy kept for the purpose.
Deletion
Settings → delete account schedules the deletion and tells you the date. The account keeps working until then and you can cancel from any device, because a decision made by accident needs a way back. On that date, everything above is destroyed, with three exceptions, all deliberate:
- Recipes you published to the public catalogue are kept, and severed from you. They are in other people’s meal plans and shopping lists, and withdrawing them would delete a stranger’s dinner for a reason that has nothing to do with them. They carry no author byline. Your photographs are not kept: those are deleted, because a picture of your kitchen is a more personal thing than a method.
- A report you filed about a recipe stays as an anonymous row. That it was you goes; that a recipe was reported, dismissed and reported again is what makes moderation possible.
- Audit entries stay. The record that a moderation decision or a role grant happened has to remain attributable — it holds an account id and a timestamp.
Anything else — correction, a question about what is held, or a deletion you would rather arrange by email — is ivanwanwas@gmail.com. If you are in the UK or EU/EEA, the rights of access, rectification, erasure, restriction, portability and objection all apply, and you may complain to your national data protection authority.
Where it is held
On servers in Germany. Sign-in verification talks to Apple and Google, who operate globally; nothing about you is sent in either direction.
Children
The app is not directed at children, and an account is not knowingly created for anyone under 13. If you believe a child has one, write to the address above and it will be removed.
This website
These pages set no cookies, run no analytics, and make no requests to any other host — the typeface is served from this domain for that reason. The web server keeps ordinary access logs for a short period to diagnose faults.
Changes
When this policy changes, the date at the top changes with it, and a change that widens what is collected will be announced in the app before it takes effect.