What we can & can't see
Most "secure" apps stay vague here. We won't. Here's the plain truth about what's encrypted, what isn't, and what that means for you.
Your most sensitive fields are encrypted with a key we hold in AWS KMS — and decrypted only when you ask. That covers:
- Vault secrets — passwords, PINs, lock combinations, and codes.
- Financial account numbers and login passwords in the Finance section.
These are written to the database as ciphertext (gibberish like k1:AQID…), never shown in your lists, and unscrambled only in the moment you — signed in — tap to reveal one. They are never decrypted in bulk and never in the background. And because the key lives in AWS Key Management Service, every single decryption is logged in AWS CloudTrail, stamped with which user and which field — so any access is recorded and auditable, and the key can be frozen instantly if anything ever looks wrong.
Other fields are stored in plain form so the app can actually work. The label on a warranty, the name of a membership, where you keep something, a renewal date — the app needs to read these to show your lists and email your reminders. They're protected by account isolation, encrypted disks, and access controls, but they aren't individually locked the way the secrets above are.
- The key is separate from the database. It lives in AWS KMS, not in Postgres — so a database breach alone yields only unreadable ciphertext.
- Decryption only happens on your action. The protected fields are unscrambled in response to your own signed-in reveal — never swept in bulk.
- Every decrypt is logged and attributable. AWS CloudTrail records each one with the user and field, so misuse can't happen quietly.
- Least access, and separating duties as we grow. Production access is narrow today, and we're splitting database access from key access so that — by design — no single person can do both.
- You can keep anything to yourself. Mark any item private and it's visible only to you, even inside a shared household.
If a service ever tells you it's literally impossible for them to see your data, ask how their reminders and search work. Honesty about the limits is the difference between security and a sales pitch.
Is my money safe?
The scariest thought is "what if someone gets in and drains my accounts." Here's why Squirreld is structurally not that risk.
- Squirreld can't move money. It's a record-keeper, not a bank or a payment rail. It is not connected to your accounts and cannot transfer, withdraw, or spend a single dollar.
- A stored password is not access to your money. Even in a worst case, someone would still have to go to your actual bank and defeat its own login, two-factor, and fraud detection. Keep two-factor on your bank and email, and a leaked password alone gets nobody in.
- We never see your card details. Subscription payments are handled by Stripe; your card number never touches our servers.
- We never see your password to get in. You sign in with Google — we never receive or store your Google password.
How it's built
Squirreld runs on Supabase managed Postgres, with layered controls at rest, in transit, and at the row level.
- Encryption at rest (AES-256). Stored data and backups are encrypted on disk.
- A second lock for secrets (AWS KMS). The sensitive fields above get an extra layer of encryption with a dedicated KMS key before they're written — separately from everything else, and bound to a per-user encryption context so one user's ciphertext can't be decrypted as another's.
- Encryption in transit (TLS). All traffic between your browser, our servers, and the database is encrypted.
- Per-user data isolation. Every record is tied to its owner, and every query the app makes is scoped to the signed-in user. Row-level security is enabled on every table as defense in depth.
- Authenticated access only. Every API call requires a valid session token, and production data is reached only when needed.
Who else can see your data
By default, your data is yours alone. Sharing is something you turn on, item by item or household-wide — and it's built so it can't be used against you.
- Solo by default. If you haven't invited anyone, no other user can see your data, full stop.
- Household sharing is opt-in. On the Family plan you can invite a partner or trusted family member; they sign in with their own account and see what's shared — no shared master password.
- Private items stay private. Mark any item private and it's visible only to you, even within a shared household — and only you can change that.
- Read-only for others; only the creator can change or delete. A household member you share with can view a shared item, but only the person who created it can edit, delete, or re-share it. No one can quietly overwrite or wipe your records.
What we do with your data
The only parties who ever touch your data are these, and the list is complete:
- People you choose to share with. Members of your household, and only for the items you've shared with them.
- Service providers that run the product. Our database host (Supabase), our payment processor (Stripe), and AWS (for the encryption key and email). They process data on our behalf and may not use it for anything else.
- Valid legal requests. If we receive a lawful, properly scoped legal demand, we comply. Where the law permits, we'll notify the affected user first.
That's the entire list. No data brokers. No ad networks. No "analytics partners" rummaging through your vault.
If something goes wrong
No system is perfectly immune, and we won't pretend otherwise. What we commit to is honesty and speed if a breach ever occurs. Here is the plan, in order:
-
Contain & investigateCut off the access path, preserve forensic evidence, and determine the scope: who was affected and what data was exposed.
-
Notify affected users within 72 hoursAs soon as we have confirmed scope, we notify every user whose data was involved — directly, by email, within our committed window.
-
Tell users what was exposed and what to doPlain-language disclosure of which fields were involved, what risk that creates, and concrete steps each user can take (rotate credentials, freeze cards, etc.).
-
Fix the root cause and hardenAddress the underlying weakness, run a post-incident review, and ship the controls needed so the same class of failure can't happen again.
Reporting a vulnerability
If you've found a security issue, please tell us before disclosing it publicly. We read every report and respond as quickly as we can.