MyWeightTracker Privacy Policy
This policy explains how MyWeightTracker handles account information, meal photos, food-recognition results, subscriptions, and related app data.
What We Collect
- Account information such as your email address, Firebase user ID, and optional display name.
- Meal photos when you use cloud-backed food analysis.
- Food-recognition results, corrections, and related telemetry used to operate and improve the app.
- Locally stored profile and meal-log data on your device, including optional weight and goal information.
- Subscription status through RevenueCat and app-store billing platforms.
- Advertising and device identifiers used by Google AdMob on supported free-tier experiences.
How We Use Data
- Authenticate users with Firebase.
- Analyze meal photos and return food-recognition and nutrition estimates.
- Store meal history and support app features such as corrections, subscriptions, and settings.
- Measure inference quality, latency, and correction patterns.
- Show ads and manage premium entitlements where applicable.
Where Data Is Processed
- Firebase Authentication handles sign-in and identity records.
- Cloud inference uploads meal photos to backend infrastructure and Cloudflare R2 storage when that path is used.
- RevenueCat and the Apple App Store / Google Play Store handle subscription billing events.
- Google AdMob may receive advertising identifiers and related ad-request metadata.
Some analysis can also run on-device. When on-device inference is used, the photo does not need to be sent to the backend for recognition.
Images, EXIF, and Location
When a meal photo is uploaded through the backend, the current server code re-encodes the image before storage. That process strips EXIF metadata, including GPS location metadata, before the sanitized JPEG is written to Cloudflare R2.
MyWeightTracker does not request fine location permission from the app for calorie tracking features.
Diagnostics and Telemetry
The backend stores operational and model-quality data such as latency, confidence, prediction metadata, and user corrections. Telemetry uses a pseudonymized subject identifier derived from your Firebase user ID with server-side HMAC hashing.
As of the code state reflected by this repository, no external mobile crash-reporting SDK such as Firebase Crashlytics or Sentry is wired into the shipping app code.
Advertising and Subscriptions
MyWeightTracker integrates Google AdMob and RevenueCat. AdMob may use the Android advertising ID and related ad-request metadata. RevenueCat and the app stores handle subscription purchase and renewal data.
Payment card information is not stored by the MyWeightTracker app backend.
Retention and Deletion
Data stored locally on your device remains there until you delete it, sign out and clear app state, or remove the app.
For server-side account deletion, the current backend contract is
POST /v1/auth/account/delete. In the code currently in this
repository, that workflow marks the account pending_delete,
sets a purge_after timestamp 30 days out, and revokes
Firebase refresh tokens immediately.
A daily backend purge job then deletes the user's application rows from the database after that grace period and attempts Firebase account deletion and Cloudflare R2 image cleanup afterward.
Local device data can still remain on your phone until app state is cleared or the app is removed. Server-side deletion and local-device cleanup are separate steps.
Your Choices
- You can sign out from the app at any time.
- You can request account deletion from the in-app Settings delete-account flow.
- A self-serve export flow is not implemented in the current repository state.
- You can manage subscription billing through the relevant app-store account.
Contact
Support and privacy contact details are configured outside this repository. Use the contact method listed in the published app store listing or official MyWeightTracker website when available.