Local storage security (encryption at rest of browser's IndexedDB)

[elijh]

Regardless of how workspace data is saved in the cloud, either AFFiNE hosted or self-hosted, a ton of data is saved locally in the browser's IndexedDB. For some use cases, it can be an important security issue to not have your workspace data available to any process on your local machine that can read the browser's IndexedDB files.

As I read the code, currently the web app uses the npm library idb as a light wrapper around the native IndexedDB in the browser. This does not support any local encryption of the database at rest.

Happily, there other libraries, such as secure-webstore that supports encryption of IndexedDB at rest.

This still leaves open the question of how the symmetric key for IndexedDB encryption is derived. One option might be to create it randomly and store it in an app-bound encrypted cookie. Not ideal, since still vulnerable if the browser's master key is leaked, but much much better. An even better method would be to simply store a random key on the server. The server already has access to the workspace data, and our goal here is just to protect it while at rest on the client device.

Side note: There has been some confusion in the past regarding what end-to-end encryption means (see #6160). One way to read that thread is to assume that the developers behind AFFiNE are grossly misrepresenting the security features of AFFiNE. I read it as more of a language issue. Regardless, full end-to-end encryption, where all data is encrypted in the cloud storage such that the storage provider cannot read it, is a real challenge, mostly because it requires a secure way to store private key material. In the case of webapps, the code is just loaded from the server anyway, so true e2ee is not strictly possible.