Security & Data Protection

1. Our Goal

Twin Leaf handles some of the most private information people have. We designed it so that the contents of your financial data are encrypted on your device and stored only in encrypted form, so that a breach of our database provider, a mistake in our database rules, or a curious administrator would not expose them. This page explains how that works and the cases where it does not fully protect you.

Pay statement PDFs are read in your browser and are never uploaded. See Section 3 of the Privacy Policy.

2. Encryption on Your Device

3. The Passcode Lock & Limits on Guessing

A six-digit PIN has only a million possibilities, so someone with a copy of your wrapped key could try them all offline. To prevent that, the key that unwraps your data key is derived from your passcode and from a value that only Twin Leaf's key service can help compute: an oblivious pseudorandom function (OPRF, over the P-256 curve). Angel Gate Solutions operates the key service on its own server in the United States. Your browser blinds the passcode (it sends a masked point, never the passcode), the key service applies a secret key derived for your account and sends the result back, and your browser removes the mask. The service never learns your passcode and the browser never learns the service's key.

• Every guess is a counted request. The key service counts each evaluation before it answers: the first five answer at once, each further one waits 30 seconds, then 1, 2, 4 minutes and so on up to an hour, and after 30 it refuses until an unlock is proven. A copy of the database, or a stolen sign-in session, therefore gets about 30 guesses at a passcode, not millions.
• A correct unlock resets the count, and only a proof can. After a correct passcode, the app sends a proof derived from your data key. The key service checks it against a hash stored in your own database record, which it reads with your own sign-in token (it holds no database credential). Saying "it worked" without the proof resets nothing.
• Only a verified sign-in is answered. The key service accepts only a valid Firebase sign-in token for your account (signature, issuer, audience, timing, and an Apple or Google sign-in) and checks with Google about once a minute that the session has not been revoked and the account is not disabled or deleted.
• Replacing your wrapped keys needs the data key. The database rules accept a replacement only with a write proof that can be derived only by someone who has already unlocked, so a stolen session cannot overwrite (and so destroy) your wrapped keys.
• It never receives your passcode, your recovery code, your data key, or your data, and it stores nothing per user except the attempt count, filed under a one-way tag.
• The service's secret is stored with owner-only permissions and backed up on encrypted storage. If it were lost, passcode unlock would stop working for everyone, but no data would be lost: each person would unlock with their recovery code and set a new passcode.
• Accounts created before October 3, 2026 used an older scheme (a static per-account value released to the signed-in browser). The key service releases that value only to an account whose keys are still in the older form; at the next unlock the app re-wraps your key under the new scheme, keeps your recovery code working, and the old value is never released again.

4. The Code You Run

Twin Leaf is a web app. Each time you open it, your browser downloads the code that performs the encryption from Firebase Hosting. Whoever can publish that code could, in principle, publish a version that captures passcodes or data. We reduce that risk as follows:

• Releases are built from our public source code, cryptographically signed (Ed25519) by our build system, and verified file by file on our server before anything is published. The credential that publishes the website is held only on that server.
• Every release is checked automatically and refused if it contains a private key, a client secret, analytics, inline scripts, or a weakened security policy.
• A strict Content Security Policy allows scripts only from Twin Leaf itself and Google's sign-in helper, limits connections to Google's sign-in and database services and our key service, and prevents the site from being framed.

These measures depend on our publishing systems remaining secure, and on us. If you need protection that does not depend on trusting the publisher, a web app cannot fully provide it.

5. What Remains Visible

Encryption hides the contents of your data. Some facts are visible to Angel Gate Solutions and to Google because they are needed to store and serve it:

• your sign-in details from Firebase Authentication (name, email address, profile photo link, provider, account identifiers, creation, last sign-in, and last token-refresh times);
• which calendar months have transaction documents (the document names are months, such as 2026-09);
• how many accounts, bills, budgets, goals, and import records you have, and whether optional records exist (they have fixed names: settings, categories, rules, alerts, paystubs, holdings);
• the size of each document — a month's size roughly reflects how many transactions it holds — and when documents were created and last updated;
• a revision counter on your overview document, used to stop two devices overwriting each other; and
• your wrapped keys, salts, and key-derivation parameters.

