Privacy
Data Privacy in Nutrition Apps: What to Check For
A nutrition tracking app collects some of the most intimate data on your phone: what you eat, how much you weigh, which gym you go to, sometimes exactly where you are at a given moment. Where that data goes matters more than any feature list — a single sentence buried in a few thousand words of privacy policy (“your data may be shared with our partners”) can quietly change who actually owns years of your own history. The five questions below are a concrete checklist you can run against any nutrition or health app before handing over that history.
Question 1: Does it sell your data to third parties?
“Selling data” means something specific: a company paying — in money or something of monetary value — for access to user data. How common this is in health-adjacent apps isn’t a guess: Grundy et al.’s 2019 study in The BMJ examined 24 of the top-rated medicines-related apps on Google Play and found that 19 shared user data with outside companies including Google and Amazon, with that data potentially reaching advertising and credit-reporting firms further downstream. That study wasn’t about nutrition apps specifically, but it’s a real precedent from the same broad category — health-related mobile apps.
What to check: does the privacy policy name its “partners” explicitly, or does it hide behind a vague, boundary-less list? Cookrange’s privacy policy states, under its own heading in the CCPA section for US users, that it does not sell personal information for monetary consideration. Having that stated as a specific, standalone claim — rather than folded into a generic “we take privacy seriously” line — is what makes it checkable.
Question 2: Does it share data with advertisers?
Selling and advertiser-sharing aren’t the same thing — the second can happen with no money changing hands at all, through an ad-measurement pixel quietly passing behavioral data along inside the app. The right question here isn’t “does it sell,” it’s “what third-party SDKs or pixels actually run inside the app, and what do they collect?”
Cookrange’s sub-processors page lists the three providers currently in use (Vercel, Firebase/Google Cloud, Cloudflare Turnstile) one by one, and separately marks categories not yet decided — an email delivery provider, web analytics, a possible ad-measurement pixel — as “to be selected,” rather than inventing a name for a choice that hasn’t actually been made. Whether an app keeps a list like that, in the open, updated as it changes, is itself worth weighing.
Question 3: Is it actually compliant with KVKK and GDPR, or just claiming to be?
For an app operating in Turkey, Law No. 6698 on the Protection of Personal Data (KVKK) has been in force since 2016; for one with EU users, Regulation (EU) 2016/679 (GDPR) applies. The sentence “we comply with KVKK and GDPR” isn’t a guarantee on its own — what actually matters is whether that compliance cashes out into specific rights: access, correction, deletion, objection.
Cookrange’s privacy policy includes a table mapping each processing purpose to its corresponding legal basis under both KVKK (articles 5/6) and GDPR (articles 6/9), and separately defines access, correction, deletion, portability, objection, and restriction rights. Whether that’s sufficient is for the reader to judge — but it’s at least an itemized, checkable text rather than a single reassuring sentence.
Question 4: Can you export or delete your data?
Months, maybe years, of meal and weight history shouldn’t be locked inside one app. What to check: does the settings menu or a request process state plainly that data can be exported in a structured format, and that deleting an account actually deletes the data — not just hides it from view?
Cookrange’s privacy policy states that, alongside access and portability rights, data is deleted or anonymized within a reasonable period after account deletion, except where a legal retention obligation applies, and it defines a separate data-subject request process for these claims. A practical step when evaluating any app: check whether that process actually exists, and whether it runs through a structured form or just an email address that may or may not get a reply.
Question 5: Is your location data processed on-device, or sent to a server?
Of the five, this is the most technical and also the most concrete. A feature like “friends nearby” can be built two different ways: send the location coordinate to a server and compare it there, or compute the comparison entirely on the device and never send a coordinate anywhere. The second approach means there’s no central store of location data to leak, subpoena, or misuse — because it was never collected centrally in the first place.
Cookrange’s security page states that nearby gym/coach ranking is computed on-device, and that no coordinate is sent to or stored on a server. That’s not a vague reassurance — it’s a specific, architectural claim, and one that’s in principle verifiable by inspecting network traffic.
Five criteria, side by side
| Criterion | Weak signal | Strong signal |
|---|---|---|
| Data sales | Policy is vague or doesn’t address it at all | Answered explicitly, under its own heading, in the negative |
| Advertiser sharing | No list of third-party SDKs/pixels, or a hard-to-find one | Sub-processor/SDK list kept on a dedicated, updated page |
| KVKK/GDPR compliance | A one-line “we comply” claim | A rights-based, itemized process |
| Data portability | No export; deletion routed through a vague email address | Structured request process, exportable history |
| Location data | Silent on whether coordinates reach a server | States plainly, in technical terms, that processing happens on-device |
How do you check these five things in practice?
There’s a way to partially answer these five questions without reading a full privacy policy: both Apple’s App Store privacy labels and Google Play’s Data safety section summarize, before you even download an app, which data categories it collects and whether they’re linked to you. Those labels rest on the developer’s own disclosure rather than an independent audit — but they’re still a useful starting point, and a reference to cross-check against the policy text itself. One practical test: if the store label and the privacy policy disagree with each other, that disagreement is a warning sign on its own.
Frequently asked questions
Doesn’t a free app have to monetize my data somehow? A free tier’s cost doesn’t have to be data sales — ad impressions, upgrade prompts, or aggregated, de-identified reporting that isn’t tied to your identity are all alternative models. What matters is whether the app states plainly which model it’s actually using.
If an app says “KVKK compliant,” is that enough on its own? Not by itself — that sentence is a statement of intent, not an audit result. A more reliable signal is a text that itemizes which specific rights (access, deletion, objection) that compliance actually produces.
How would I verify a claim that location is processed on-device? Confirming this with certainty as an individual user usually requires network traffic analysis, which most people won’t do. But the specificity of the claim itself is a useful proxy: “we don’t collect location data” is vague, while “coordinate comparison runs on-device, nothing is sent to a server” is a specific technical claim — one that’s at least falsifiable, and therefore testable, in a way the vague version isn’t.
Where to start
These five questions apply to any nutrition or health app — Cookrange included. Cookrange’s own approach is laid out on the security and privacy policy pages; the app is still in internal alpha, and joining the waitlist is the way to try it early.