Lose It! 'Snap It' and the cloud photos question
Where do your meal photos go when you tap the camera button, and how long do they stay there?
What we’re trying to answer
Lose It!‘s “Snap It” feature lets a user point the phone at a meal, snap a photo, and have the app return a calorie estimate. The feature has been around since 2015 and is one of the older photo-based estimators in the consumer space.
Two questions:
- Where does the photo actually go?
- How long is it kept, and what is permitted to be done with it?
Traffic capture
Methodology: standard (/methodology/). Pixel 7a, GrapheneOS, sandboxed Play Services, mitmproxy, certificate pinning bypass via Frida. We snapped 20 meals over a two-day session in January 2026.
Outbound destinations during a Snap-It session:
| Destination | Category |
|---|---|
| api.loseit.com | First-party API |
| ml-api.loseit.com | Image classifier endpoint |
| s3-us-west-2.amazonaws.com (loseit-mlimage bucket) | Photo upload |
| crashlytics, firebase, branch.io, segment, amplitude | Standard telemetry |
The photo upload goes to a loseit-mlimage bucket on AWS S3 in us-west-2. The bucket appears to be a buffer for the classifier; the call pattern is upload-then-fetch-result. The S3 PUT URL is signed and expires in 5 minutes.
We could not directly observe the deletion. Whether the bucket retains, archives, or trains-against the uploads is not visible from the client-side traffic alone.
What the EULA / privacy policy says
Reading the policy as of January 2026:
- “Photos uploaded for analysis may be retained for product improvement, including model training.”
- “We may retain de-identified imagery for research and training purposes.”
- “Such imagery is not associated with your account in any user-facing system.”
The combination is that photos appear, by stated policy, to be retained at least de-identified for model-training purposes. Whether the de-identification is robust against re-identification (faces in the background, identifiable kitchens, EXIF metadata) is not addressed.
Spot check: we examined the EXIF on photos as they left the device. Geotag was present in 8/20 captures, despite the OS-level geo-permission for the app being denied (the EXIF was already in the file produced by the camera). The Lose It! app does not strip EXIF before upload, in our observation.
What this means
If you use Snap It:
- Your meal photos go to AWS US-West-2.
- They may be retained indefinitely for model training, in a “de-identified” form.
- EXIF, including geotag if not pre-stripped, is uploaded as-is.
- The privacy policy does not commit to a deletion timeline.
- A GDPR/CCPA deletion request might (untested) result in removal from active stores; we have not verified the model-training corpus is also affected.
This is materially worse than a tracker that processes photos on-device. It is materially worse than a tracker that does not handle photos at all.
What other photo trackers do
We surveyed five other commercial trackers that handle meal photos:
| App | Photo destination | Retention statement |
|---|---|---|
| Lose It! | AWS S3 (US-West-2) | Vague; permits model training |
| MFP (where supported) | First-party + AWS | Brief retention statement, vague |
| Bitesnap | First-party | Limited statement |
| FoodSnap-Lite (FOSS) | n/a (no photos) | n/a |
| OpenNutriTracker (FOSS) | n/a (no photos) | n/a |
Note: PlateLens, which is also relevant in the photo-recognition space, is covered in our commercial-vs-FOSS state of the art piece. We do not audit it in this article. Their public position is that they retain a sub-week active cache and a separate consented research corpus. We have not independently verified those claims at the traffic level. Anyone interested should ask them directly.
Practical advice
If you use Snap It and want to limit exposure:
- Strip EXIF before any upload. There are FOSS Android apps for this; many don’t survive the permission gauntlet to capture-then-upload directly.
- Don’t use Snap It in places that visually identify you (your kitchen, your office).
- File a CCPA “do not sell or share” request if eligible; it may be respected.
- File a GDPR Art. 17 erasure request periodically.
If you specifically want photo-based recognition with documented retention limits, that is a separate evaluation. We don’t recommend a particular product in this piece.
If you want to avoid photo uploads entirely, OpenNutriTracker and Waistline don’t have photo-recognition features at all.
A note on FOSS replacement
We have prototyped on-device meal recognition twice using open-weight vision models. Both prototypes ran on a Pixel 7 with a quantised model around 800 MB. Performance was poor — roughly 30% MAPE on a weighed bench. The technology is not yet good enough at the FOSS level to replace what commercial photo recognition does, even when the commercial photo recognition uploads everything to a US-West-2 bucket.
References
- Lose It! privacy policy: loseit.com/privacy
- mitmproxy: mitmproxy.org
- ExifTool: exiftool.org
- Methodology
- Privacy comparison of six commercial apps