Privacy Policy
What data Cal 3D processes, where it goes, and what never leaves your device. Written from what the code actually does — not from a template.
On this page
- The short version
- Controller
- What stays on your device
- What happens when you scan a meal
- Processing by artificial intelligence
- Recipients at a glance
- Transfers to the United States
- Barcode lookup
- Subscriptions and payment
- Security in transit
- This website
- When you write to us
- Retention and deletion
- Do you have to provide this data at all?
- Your rights
- Children and young people
- Changes to this policy
The short version
The app is not published yet. This policy describes the processing that begins with its first release — so you can read before you install what will happen, rather than afterwards. This website itself processes nothing beyond what is described under Using this website.
Cal 3D is built so that as little as possible leaves your device. So that you do not have to read the whole thing first, here is the summary:
- There is no user account. You never sign in anywhere. We have no list of users, because technically none exists.
- Your food diary stays on your device. Meals, weight, goals, history — all of it lives in the app’s local storage and is never stored by us.
- Three things do leave your device, and only when you ask for them: a photo of your meal, a food name you type into the search, or a workout you describe in your own words. Each goes through our own endpoint to OpenRouter and from there to Google Gemini. We do not store any of them.
- The measurement never leaves your device. Volume and portion size are computed on your iPhone. Our endpoint never sees them — and neither does your body weight, which the app uses only locally to turn a workout into calories.
- This website sets no cookies and loads nothing from third-party servers. That is why there is no consent banner — there would be nothing to consent to.
Everything below is the detailed version that the GDPR requires.
Controller
The controller within the meaning of Art. 4 (7) GDPR is:
Noah Sioly UG (haftungsbeschränkt)Hoheluftchaussee 139
20253 Hamburg
Germany
Email: noah.sioly.ug@gmail.com
Phone: +49 163 1482383
Data protection enquiries are answered by the management directly, at the address above. You will get an answer within one month, as Art. 12 (3) GDPR provides — usually within two working days.
What stays on your device
Most of what the app knows about you never reaches us. This data lives exclusively in the app’s local storage on your device:
- your food diary — every logged meal with its ingredients and nutrition values,
- your profile — height, weight, age, activity level and the goals derived from them,
- progress, streaks and badges,
- the measured volume and the portion size derived from it,
- your photos — the profile picture, progress photos attached to individual weigh-ins, and the thumbnails of logged meals,
- your meal reminders and your settings.
None of this is transmitted to us, backed up to a cloud, or synchronised between devices. We can therefore neither see it nor restore it — and you do not need to ask us to delete it: it disappears with the app.
The downside of this design, stated rather than hidden: if you delete the app or lose the device, the data is gone. A device backup (iCloud or computer) includes the app’s data — currently that is the only way to preserve it.
What happens when you scan a meal
A scan consists of two parts that run separately. The difference matters for privacy:
The measurement — stays on the device
While you sweep around the plate, the app reads the camera’s depth data and computes the volume of the food in millilitres. This happens entirely on your iPhone. The depth data and the volume are not transmitted.
The recognition — this is what leaves the device
To determine what is on the plate, a vision model is needed, and it does not run on the device. The same model also answers two other questions you can ask the app, so there are three ways — and only three — for something you provide to reach it:
| When | What is transmitted | What is not |
|---|---|---|
| You photograph a meal | What is transmittedexactly one compressed image, together with the text instruction that directs the model | What is notthe measured volume, the portion size, your diary |
| You type a food into the search | What is transmittedthe words you typed, together with the same kind of instruction — no image | What is notyour profile, your goals, anything you typed earlier |
| You describe a workout in your own words | What is transmittedthe description you typed — no image | What is notyour body weight; the calories are worked out on your iPhone afterwards |
For all three of them the following applies:
- Our endpoint stores nothing and writes nothing to a log. It passes the request through and returns the answer.
- No device identifier, no advertising ID and no user name goes to this endpoint.
- Nothing is sent unless you start that one action. The app transmits nothing in the background and nothing on a schedule.
Worth spelling out, because it would be the obvious thing to send: your body weight is not transmitted when you describe a workout. The model is asked for the intensity of the activity, never for calories — those are worked out on your iPhone from a weight that stays there.
There is an identifier in exactly one place, and it is not this one: to check whether a subscription is active, the app generates a random identifier. It is described under Subscriptions and payment and is not sent along when you scan.
Why there is an endpoint of ours in between at all
So that the access key to the model provider is not inside the app. If it were, anyone could extract it and spend our money. The endpoint is a doorman, not another collector of data.
The IP address, and why we hash it
To stop anyone from draining the endpoint there is a daily limit of 120 analyses. Counting requires something to tell requests apart. We use the IP address for that — but we do not store it: it is passed through a one-way function together with a secret value, and only the result is stored. The IP address cannot be recovered from that result, and without the secret value it is worthless outside this project.
- Purpose
- Recognising what you logged; protecting the service against abuse
- Legal basis
- Art. 9 (2) (a) GDPR — your explicit consent. A photo of your meal, read together with your calorie target and your weight history, can say something about your health, so we treat it under the stricter rule rather than argue about whether it falls under it. Art. 6 (1) (a) applies alongside it. For the abuse limit, and only for that, Art. 6 (1) (f) GDPR; our legitimate interest is running a service we can afford.
- If you do not consent
- The app stays fully usable: logging by hand, the barcode scanner, the food database, the diary, goals and weight history all work without any transmission. What you lose is the recognition, not the app.
- Withdrawing consent
- At any time in the app’s settings, with effect for the future (Art. 7 (3) GDPR). Like everything described here, that applies from the first release; withdrawing is as easy as giving consent, and nothing you have already logged is lost.
No automated decision within the meaning of Art. 22 GDPR is made here. The model proposes; you can change every value before you save it, and nothing is decided about you on that basis.
Processing by artificial intelligence
This section stands on its own deliberately. The App Store guidelines require two things: that sharing with third parties be clearly disclosed — “including with third-party AI” — and that explicit permission be obtained before it happens. This section is the disclosure.
Consent is obtained before anything reaches the endpoint for the first time — that is how the app ships: the recognition only runs once you have agreed, separately for photos and for what you type. Without that agreement nothing is transmitted and only the recognition stops. The volume measurement is not affected by it at all; it runs on your iPhone and sends nothing.
Whatever you hand over is analysed by a third party’s AI model:
- Intermediary
- OpenRouter, Inc., USA — privacy notice
- Model
google/gemini-3.5-flashby Google, withgoogle/gemini-3-flash-previewas fallback. Other models are blocked on the server and rejected.- What the model receives
- one of three things, never more than one at a time: a photo of your meal, the food name you typed, or the workout you described — each with the text instruction that directs the model, and nothing else
- What the model returns
- for a meal, a list of suspected ingredients with estimated proportions; for a workout, how strenuous the activity is and how long it lasted
What we are not claiming here
We cannot assure you that what is transmitted is not used for training at the model provider. Whether and for how long it is processed there is governed by the terms of OpenRouter and Google, linked above. We write this down instead of making a promise we do not control.
And one difference we would rather name than smooth over: the intermediary’s own notice promises not to keep image files longer than a request needs. For typed text there is no equivalent promise. So treat the two free-text fields as what they are — text that leaves your device.
The practical advice that follows: photograph the plate, not the table, and type the food or the workout — not a diagnosis, a medication or anything about someone else. What is not in the frame and not in the field cannot be transmitted.
No model decides on its own what ends up in your diary: the amounts are corrected on your device using the measurement, and you can change every value before saving. How exactly that works is described on the method page.
Recipients at a glance
The table below names every service that gets to see any of your data. These are all of them — the list is not abridged.
| Recipient | What it sees | Purpose | Location |
|---|---|---|---|
| Supabase, Inc. | What it seesthe photo or the text you typed, while it passes through, and the hash of your IP address | PurposeRunning our analysis endpoint | LocationEU (Frankfurt, eu-central-1) |
| OpenRouter, Inc. | What it seesthe photo or the typed text, together with the instruction that goes with it | PurposeRouting the request to the model | LocationUnited States |
| Google LLC (Gemini) | What it seesthe photo or the typed text | PurposeRecognising the dish or the entry | LocationUnited States |
| Open Food Facts | What it seesthe scanned barcode number and your IP address | PurposeNutrition data for packaged products | LocationFrance |
| Apple Distribution International Ltd. | What it seespurchase and billing data | PurposeSelling and billing the app | LocationCork, Ireland |
| IONOS SE | What it seesthe server logs of this website | PurposeRunning the website | LocationGermany |
| Google Ireland Limited (Gmail) | What it seeseverything you send us by email | PurposeRunning our mailbox | LocationIreland |
Where a provider processes on our behalf, data processing agreements under Art. 28 GDPR are in place to the extent the processing falls under that provision. They bind the providers to confidentiality, to acting on our instructions, and to using the data solely for the purpose named here.
One exception, and it concerns our mailbox. Until our own domain is set up we use a free mailbox at Google Ireland Limited (Gmail), Dublin. For that service the provider acts as a controller in its own right, not as a processor for us, so no Art. 28 agreement covers it — which is why we say it here instead of letting the paragraph above cover something it does not. Anything you email us is therefore also subject to that provider’s privacy notice. If you would rather not use it, write to us by post; the address is in the imprint.
Every third party named here is therefore held to the level of protection this policy describes — including the limitation stated explicitly in the next paragraph. A promise reaching beyond what we can enforce would be no promise at all.
We name one exception explicitly: for the model provider this assurance only holds within its own terms. What happens there to a transmitted image — in particular whether it is used for training — is something we cannot guarantee. The section Processing by artificial intelligence says exactly that, and we repeat it here rather than promising something in one place and withdrawing it in another.
We do not sell data. We run no advertising, no cross-provider tracking and no analytics — neither in the app nor on this website.
Note on Apple and Google: their privacy notices are available from Apple and Google. We have no influence over their processing.
Transfers to the United States
Some of the recipients above are based in the United States. Below is what applies to each of them individually — because the routes are genuinely different, and a single blanket sentence would have hidden that.
| Recipient | Country | On what basis |
|---|---|---|
| Supabase, Inc. | CountryUnited States (company seat) | On what basisArt. 46 (2) (c) GDPR — standard contractual clauses |
| OpenRouter, Inc. | CountryUnited States | On what basisArt. 46 (2) (c) GDPR — standard contractual clauses |
| Google LLC (Gemini) | CountryUnited States | On what basisArt. 46 (2) (c) GDPR — onward transfer under the same clauses |
What that means in each case
- Supabase, Inc.
- The data itself stays in Frankfurt. A transfer only happens if Supabase reaches into the project from the United States for administration. Supabase is not certified under the EU-US Data Privacy Framework.
- OpenRouter, Inc.
- Not certified under the EU-US Data Privacy Framework. OpenRouter commits to the standard contractual clauses in its own privacy policy, and its data processing agreement applies to commercial users under section 10.2 of its terms.
- Google LLC (Gemini)
- Google LLC is certified under the EU-US Data Privacy Framework, but that certification does not carry this transfer: we do not send anything to Google ourselves. The data reaches Google through OpenRouter, so what applies is the onward-transfer clause of the standard contractual clauses.
For every one of them we have also assessed whether those clauses can actually be effective in the country concerned. You can obtain a copy of the clauses free of charge by asking us at noah.sioly.ug@gmail.com.
Where the table says standard contractual clauses, that is the mechanism the provider commits to in its own terms and data processing agreement — for OpenRouter, its terms apply that agreement to commercial users like us automatically. We name the mechanism that is actually in force rather than describing a contract we have not signed.
For the image analysis the transfer is also strictly necessary for us to provide the service you requested — an equivalent model hosted in the EU is not available to us.
What this means for you, stated plainly: the United States does not provide a level of data protection equivalent to the European one. Authorities there may under certain conditions access data, and the legal remedies available to people in the EU are limited. If you do not want that, do not use the scan function — every other feature of the app works without it and without any transfer.
Barcode lookup
If you scan the barcode of a packaged product, the app looks up its nutrition data at Open Food Facts — a non-profit open food database based in France.
What is transmitted is the barcode number. For technical reasons the service also learns your IP address, because without it no answer could come back. No photos and no diary data are transmitted.
- Legal basis
- Art. 6 (1) (b) GDPR — without the lookup there would be no nutrition data for the scanned product
- Provider’s privacy notice
- Open Food Facts
Subscriptions and payment
If you take out a subscription, payment runs entirely through Apple’s App Store. We never see payment data. Your card number, your billing address and your name do not reach us.
No subscription is running yet, because the app is not published. So nothing is transmitted for this purpose today — not even a purchase status. Once subscriptions go live, a service that checks them will appear in the table above and in this section, before the first one is sold.
You cancel a running subscription in the store itself: manage Apple subscriptions. We cannot technically do it for you.
Security in transit
Everything that travels between your device and us is encrypted in transit: both the request for this website and every request the app makes to our analysis endpoint. We use TLS (HTTPS) to current standards; unencrypted connections are not accepted.
The access key to the model provider is not in the app but on the server alone — that is why the endpoint exists in the first place. The IP address is put through a one-way function with a secret value before storage; only the result is kept.
Logs of the analysis endpoint
The endpoint keeps logs too — every server does, and leaving that out here would be the more convenient but incomplete answer. What is logged is technical: timestamp, outcome of the request, and error messages. The photo appears in no log. The calling IP address is read for the daily limit and stored only as a hash.
- Where
- Supabase, EU (Frankfurt, eu-central-1)
- Legal basis
- Art. 6 (1) (f) GDPR — legitimate interest in a secure, functioning and affordable service
- Retention
- a few days, then deleted automatically by the platform
This website
Different rules apply to cal3d.app than to the app — considerably less happens here.
No cookies, no analytics
This website sets no cookies, stores nothing at all in your browser — neither in local storage nor in session storage — and embeds no analytics services, advertising networks or tracking pixels. The typeface is served from our own server, so no connection to a font service is opened either.
That is why there is no consent banner: § 25 (1) TDDDG requires consent for storing information on your device — and nothing that falls under it happens here. A banner would suggest processing that does not exist.
You can verify this yourself in under a minute: open your browser’s developer tools on any page of this site and look at storage and network. Both stay empty apart from the files of this site itself.
Server logs
This website is hosted by IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany (privacy notice); the servers are located in Germany. When a page is requested, your browser transmits technically necessary information that the host logs briefly: IP address, timestamp, requested address, amount of data transferred, browser type and operating system. These logs serve secure operation and troubleshooting. They are not combined with other data and not used to build usage profiles.
- Legal basis
- Art. 6 (1) (f) GDPR — legitimate interest in technically sound and secure operation
- Retention
- usually a few days, then deleted automatically
When you write to us
If you send us an email, we process your address and the content of your message in order to answer it. That is unavoidable — no address, no reply.
- Legal basis
- Art. 6 (1) (b) GDPR for enquiries relating to the contract, otherwise Art. 6 (1) (f) GDPR — legitimate interest in answering enquiries
- Retention
- until your matter is settled, then at most six months for follow-up questions. Where commercial or tax law requires retention, the statutory periods apply instead.
Our mailbox is operated by Google Ireland Limited (Gmail), Dublin, Ireland (privacy notice). Technically, that provider sees everything you write to us — which is why it appears in the recipients table. Do not send us anything you would not want sitting there; for particularly confidential matters you can also reach us by post at the address in the imprint.
Job applications
If you apply to us, we process your application solely for the selection procedure: covering letter, CV, references and anything else you choose to send.
- Legal basis
- § 26 (1) German Federal Data Protection Act in conjunction with Art. 6 (1) (b) GDPR — deciding on the establishment of an employment relationship
- Recipients
- nobody outside the company; technically the operator of our mailbox (Google Ireland Limited (Gmail))
- Retention
- six months after the procedure ends, then deleted. If you would like us to keep you in mind for longer, say so — we will ask you first.
You may object to this storage at any time; we will then delete the correspondence unless a retention obligation prevents it.
Retention and deletion
What is kept for how long, at a glance:
| Data | Where | How long |
|---|---|---|
| Diary, profile, progress | Whereon your device only | How longuntil you delete it in the app or remove the app |
| Photo of a meal | Wherepassed through, not stored | How longnot at all with us; at the model provider per its terms |
| Hash of the IP address | Wherequota table | How longuntil the table is next cleaned up; never read again once the day rolls over |
| Website server logs | Whereat the host (IONOS SE) | How longa few days |
| Logs of the analysis endpoint | WhereSupabase, EU (Frankfurt, eu-central-1) | How longa few days |
| Job applications | Wheremailbox | How longsix months after the procedure ends |
| Emails to us | Wheremailbox | How longuntil settled, at most six months |
How to delete everything, step by step, is on the delete your data page.
Do you have to provide this data at all?
Short answer: no. There is no statutory and no contractual obligation to give us anything. You need not create an account, give a name or leave an email address — the app works without all of it.
What actually governs this is a technical necessity, not an obligation:
- Photo of a meal: no transfer, no recognition. If you do not want that, do not use recognition — the diary, the volume measurement, goals and progress carry on with no transfer at all.
- Barcode lookup: sends the barcode number, nothing else about you. If you would rather not, enter packaged food by hand.
- IP address at the endpoint: technically unavoidable; without it no answer can come back. Only its hash is stored, and only for the daily limit.
- Email address: only needed if you want a reply. Post works too.
So withholding data has one consequence only: the feature in question is not available to you. Nothing beyond that follows from it, and no contract fails because of it.
Your rights
You have the following rights in relation to us:
- Access (Art. 15 GDPR) — what data we process about you
- Rectification (Art. 16 GDPR) — correction of inaccurate data
- Erasure (Art. 17 GDPR) — the “right to be forgotten”
- Restriction of processing (Art. 18 GDPR)
- Data portability (Art. 20 GDPR) — a copy in a common format
- Withdrawal of consent (Art. 7 (3) GDPR) — with effect for the future
Honestly: with us, most of these come up empty
Because there is no account and your data sits on your device, we usually hold nothing we could give you access to or erase. Ask anyway — we will tell you exactly that, with reasons.
Requests to noah.sioly.ug@gmail.com. We reply within one month, as Art. 12 (3) GDPR provides.
Right to object
You can object
You have the right to object at any time, on grounds relating to your particular situation, to processing of your data that we base on Art. 6 (1) (f) GDPR (Art. 21 (1) GDPR). Four things here fall under that: the abuse limit at the analysis endpoint, the logs of that endpoint, the server logs of this website, and answering your emails.
If you object, we will stop processing the data concerned unless we can demonstrate compelling legitimate grounds that override your interests, or the processing serves to establish, exercise or defend legal claims. A plain sentence to noah.sioly.ug@gmail.com is enough; a reason helps us but is not a condition.
Right to lodge a complaint
You may lodge a complaint with a data protection supervisory authority if you believe we are infringing the GDPR. The authority responsible for us is:
Der Hamburgische Beauftragte für Datenschutz und InformationsfreiheitLudwig-Erhard-Str. 22
20459 Hamburg, Germany
datenschutz-hamburg.de
You may equally contact the supervisory authority of your habitual residence or place of work.
Children and young people
Cal 3D is intended for people aged 16 and over. We do not knowingly collect data from children under 16. If we learn that such data has reached us, we delete it. Parents and guardians can contact us at noah.sioly.ug@gmail.com.
Changes to this policy
When the app changes, this policy changes with it. The version published here is always the applicable one; the date of its last change is shown at the top of this page.
For changes that materially affect you — a new recipient or a new purpose, for instance — we additionally point them out inside the app rather than folding them in here quietly.
What has changed
- Initial version. It describes all three ways something reaches the AI model (a photo of a meal, a food name you type, a workout you describe), names your explicit consent under Art. 9 (2) (a) GDPR as the legal basis for them, gives every recipient outside the EEA its own transfer mechanism instead of one collective clause, and names the provider of our mailbox as a controller in its own right.
The list starts here: there is no earlier published version that this one could differ from.