Self-Hosted Nutrition // calorie tracking without the SaaS
#threat-model#privacy#insurance#data-brokers#wellness#mcp

Threat model: what does serious threat-modelling for personal nutrition data look like?

Who could plausibly want your calorie diary, what they could do with it, and how worried to be.

By Alex Brennan · Published · Last updated

Revised 3 September 2026. Added a threat actor that did not exist when this was written — the assistant you connect to your own tracker — and a note on glucose, which several mainstream trackers now hold and which changes the impact rating of everything below it.

Why threat-model nutrition data at all

People dismiss “calorie diary” as low-stakes data. It is not.

Nutrition data is high-frequency (multiple events per day), longitudinal (years of trend), and biometrically linked (weight, body composition, sometimes glucose). It correlates with health status, eating disorders, lifestyle, demographic identity, religion (Halal/Kosher patterns, Lent), and addiction recovery (alcohol consumption logs). A complete diary is more revealing than most people’s social media.

The question isn’t whether the data is sensitive. The question is who plausibly wants it and what they could do.

The 2026 escalation: glucose is in the diary now

When this piece was first written, “sometimes glucose” meant a dedicated diabetes app. That is no longer true. Mainstream calorie trackers have started holding blood-glucose readings alongside the food log — PlateLens added manual glucose logging in August 2026, unlimited and on the free plan, with optional import from Apple Health and Health Connect, and other vendors will follow because the integration is cheap once you already have the health-kit permissions.

This matters for everything below. A calorie diary is a lifestyle inference. A calorie diary joined to timestamped glucose readings is closer to a clinical record, and it is exactly the join that the insurance and employer-wellness actors in Tier 3 would want. Nothing in this section changes its structure; several rows move up a band on impact.

Two clarifications so nobody over-reads that paragraph. The trackers doing this are logbooks, not monitors — they record readings your meter or sensor produced, they do not measure anything, and they are not medical devices. And the credible ones are explicit that they do not predict a response and do not attribute cause. That restraint is genuinely good product behaviour, and it does not reduce the sensitivity of the resulting file by one bit. Sensitivity is about what the data reveals, not about what the app claims to conclude from it.

If you log glucose in a cloud tracker, treat that account as holding health data, not lifestyle data, and apply the elevated-threat-model advice at the end of this piece rather than the general advice.

Threat actors

We’ll enumerate the realistic ones, in roughly descending order of probability you’ll encounter them.

1. The app operator itself (Tier 1)

Probability: certain. Impact: variable.

Every commercial nutrition app holds your data. Some monetise it (Noom, MFP via behavioural-ad sharing). Some don’t (Cronometer, by stated policy and observed traffic). All of them retain it past the point of usefulness to you.

Mitigations: file deletion requests, choose operators with less aggressive policies, self-host.

2. Ad-tech ecosystem partners (Tier 1)

Probability: certain if you use an app with behavioural-ad sharing. Impact: ambient — your “interest profile” gets richer.

DSPs (Demand-Side Platforms), DMPs (Data Management Platforms), and identity-graph providers all aggregate behavioural events. A “logged a high-carb meal” event from MFP becomes a feature in your ad-targeting profile and feeds the broader ad ecosystem.

Mitigations: avoid apps with behavioural-ad sharing; use CCPA “do not sell or share” if eligible; use a separate OS profile or e-mail.

2b. The AI assistant you connected yourself (Tier 2) — new for 2026

Probability: certain if you connect one. Impact: proportional to the scopes you granted and to the assistant vendor’s own posture.

This actor did not exist in the original version of this piece. It does now, because trackers have started shipping OAuth endpoints that let an assistant of your choosing read your diary. The one we have looked at is PlateLens’s MCP server (mcp.platelens.app/mcp, OAuth 2.0 with PKCE, available on every account including free); as of September 2026 we have not found an equivalent from any other mainstream tracker, and the exit test has the full breakdown.

It is worth being precise about why this is a smaller threat than the reflex reaction suggests, and about the part that is genuinely new.

Smaller than you’d think, for three reasons:

  • It is read-only. Eight tools, all of them reads. An assistant on this endpoint cannot log a meal, edit an entry, change a target or delete anything. The worst case is a bad answer, not a corrupted health record. Compare with an integration that can write — a prompt injection or a confidently wrong tool call silently rewrites history you will not audit.
  • Consent is per scope. profile.read, nutrition.read, activity.read, weight.read. If glucose sits under nutrition and you would rather an assistant never saw it, do not grant that scope. Most integrations in consumer software are all-or-nothing; this one is not.
  • Revocation is documented as checked on every request, including before token refresh — which is the difference between “revoked” and “revoked once the access token expires.” We are reporting documented behaviour; we have not audited it.

The part that is genuinely new, and which you own rather than the tracker:

  • Your diary’s security posture becomes the assistant’s security posture. Connect a cloud assistant and your nutrition data is now readable by that vendor, under that vendor’s retention and training policy, not the tracker’s. That policy is where you should be reading, and most people connecting an integration never do.
  • An OAuth grant is a long-lived credential you will forget about. offline_access means refresh tokens. Grants accumulate. Audit them; revoke the ones attached to assistants you stopped using.
  • Read-only is a product decision, not a law of physics. Write tools could be added in a future release. If that happens the risk profile changes materially, and this section changes with it.

