Security & Sub-processors

A summary of how we keep your data safe — what we encrypt, who we trust to operate parts of the service, how we respond to incidents, and how to disclose a vulnerability to us responsibly.

Effective date: 9 May 2026 · Last updated: 9 May 2026

1. Architecture at a glance

• Mobile app — Flutter (Android & iOS). Talks only to our Supabase project over TLS 1.2+.
• Backend — Supabase (Postgres + Auth + Storage + Edge Functions). Every table containing user data has Row-Level Security (RLS) enforced.
• AI inference — Microsoft Azure OpenAI Service, enterprise tier. Reachable only from our Edge Functions, never directly from the device.
• OCR — Google ML Kit on-device. Report images do not leave the device for OCR. Only the resulting text is sent to AI.
• Translation — MyMemory for short strings; Azure OpenAI for longer texts.
• Authentication — Google Sign-In and Sign-in with Apple (ID-token flow). We never see your password.
• This website — Firebase Hosting, static files only. No analytics, no third-party scripts, strict Content-Security-Policy.

2. Encryption

• In transit: TLS 1.2 or above with modern cipher suites between every component (device ↔ Supabase, Edge Functions ↔ Azure OpenAI, Edge Functions ↔ MyMemory, browser ↔ this site).
• At rest: Supabase Postgres and Storage encrypt data at rest with AES-256-equivalent provider-managed keys. Backups are likewise encrypted.
• On device: auth tokens and the active-profile pointer are stored in iOS Keychain and Android EncryptedSharedPreferences via flutter_secure_storage. Other local data lives in a Hive box namespaced per signed-in user; on sign-out the box is wiped before the OS notifies any background sync.
• Screenshot & recording protection: on Android, screens that display identifiable health information set FLAG_SECURE so the OS blocks screenshots and screen recording.

3. Access control

• Every Postgres table that holds user data has RLS policies that scope access to auth.uid() and to explicitly-shared rows.
• Service-role keys (which can bypass RLS) are held only in our Edge Function environment and never embedded in the app.
• Administrative access to Supabase is limited to the developer, gated by hardware-backed multi-factor authentication and scoped to the minimum permissions needed to operate the service.
• All admin actions are recorded in the Supabase audit log, which is retained according to Supabase's standard policy.

4. Sub-processors

We use the following sub-processors to deliver the app. Each has signed a data-processing agreement (DPA) consistent with the GDPR / UK GDPR / DPDP Act, and where relevant has agreed to the European Commission's Standard Contractual Clauses (2021).

We will give notice before adding a new sub-processor that processes a meaningful new category of data, and we will offer EEA / UK / India users a way to object before the change takes effect.

5. Vulnerability disclosure

We welcome responsible disclosure of security issues. To report a vulnerability:

1. Email contact@fcappstudio.tech with subject line [Security].
2. Include a clear description, reproduction steps, and any proof of concept. If the issue is sensitive, request our PGP key first.
3. Give us a reasonable time to investigate and remediate before any public disclosure (we aim for 90 days; sooner if the fix is straightforward).
4. Do not access or modify other users' data, do not run automated scanners that degrade availability, and do not publicly disclose the issue while we work on a fix.

We will acknowledge receipt within 72 hours and provide a remediation timeline within 7 days. We do not currently run a paid bug-bounty programme but we will publicly credit researchers who agree.

6. Incident response

Our incident-response procedure is summarised below.

1. Detect & triage. Logs, alerts, or a third-party report identify a possible incident.
2. Contain. Compromised credentials are rotated immediately. The affected component is isolated.
3. Assess. We determine which records were affected, the categories of data involved, and the likely impact.
4. Notify. If the incident is likely to result in a risk to your rights and freedoms, we notify the relevant supervisory authority and you, as required by law (within 72 hours under GDPR; without undue delay under the DPDP Act).
5. Remediate. We deploy the fix and verify it.
6. Review. We carry out a blameless post-mortem and update our controls.

7. Secure-by-default mobile build

• App is built with R8/Proguard minification and resource shrinking on Android, and with bitcode and symbolication on iOS.
• Network security config enforces HTTPS-only traffic; cleartext traffic is disabled.
• Dependencies are pinned in pubspec.lock and reviewed before each release.
• The release pipeline rejects any debug build that ships secrets, and our .env file is git-ignored.
• Supabase service-role keys and Azure OpenAI keys live only in the Edge Function environment, never on the device.

8. Out of scope

The following are outside our security boundary:

• The security of your Google or Apple account that you sign in with.
• The security of any device you root, jailbreak or run with developer mode enabled.
• The security of third-party services to which you choose to send your data (for example, when you share a report through WhatsApp or email).

9. Contact

For security questions, email contact@fcappstudio.tech with subject [Security].