None of these is an amount, a merchant, a balance, or a category, but together they can reveal patterns, such as how actively you use Twin Leaf or whether you track investments.

6. Who Holds What

Twin Leaf's administrative credential and the key service's secret are held by Angel Gate Solutions with owner-only permissions and are never placed in code repositories, the build system, or the website. (Section 3 names the limits of that.)

6A. Optional Data Sharing

Help improve Twin Leaf is off by default. If you turn it on, it is the only path by which decrypted transactions leave your device: your device builds a de-identified copy (no names, account numbers, notes or person-to-person names), and our key service checks every field against a fixed list and refuses anything else. It stores the copy in files only that service can read, under a random number whose link to your account exists only in your encrypted settings; it does not store your user ID or IP address with it, and the log line for a sharing request carries no account tag. Turning the setting off deletes it. Details are in the Data Sharing Notice.

7. Isolation in the Database

Cloud Firestore enforces security rules on every read and write, independently of the app:

• Default deny. Only the paths named in the rules exist for clients. Listing users and cross-user queries are refused.
• Owner only. Every rule requires that the verified user ID in the sign-in token equals the owner of the data.
• Apple or Google only. Anonymous, password, phone, and other public sign-in methods are refused (and switched off). The only exception is our automated post-release self-test, which uses temporary test accounts that only our administrative credential can create, can reach only their own test data, and are deleted after each run.
• Encrypted only. Every document must have exactly the encrypted shape — a version, a 12-byte nonce, and ciphertext — plus server timestamps (and a month or revision number where named). Any other field is refused.
• Bounded. Each document has a size cap sized to what Twin Leaf writes (from 2 KB for an import record to 900 KB for a month of transactions), and a month's document name must be a real month from 1990 to next year by the server's clock, so one account cannot fill the shared storage and request quotas with made-up documents. This limits how much one account can write; it does not stop a determined person from using up Google's free daily quotas for everyone (Section 13).
• Wrapped keys are protected. Your wrapped-keys document can be created only once, can be replaced only with the write proof described in Section 3, and can be deleted only within 10 minutes of a real Apple or Google sign-in.
• No lost updates. A revision number must increase by exactly one per write.
• Paged reads. List queries must carry a small limit.

These rules are tested on every change against Google's Firestore emulator — including that one user cannot read, list, create, change, or delete another user's documents — and checked again against the live service after every release. They do not restrict Google or holders of our administrative credential, which is why your data is also encrypted.

8. Sign-In Security

Twin Leaf does not handle passwords. You sign in with Apple or Google through Firebase Authentication, so your sign-in benefits from their security, including two-factor authentication if you enable it. Deleting your Account, erasing your data, and other bulk deletions require a sign-in within the last few minutes: Twin Leaf asks you to sign in again first, and our database rules refuse those deletions without it. Your session stays on a device until you sign out, even while Twin Leaf is locked; anyone who can use that browser can reach your Account's encrypted data and make counted passcode guesses (Section 3). We recommend two-factor authentication on the Apple ID or Google Account you use, and signing out on shared devices.

9. Our Server

The key service accepts a fixed set of routes, verifies sign-in tokens itself, allows browser requests only from Twin Leaf's own web origins, caps request size and concurrency, and rate-limits by network address and by account. Twin Leaf also uses Firebase App Check with Google's reCAPTCHA Enterprise so that our database and key service can tell the genuine app from bots and scripts (see our Cookie Notice). It runs as a restricted, resource-limited service on a server operated by Angel Gate Solutions; that server also runs other services we operate.

Its logs record one line per request — time, route, result, duration — with a shortened keyed hash of the IP address and an account tag. They never include a token, key, email address, or financial data. Our Privacy Policy (Section 13) explains where log copies are kept and for how long, and why we treat the hashed IP address as personal information.

10. On Your Device