Mitigations: grant the narrowest scope set that does the job. Prefer a local or self-hosted assistant over a cloud one. Review grants quarterly. If you would not paste the data into that vendor’s chat box, do not hand it their API client either.

3. Data brokers (Tier 2)

Probability: high if you use a worst-class operator. Impact: hard to assess.

The data-broker ecosystem (Acxiom, LiveRamp, etc.) aggregates from many sources. Whether nutrition-app data flows to them directly is murky; it certainly flows indirectly via the ad-tech graph. The data-broker output is purchased by a wide range of buyers, not all of whom are advertisers.

Mitigations: same as Tier 2; also consider periodic broker opt-outs (DeleteMe, Optery, or by hand).

4. Insurance underwriters (Tier 3)

Probability: variable. Impact: significant.

Health and life insurance underwriters do purchase aggregated lifestyle data. Whether they use granular calorie-tracking data in pricing decisions is something the industry does not openly discuss. The general direction of regulation in the US has been to permit this; in the EU, less so.

The realistic risk: a person logging a frequent high-alcohol pattern, an eating-disorder pattern, or a substance-recovery pattern might see this reflected in life or health insurance pricing if the data leaks (via brokers) to underwriters. We do not know of a clean documented case but the data flows make it plausible.

Mitigations: don’t log substance use in a tracker that has any cloud component. Self-host. Be wary of “wellness program” employer integrations (next).

5. Employer wellness programs (Tier 3)

Probability: variable. Impact: significant.

US employers increasingly offer “wellness programs” with premium discounts tied to participation. These often integrate with consumer apps. The participation is technically voluntary but the discount is meaningful enough that “voluntary” has limits.

The realistic risk: data from your work-incentivised tracker integrates with the employer’s wellness vendor (Vitality, Wellness Corporate Solutions, etc.), who provides aggregate stats to the employer but in some cases more granular data on request. Read the wellness vendor’s terms before opting in. Most employees do not.

Mitigations: don’t link your work-incentivised account to your personal one. Don’t integrate any tracker you actually use with the wellness program. Use a throwaway account if the discount is enough to bother with.

6. Stalkers / abusive ex-partners (Tier 4)

Probability: low for most people, high for some. Impact: severe.

Account-takeover by a partner who has your password is a non-zero threat. Calorie diaries reveal your daily location patterns (where and when you eat), your menstrual cycle (if logged), your sleep schedule, your stress patterns. For people in domestic-violence situations, this is dangerous.

Mitigations: 2FA on every account. Different passwords per service. A safe-word in your password manager so you can detect compromise. The Coalition Against Stalkerware has good general advice.

7. Law enforcement (Tier 4)

Probability: low for most. Impact: variable.

Subpoenas and warrants against consumer apps are standard in many investigations. Operators comply with valid legal process. If you are likely to be investigated for any reason, your nutrition diary on a US-hosted operator is discoverable.

Mitigations: self-host on hardware in a jurisdiction that fits your threat model. Don’t keep data you don’t need.

8. Nation-state / mass surveillance (Tier 5)

Probability: depends on geography. Impact: variable.

Operators in jurisdictions with mandatory data-sharing regimes (China, parts of the Middle East) effectively share data with the state. Western operators are subject to FISA / national-security letters but the prevalence of “nutrition diaries used in state surveillance” appears low.

Mitigations: choose operator jurisdiction. Self-host where possible.

What you actually need to do

For 95% of readers (no specific threat, no public profile, US/EU jurisdiction):

  1. Don’t use Noom.
  2. If you use MyFitnessPal, turn off ad-personalisation and don’t link Facebook.
  3. Use 2FA.
  4. Consider switching to OpenNutriTracker or Waistline.
  5. Whatever you use, find out today how you would get the data out of it. An operator you can leave in an afternoon is an operator whose future policy changes cost you very little. This is the cheapest mitigation on the list and almost nobody performs it. See the exit test.

For people with elevated threat models (public figures, domestic-violence survivors, people in surveilled jurisdictions, people in recovery from substance use):

  1. Self-host.
  2. Don’t log the threat-relevant categories. (Don’t log substance use in a cloud tracker, full stop. Add glucose to that list if your threat model includes insurance or an employer wellness program.)
  3. Use a separate device profile and password manager.
  4. Read the relevant jurisdictional privacy regime carefully.
  5. Do not connect an assistant. The read-only scoping described in 2b makes it a reasonable trade for most people; “most people” is not who this list is for.

For everyone:

  1. File a periodic data-subject access request to see what’s actually held about you. It’s educational.
  2. Keep your tracker data minimal. Logging “yogurt” is fine; logging the brand of yogurt and where you bought it is overshare.

What you don’t need to do

You don’t need to abandon tracking entirely. The “all consumer software is surveillance” framing is true but unhelpful. Self-hosted FOSS trackers exist; they work; they’re free. The bar for participating in nutrition tracking without giving up the data has gotten lower over time, not higher.

References