What Happens to Your Health Data in Moow?
Privacy is not a promise in a headline. It is authentication, ownership checks, private storage, limited permissions, deletion paths, and honest disclosure of what remains under development.
By Moow Product ·
- Moow’s architecture keeps user-owned records behind authenticated API checks.
- Meal images use private storage; raw movement-camera recordings are not uploaded by default.
- Production privacy claims must be verified against the released system, not inferred from a prototype screen.
Start by naming the data
Moow can hold profile details, goals, measurements, meals, workout history, progress entries, private images, challenge memberships, and account settings. Planned wearable connections may add steps, sleep, heart rate, and provider identifiers. These records vary in sensitivity, but combining them can reveal routines and health-related patterns that deserve stronger handling than ordinary app preferences.
The product should collect a field because a defined feature needs it, not because it may become useful later. Camera and photo permissions are requested when the related feature is selected. Barcode scanning reads a product code without saving an image. The movement-analysis interface says raw recordings are not uploaded or saved by default, with on-device processing intended where supported.
Authentication is only the first boundary
In the production architecture, the mobile app sends an authenticated access token to the Moow API. The API derives the internal user from that token and applies ownership checks rather than trusting a user ID supplied by the client. User records live in the application database, with row-level security as an additional boundary. The public website is a separate surface and does not read private mobile health records.
Files are separated into private storage areas for meal images, profile images, community media, and temporary exports. Upload paths begin with the authenticated internal user ID and use generated identifiers instead of email addresses. The API authorizes a short-lived upload path, verifies type and size, and then attaches the storage reference. Local development may use a JSON and development-upload adapter, which must not be described as the production system.
- Meals, workouts, progress, and profiles are user-owned API records.
- Meal, profile, and community images use separate private storage containers.
- Permissions are requested in the feature flow rather than at first launch.
- Website blog accounts and mobile health records remain separate product boundaries.
What Moow must disclose before public release
A production privacy notice needs to identify the controller, purposes, categories of data, service providers, storage regions, retention periods, deletion and export processes, support route, and any model-training or analytics use. Wearable and photo-analysis features need their own plain-language explanations. If a provider receives data for analysis, that transfer cannot be hidden behind a broad “improve the service” sentence.
Security reduces risk; it does not make breach or misuse impossible. Moow’s current repository documents private buckets, ownership checks, limited permissions, and operational safeguards, but the final claim must match the deployed configuration. Users should be able to use core manual logging without granting optional camera, photo, community, or wearable access, and revoking a permission should have a predictable result.
Sources
Do not upload clinical documents, identification, medication labels, or other sensitive background details in a meal or community photo unless the feature explicitly requires them. Review permissions and sharing settings, and contact Moow support promptly if you suspect unauthorized account access.