Security

Service controls

• Transport security — production traffic uses HTTPS and HTTP Strict Transport Security.
• Account isolation — Supabase row-level security scopes database reads and changes to the authenticated account; private storage paths are similarly owner-scoped.
• Authentication — Supabase handles password hashing and session rotation. Password recovery uses browser-bound callback state and a short-lived, one-use server proof.
• Sensitive operations — password change, export, upload, consent withdrawal, and account deletion require a current account and include application rate limits or confirmation controls.
• Browser hardening — production responses use a nonce-based content security policy with inline scripts blocked, plus clickjacking protection, MIME-sniffing protection, referrer controls, and a restrictive permissions policy. Inline style attributes remain allowed for data-driven meters and charts; script execution does not inherit that exception.
• Data minimisation — there is no advertising SDK, analytics tracker, session replay, public profile, or cross-user sharing feature.
• Native storage — the iOS offline ledger uses an OS file-protection class, is excluded from device backups, is separated per account, and can be removed from Settings.
• Assurance — releases are checked with type, lint, unit, build, browser-journey, accessibility, overflow, iOS test, and static-analysis gates.

Data resilience

The current Supabase plan does not provide automatic database backups. Users should keep an export of important records. A tested automatic or independent backup-and-restore arrangement is a required public-launch control; this page and the Privacy Notice must be updated when that arrangement exists. Private files and local caches also require their own deletion and recovery checks because a database backup alone would not cover them.

What you can do

• Use a strong, unique password and protect access to your email account.
• Do not follow an unexpected recovery link; start recovery from Ordivum yourself.
• Sign out on a shared device and remove its local data if you do not want an offline cache retained.
• Export important records periodically.
• Reset your password and contact us if you suspect unauthorised access.

Responsible vulnerability reporting

Email thomaswdelaney115@hotmail.com with “security report” in the subject. Include the affected page or app version, what you observed, safe reproduction steps, impact, and a way to contact you. Do not include passwords, session tokens, private user data, or a working exploit if a redacted explanation is sufficient.

We aim to acknowledge a report within five working days, triage it, and provide a status update when there is material progress. Fix timing depends on severity and complexity. There is no paid bug-bounty programme.

Safe-research boundaries

Good-faith research must:

• use accounts and data you own or have explicit written permission to test;
• stop immediately if you encounter another person's data and report that fact without retaining it;
• avoid denial of service, automated high-volume scanning, social engineering, spam, persistence, and destructive changes;
• avoid privacy violations, service degradation, physical harm, and disclosure before a reasonable remediation period;
• comply with the law and these boundaries.

We will not initiate legal action against good-faith research that follows these boundaries. This is not permission to test Supabase, Vercel, Open Food Facts, Apple, or any other third party; use each provider's own disclosure programme for its systems.

Limits and incident handling

No control makes an internet service risk-free. If we confirm an incident, we will contain it, preserve appropriate evidence, assess affected data and people, correct the cause, and meet any legal notification duties. Security reports are handled separately from data-protection complaints; the Privacy Notice explains the complaint route and ICO rights.