I’m not super knowledgeable about encryption and have some questions about how Fission deals with it:
Why does Fission encrypt in the browser? I have assumed that browser storage is ‘protected’ by origin security measures but perhaps this is naive: are you able to describe any of the security risks of unencrypted data in IndexedDB?
If the app works offline, wouldn’t the key need to be stored in the same place as the encrypted data?
Are you able to talk about how encrypting everything impacts performance?
In general, we assume all the pipes are broken, and so encrypt by default.
While content may be cached locally, we built WNFS on top of IPFS so “where” content is, is unknown.
We use the WebCrypto API. Private keys are stored securely by the browser. So this works whether online or offline. More broadly — we use encryption and keys without a central server, so there is no “phone home” that needs to be online. If the keys match, things work.
Performance: I know @expede and @dholms did some tests around this. For the typical “small data” of the content of an app for a single user, it hasn’t been an issue so far.
In terms of performance, AES encryption is very quick (and ECC signatures/keysharing as well). Any performance hit from it is trivial in comparison to network operations: sending/receiving data over IPFS.
Something I don’t understand is that if the pipes are broken how can it be stored securely? I’ll check out the whitepaper to get an overview of how it all works together.
Indeed. There’s are benchmarks around on the internet (I can dig up the links if needed). It’s on the order of feeling “instant” for small files or music. It’s noticeable on human scales when you get to the GB range, where it’s some seconds (e.g. videos). Going into the TB range starts to get less great The way we’ve laid out storage means that you only need to decrypt a file at a time, not your entire file system, so we find that encryption time isn’t generally noticeable.
private keys are secured by the browser (non-exportable)
follows the principle of least access
So the user can hand over all of their data to a third party, but by default they get nothing. The user okays whatever subset of the filesystem they want to give out, and how powerful that access is (read only, append only, etc).
It’s this scenario that I was trying to imagine. With my mental model of how this works, I always thought that if a third party has access to your browser, they can just open the app and access the data (in the same way as an app with encryption that works offline and doesn’t require entering a password on launch): if this is the case I was wondering initially ‘why bother encrypting in the browser?’. I understand the non-exportable aspect now though. And if there is basically no performance difference then that’s great.
Yeah, exactly. Our goal is to do this in a way that is accessible across machines and stays online, but without giving us access to all of your stuff. If someone has physical access to your browser, all bets are off, but a single app would only have access to data you’ve given it, and the app itself can execute entirely inside the browser without a backend.
The way we’ve laid out storage means that you only need to decrypt a file at a time, not your entire file system, so we find that encryption time isn’t generally noticeable.