Security Practices

Toothprint · Version 1.2 · Updated September 12, 2026 · Español

This page describes how the Services are protected. It is referenced by the DPA as the technical and organisational measures we commit to.

A note on how to read it. Toothprint is built by one person today. A security page written for a fifty-person company — on-call rotations, background checks, quarterly tabletop exercises — would be easy to write and false. What follows is what runs. Where a measure is not in place, it says so, and that is more useful to you than a list you cannot verify.

1. Who is responsible for what

We are responsible for the platform: the application code, the backend configuration, the security rules, the subprocessors, the build and release path.

You are responsible for your devices, your network, your credentials, who you let into your practice, and the lawful basis for what you upload. See the Acceptable Use Policy and the DPA.

2. What the system is made of

• Backend. Firebase and Google Cloud: Authentication, Firestore, Cloud Storage, Cloud Functions, Hosting. No servers of our own, which keeps the attack surface small.
• iPhone and iPad app. Native Swift, distributed through the App Store and TestFlight. It links Firebase Auth, Firestore and Storage, Google Sign-In and a geometry library. It links no analytics library and no advertising SDK, and analytics is disabled in the Firebase configuration file. That is a fact you can check in the build, not a promise.
• Web hub. A static build served from Firebase Hosting, talking to Firebase through the official SDKs.
• Heavy reconstruction. Runs on a GPU compute provider in the United States. See Subprocessors.

3. Getting in

• Firebase Authentication, with email and password or Sign in with Apple / Google.
• Tokens only. No password ever reaches our storage in readable form.
• Access is decided by Firestore and Storage security rules, evaluated on the server on every read and every write. A client that asks for something outside its practice is refused by the database, not by the app.
• Multi-factor authentication is not enforced for professional accounts today. It is available on the underlying identity provider and enabling it is on the list below.

4. Isolation between practices

Every patient, appointment and session carries the identifier of the practice that owns it. Rules compare that identifier against the practice of the account asking. There is no pooling of data between practices anywhere in the application layer.

This was verified end to end on 11 September 2026 with real accounts: a member of one practice reading their own patient succeeded; the same read from an account in a different practice was refused with a 403.

5. Encryption

• In transit. TLS 1.2 or higher on every client-server path. HSTS on the web surfaces.
• At rest. Google Cloud encrypts with AES-256 under keys it manages. There is no customer-managed key option today.
• Secrets. Production credentials live in a managed secret store, never in the repository.

6. File links, and why they are credentials

Files in Cloud Storage are reachable by a download link that carries a token. That token is a credential: anyone holding the link can fetch the file, and the storage rules do not apply to it. This is how Firebase is designed, and it is worth you knowing it, because it changes what "a link to a scan" means: forwarding one is handing over the file, not a reference to it.

What we do about it:

• A download link is never shared outside the practice that owns the case.
• Any rule that exposes a collection holding one is re-read and re-tested whenever the rules change, with the access tests described in Section 4.
• Tokens can be rotated, and rotating them invalidates every link issued before. We treat that as a normal operation, not an emergency measure.
• The structural fix — storing paths instead of links and signing a short-lived URL at the moment of serving it — is on the list in Section 12.

7. Backups and history

This section used to say that point-in-time recovery was enabled and that backups expire within 12 months. Neither statement was verified, and a security page is exactly the wrong place to write something you have not checked. What is actually true:

• We do not operate a backup configuration of our own. There is no point-in-time recovery setting, no scheduled export, and no backup bucket in the project. Google Cloud keeps its own infrastructure-level redundancy, which is not the same thing as a backup you can restore from on request, and we are not going to describe it as one. Enabling recovery is on the list in Section 12.
• What this means for you in practice: if a record is deleted, it is gone. There is no "restore from yesterday" today.
• The BigQuery copy described in Subprocessors keeps a version history. Account deletion runs against every one of its tables, and may take up to 24 hours to complete.

8. Logs

What the platform logs by default, and what it does not, because the difference matters:

• Administrative activity — changing a security rule, deploying a function, altering a configuration — is logged by Google Cloud automatically and retained for 400 days. That is the default and we have not shortened it.
• Data access — who read which patient record — has been logged since 12 September 2026. Google Cloud's Data Access audit logs are off by default; we turned them on for the database and for storage, with 90 days of retention. Before that date we could tell you who changed the system, not who read a record; since that date, both.
• Security-rule denials are visible in the Firestore usage metrics as counts, not as an itemised list of who was refused what.

We do not routinely read Customer Data. Where an investigation requires it, the access is deliberate, and since 12 September it is logged.

9. Building and shipping

• Dependencies are pinned by the Swift package resolver and reviewed when they move.
• Releases are signed: the app by Apple's distribution certificate, the sites by Firebase Hosting.
• Security rules are deployed from the repository, and the deployed ruleset is read back and compared before anything else is changed. We do this because we once believed the rules in the repository were what production was running, and they were not.

10. Reporting a problem

Write to hola@toothprint.ai with "security" in the subject. We answer within one business day. If you want to encrypt, say so in the first message and we will send a key. We will not threaten anyone who reports a vulnerability in good faith.

11. Incidents

We notify you of a personal data breach within 72 hours of becoming aware, under Section 8 of the DPA, and we tell you what we know at the time rather than waiting for a complete picture. There is one person on this rota today and that person is reachable by email.

12. What is not in place yet

We would rather list these than let their absence be inferred:

---

Updated September 12, 2026 · Version 1.2

Version 1.1, amended 12 September 2026. Version 1.0 was published on 11 September and contained statements that a review against the running system showed to be wrong. They are corrected here rather than quietly edited, because a published document that changes without saying so is worth less than one that admits it changed: a page that said no third party ran AI inference on patient material, while a patient-photo feature was sending faces to a generative model; a security page that claimed point-in-time recovery and 12-month backups that were never configured; a deletion promise that gave one timeline for three destinations that do not run at the same speed; and a three-year destruction promise with no machinery behind it.

Version 1.2, amended September 12, 2026. The analytics export to BigQuery stopped carrying the raw sessions collection — which holds patient identifiers and download links inside it, and a download link is a credential — and now carries a derived collection with nothing identifiable in it. The history already exported is kept separately, pseudonymised. This is written down because version 1.1 described the previous export, and describing it wrongly after fixing it would be version 1.0's mistake in reverse.