Data protection

We believe that data durability, privacy and security are important for financial records, as your financial data is sensitive and irreplaceable. This document explains the three pillars of our data protection approach and answers the most common questions about what happens to your information.

1. Durability

All your financial records are stored in AWS S3, which provides 99.999999999% (11 nines), meaning that if you store 10 million objects, you can expect to lose only one object every 10,000 years on average. That means your data is virtually indestructible. We organize your data by year, with each year’s transactions stored as a single, durable object.

We have versioning and object locks technologies enabled in S3. Versioning allows us to restore your data to any given state in the past. We keep 28 days of versions. Every time you upload data, the new version is created, meaning it is technically possible for us to rollback to a version prior to that should the uploaded data be corrupted or otherwise malformed.

Object locks ensure that nobody can erase or overwrite your data. This creates what is called a WORM model - Write Once, Read Many. Think of it like writing in stone - once written, it can’t be erased or changed. The lock on every object is set to 28 days, and is prolonged every 2 weeks for another 28 days for the latest version of the object to ensure that all your historical records are kept indefinitely until you decide to delete an accounting book or user account. The benefit is that even operational or administrative mistakes are impossible, not even talking about malicious attempts to erase the objects.

AWS S3 is configured with cross-regional replication. The primary region where the data is written is Frankfurt, with live-replication to Ireland and US East regions. Ensuring that even in an event of loss of the whole region, which is extremely unlikely, you can still access your records.

Your data stored in AWS S3 is self-contained, meaning that if we happen to lose our primary database despite the nightly backups, or go out of business due to a disaster, we can always hand off your encrypted data to you directly from AWS S3. As long as you have your book secret keys, you will be able to decrypt and access your data.

2. Privacy

The application is built using end-to-end encryption technology, also known as client-side encryption. No financial data leaves your computer without being encrypted first. Contrary to encryption in transit and at rest, it is technically impossible to access your records on our side. Only the owner of the book secret key can read the data.

To achieve that, we leverage well-known cryptographic primitives. The encryption algorithm used is XChaCha20-Poly1305 with 256-bit encryption key. This allows for higher performance compared to AES-GCM, yet not compromising on security, which is particularly relevant when encryption is happening on your computer, and the data is re-encrypted every time you upload your changes to the servers.

Every uploaded object contains a random 192-bit number used once required for encryption algorithm for security reasons, making the object self-contained. Each encrypted object is tied to your specific account, preventing mix-ups or substitutions, in other words it is cryptographically bound to the book and the name of the file. For extra security, we generate truly random keys for every accounting book.

We employ a method called envelope encryption to store your data encryption keys. It can be thought of as having a safe (your data) stored in secure premises (our servers), where the combination to that safe is known only to you. In more technical terms, your data encryption key (DEK) is encrypted with key encryption key (KEK), and then stored on our server for easier access. The KEK is derived from your authentication credentials, and allows you to access your books without reaching out to your book secret key backup as long as you don’t reset your authentication credentials. Upon reset, you will need to enter the DEK from the backup to regain access to your data. You can think of envelope encryption and server-side storage of encrypted DEK as a convenience feature.

As for general privacy, we collect minimal information for service operation. All our analytics are relying purely on operational metadata without collecting any extra information. Your username, email, and public keys are stored encrypted in our database to protect from data breaches. Even if the attacker manages to acquire data stored in our database, they will be unable to extract identifiable information.

3. Security

While end-to-end encryption with reliable object storage ensures that even we cannot read or erase your data, the overall security posture of the application has to be maintained. Because your keys are derived from authentication credentials, which can be a username and a password, we need to make sure that the password is not exposed anywhere, because the leak of the password would break the encryption we put in place - the attacker will be able to decrypt the DEK on the server side and hence read all your data.

Every authentication-related request, or request to change data on our servers, including data uploads, is digitally signed using your private key, stored locally on your computer. The server keeps track of public keys, allowing it to verify the digital signature of the request. That means, to authenticate with the server, no shared secret is sent over in the HTTP requests. Moreover, when you upload the data, the attacker won’t be able to replay the request, even in the event of the man-in-the-middle attack, when the secure connection between your browser and the server is compromised.

Digital signatures are made using standard algorithms: Ed25519 and ML-DSA 65. Both algorithms are used simultaneously, providing the security guarantees of both the conventional and post-quantum digital signatures. While standard digital signatures are extremely hard to forge, we choose to use the post-quantum algorithm as an extra measure to future-proof the protocol.

Unlike many end-to-end encrypted applications, we allow for a credentials reset process. To reset credentials, an email is sent with a reset link. To protect from an attacker gaining access to your email address and therefore getting hold of an account, we lock out the application after credentials reset for two days, preventing any uploads or other modifications. If someone else gains access to your user account, they won’t be able to access your data without knowing your book secret keys. If you prove the ownership of keys by entering them in the application form, you can still use the application offline - read the data, make local changes, but not upload them until the lockout ends.

Another angle where we protect the application is the integrity of the code that is executed in your browser. We make use of SRI technology to ensure that the assets pulled from a CDN are exactly the assets that were released during our build process. In addition to that, we employ standard browser security configuration, such as content security policy.

Note, that it is technically possible for us to inject malicious code to the web client, and thus gain access to your records. It is technically possible for any end-to-end encrypted service to do that, as long as they control the releases. In most cases, even open source won’t help, as the code injection may happen during the release process. We’ve designed multiple layers of protection, and like other reputable services, we operate on a foundation of trust and transparency.

What that means for you

In practical terms, our design delivers:

• Your data survives anything. Even if our entire service disappeared tomorrow.
• True privacy. We cannot read your financial data, let alone any unauthorized party.
• Defense in depth. Multiple security layers protect against sophisticated attacks.

We designed this application because we believe your financial data safety should not depend on promises or be exposed to risks of data breaches - it should be technically guaranteed.