How we protect your weight data.

What we store and what we leave out

Two values per measurement. A date and a number with one decimal place, such as 2026-09-19 and 78.4. One measurement per day: saving again replaces the previous value for that date.

Optional weight plans and body measurements. A weight plan stores starting weight, target weight, target date and milestones. Height and waist measurements are stored only when entered. Each field is encrypted and bound to its context so a value cannot be moved into another field. BMI and projections are calculated in your browser and are not stored.

An optional journal. Your journal can contain daily notes, mood, motivation, a mantra, custom metrics and uploaded photos. Each day is encrypted as a document and each photo separately. Photos are resized in your browser and location and camera metadata are removed before upload.

Only the information you choose. Health features store information you enter or explicitly choose to import. Keeping the stored data limited reduces what could be exposed or retained unnecessarily.

A record of your consent. We record when you consented, the version of the text and whether you used the web or native app. The record contains no weight or journal values and documents your consent.

Why we ask for separate consent

Meal logging is part of the core service. Health data receives separate protection. GDPR identifies it as a special category under Article 9. The weight feature requires your explicit consent for a specific purpose.

Before entering weight, you see the consent information, an unchecked checkbox and a button that becomes available only after you tick it. Nothing is preselected. You can leave the feature unused and continue using the rest of the app.

You can withdraw consent. Go to Settings → Health data to withdraw consent and delete health data from the active database.

From your input to the database

What happens when you select ‘Save measurement’:

1. 1

   On your phone

   Values are held in the page's temporary memory while you use it. The app does not store them in localStorage or persistent drafts. Health responses use no-store to instruct the browser not to cache them. Files you export yourself may remain on your device.

2. 2

   In transit

   The hosted site sends data over HTTPS. Weight requests identify your account through authentication rather than a user ID in the URL.

3. 3

   Server validation

   The server checks authentication, active consent, a weight between 20 and 400 kg, and a date that is not in the future. If validation fails, nothing is saved. Fixed error messages do not repeat your weight value.

4. 4

   Encryption before storage

   The server encrypts the value with AES-256 before writing it to the database. Encryption and decryption happen in server memory. The database stores ciphertext.

5. 5

   In the database

   The stored value looks like v1:kX9…Qw== — encrypted text that requires the key to read. The date and account ID remain readable so the record can be located. The weight value does not.

6. 6

   When you view your chart

   The server decrypts the values and sends them over HTTPS for your browser to draw the chart. Normal weight endpoints require the owner's account. Optional sharing, when enabled, requires separate consent, a selected recipient and time-limited access.

Encryption explained

AES-256-GCM. AES-256 uses a 256-bit key. GCM adds authentication so tampered ciphertext is rejected during decryption. This protects stored values, but does not make the whole system immune to compromise.

The key is separate from the database. The key is supplied separately to the server and excluded from database backups. A database copy contains encrypted health values. Reading those values requires both the database and the key. Keeping them separate is an operational requirement.

Fresh randomness for each encryption. Two identical measurements produce different ciphertext because each encryption uses a new random nonce. Comparing ciphertext therefore does not reveal that two weights are equal.

Bound to your account. Your account ID is included in the authentication data. Moving the ciphertext to another account causes decryption to fail.

What a stored record looks like. An illustrative database record:

date        2026-09-19
account     4127
weight      v1:m2Q8k1xkYVIr9ZfA3sC0oR1kJ4NbXc7h9uQ2t5WdE8yGvLp…

The prefix v1: identifies the encryption format. The current implementation uses one key. Rotation requires planned re-encryption; replacing the key alone makes old values unreadable.

Who can see what?

Usage statistics count consent records and measurements. They do not calculate statistics from weight values: there is no population mean, distribution or grouping by body weight.

Deletion, consent withdrawal and export

Withdraw in settings. Settings → Health data → Withdraw consent and delete weight and journal data. The server removes measurements, plans, body measurements, calculation profiles and journals and records withdrawal in one transaction. Confirmation means deletion from the active database. Retry a failed request; completed deletion cannot be undone in the app.

If you delete your account, weight data is deleted along with meals, conversations and login details when account deletion is confirmed.

Consent records in the active database. Consent and withdrawal timestamps remain after withdrawal, without health values, to document consent history. They are deleted with the account.

Older backups. Deleting data in the app does not rewrite existing backups. They may still contain encrypted health data, readable by anyone holding both the backup and its encryption key. See the privacy policy.

Export your data. The same settings let you export measurements as JSON or CSV. Exported or shared files may remain on your device or with a recipient. Deletion in the app does not remove those copies.

Limits of protection

Encryption has limits:

Anyone with both the database and key can decrypt the values. Keeping the key separate and controlling access are essential. These requirements also apply to the operator.

Your screen. Values are visible on your device when you open a health page. Encryption cannot prevent someone looking at the screen. Weight values are kept out of the dashboard and menus.

Losing the key makes stored values unreadable. Key custody and recovery need their own protection. No encryption system removes operational risk.

The server processes plaintext briefly. Encryption and decryption happen in server memory. The health endpoints are designed to keep these values out of logs and error messages. This is server-side encryption, not end-to-end encryption.