• Twin Leaf locks after 15 minutes without use; choose Lock now in Settings at any time.
• The local cache holds your data in encrypted form, plus the metadata in Section 5. Signing out erases it and your session.
• On shared or public computers, sign out when you finish, and do not let the browser save your passcode.
• If you use the optional email connection, your browser holds a short-lived, read-only Google access token in memory (never saved) and reads Gmail directly from Google; nothing is sent to our server. Disconnect when you finish on a shared computer.
• Encryption cannot protect your data from malware on your device or from someone using it while Twin Leaf is unlocked.

11. If You Lose Your Passcode or Recovery Code

• Forgot your passcode? Unlock with your recovery code, set a new passcode, and save the new recovery code.
• Lost your recovery code but know your passcode? Your data still opens with your passcode. The app cannot currently issue a new recovery code while you know your passcode, so take extra care, and export your transactions regularly.
• Lost both? We have no way to restore your access. You can delete the Account and start over from the lock screen.

12. Your Part

• Use a long, unique passcode (new passcodes need at least 10 characters). Letters are allowed; length is what makes it strong.
• Store your recovery code in a password manager or another safe place, separate from your devices.
• Protect the Apple ID or Google Account you sign in with, and turn on two-factor authentication.
• Keep your browser and operating system up to date.
• Be wary of phishing: Twin Leaf will never ask for your passcode or recovery code by email, text, or phone, and lives only at twinleaf-app.web.app (or a successor domain we announce in the app).

13. Known Limits

• Short passcodes and our own access. See Section 3.
• Session takeover. See Sections 3 and 8.
• Code delivery. See Section 4.
• Metadata. See Section 5.
• Compromised devices. See Section 10.
• The optional AI chat. A question asked in Coach Plus is decrypted on your device and sent, through our key service (in memory only), to our AI processor, Groq, with its zero-data-retention setting on. It is an exception to Device Encryption, off until you agree, and off any time in Settings. The optional one-time AI plan review sends the budget plan the app built in the same way. See Privacy Policy Section 9.
• Sign-in tokens after sign-out or deletion. A sign-in token can remain valid for up to an hour after the account is disabled, deleted or its sessions revoked. Our key service checks with Google about once a minute and refuses such a token, but the database rules cannot check revocation. A deleted account has no data to reach; if anything is written under a deleted account in that hour, we will delete it on request.
• Shared free quotas. Twin Leaf runs on Google's free plan. Anyone with a Google or Apple account can create a Twin Leaf account, and the database rules bound what one account can store but not how much it can read or write in a day. A determined person could use up the free daily quotas and make Twin Leaf unavailable until they reset (your data would be unaffected). We have not turned on Firebase App Check, which would make this harder, because it needs a third-party script on every page, which would change what we tell you in our Privacy Policy and Cookie Notice.
• The optional email connection. While you are connected, the Google access token is held in your browser's memory for up to about an hour. Software that can run inside the page, such as a malicious browser extension, could read it, or read your email through it, in the same way it could read anything else on the screen. The permission is read-only and the token is never stored or sent to us, and the site's content-security policy allows scripts only from Twin Leaf and a short list of named providers, but this is a limit of any web app. Email you let Twin Leaf read is not covered by Device Encryption while it is on your screen, and the emails themselves stay in your Google account under Google's security.
• No guarantee. No system is perfectly secure. We work to find and fix weaknesses, and we will tell you about the ones that matter.

14. Incident Response

If we learn of a security incident, we contain it, investigate it, fix the cause, and notify affected users and authorities as described in the Data Breach Notification section of our Privacy Policy. If an incident may have exposed both our database and the key service's secret, we will treat data protected by short passcodes as potentially readable.

15. Reporting a Vulnerability

If you believe you have found a security vulnerability in Twin Leaf, email support@angelgatesolutions.com with the subject "Twin Leaf Security Report" and enough detail for us to reproduce it. Please do not disclose it publicly until we have had a reasonable opportunity to fix it. We aim to acknowledge reports within 3 business days.

16. Contact