Security
What protects your data, and what it does not protect against. Both, on the same page.
In short
- Your password never reaches us.Your browser derives a fingerprint from it; that fingerprint is all that is sent.
- Your budget, however, is readable by our servers.That is what lets them do the arithmetic for you, on any of your devices.
- Nobody on our team accesses it.No admin screen returns the contents of a budget.
- Encrypted at rest.The disks holding the database and the backups.
- This is not end-to-end encryption.And we do not call it that. See what changed.
What protects your account
- The password. Your browser derives a fingerprint from it — PBKDF2-HMAC-SHA256, 600,000 iterations, 256-bit output — and sends only that fingerprint. Our server re-hashes it with Argon2id before storing it. The plaintext password never leaves your device, at any point.
- Two-factor authentication (TOTP). A six-digit code from your authenticator app, as a second step at sign-in. You can turn it on and off from your settings.
- Passkey. Fingerprint, face or device PIN instead of a password, through WebAuthn.
- Sessions. Refresh tokens live in the database, rotate on every use and can be revoked — signing out actually cuts access off, it does not merely forget.
- Transport. HTTPS/TLS on every exchange, no exception.
What our servers store, and what we see of it
Our servers hold your budget in the clear: accounts, transactions, envelopes, amounts, notes. That is what lets them work out your balances, what is available and your month ahead once and for all, instead of redoing the arithmetic in every browser — and it is also what makes a lightweight mobile version possible. Saying so is the precondition for everything else on this page.
What frames that access:
- The admin console only ever returns metadata. A record count, dates, a subscription state. No screen and no endpoint exposes the contents of a budget.
- Admin actions are logged — who, what, when, on which account. The log survives the deletion of the admin account that acted.
- Two rules we hold ourselves to. The console will not gain a budget-data screen. And if support ever needs one to help you, it will be with your explicit consent, and it will leave a trace.
Encryption at rest, and its limits
The database, the backups and the swap file live on an encrypted volume (LUKS). The backups are additionally encrypted with a public key whose private half is not on the server: a stolen backup stays unreadable, even for someone who takes the machine along with it.
What it does not do, and this part matters. A machine that is running holds its key in memory, otherwise it could not work. Encryption at rest protects against a recovered disk, a mislaid backup, decommissioned hardware. It does not protect against someone who gains access to the machine while it is running. That is not the same promise as end-to-end encryption, and conflating the two would be misleading you.
What changed on 25 August 2026
Until that date, Arca encrypted your budget on your device and our servers only ever saw unreadable bytes. We gave that up: as long as the server could not read, it could not compute anything — every device redid the entire arithmetic alone, and a lightweight mobile app stayed out of reach.
That is a step back in privacy, not an improvement in disguise, and we would rather write it here than let the word “encrypted” suggest otherwise. What you get in exchange: a forgotten password no longer destroys your budget, a new device gets everything back with no ceremony, and sharing a vault no longer requires a key exchange.
What this does not protect against
Said plainly, because a security page that lists only strengths is an advert.
- Us, if we decided to look. Nothing in the technology stops us any more — only our rules, the fact that no screen allows it, and the log. That follows directly from the section above.
- Someone using your unlocked device. If your session is open, your budget is open.
- A court order. We hold your data; we therefore cannot claim to be unable to hand it over.
- An audit we have not had. Arca has not undergone an external security audit. When it does, it will be written here, with the report.
What you can check yourself
The rest of this page is verifiable in our code. The headers below are verifiable from your own machine, without taking our word for it:
curl -sI https://arcabudget.app/security/- HSTS (
strict-transport-security), two years, subdomains included, preloaded. Your browser refuses to reach us over anything but HTTPS — even if you type the address without the “s”, even the very first time. - A strict content policy. The site loads scripts only from its own domain, and each inline script is allowed by its hash.
nosniff,X-Frame-Options: DENY,Referrer-Policy,Permissions-Policy. No guessing a file's type, no display inside a third-party frame, and no geolocation, microphone, camera or payment granted to the page.
Surveyed on . These headers are set by our web server: if one were to change, this page might say so late — the command above never does.
Reporting a vulnerability
Write to privacy@arcabudget.app, describing what you found and how to reproduce it. The same details are published in the standard format at /.well-known/security.txt.
What we ask: give us time to fix it before publishing. What we do not promise: a response time, or a bounty — Arca has no reward programme. Saying so beats letting you assume otherwise.
The format is open
Vault contents follow a published schema, arca.vault.v1. Your export is that format — readable by anything that implements it, not just by us — your vault is never tied to a single program.