I'm happy to share my own use case. The app I mentioned, octo, is a writing app for developers. It is an offline-first PWA, and the primary storage is IndexedDB. The hosted version of the app (at octo.app) also syncs to Firebase when logged in via GitHub OAuth. Client-side encryption allows the user to keep their data secure on their own machine (when stored in IndexedDB) and also on any remote server (such as Firebase in this case). Because the data is encrypted on the client, the server never sees the data in plain text and therefore the website/server operators are not able to access the user's sensitive information. It's all just about privacy and keeping data in the user's hands.
So the key (user chosen password?) is only used client side?
Exactly. In this article, I just generated a new CryptoKey object, but it is totally possible to use deriveKey to create a CryptoKey object from something like a user-specified password (which makes way more sense in the real world).
How do you handle forgotten passwords or lost keys?
This is a great question, and it is the tradeoff for true privacy. There is no way to recover lost keys, because the keys are never transmitted to the server. This also means users cannot recover the encrypted data if they lose said key, because the data is never transmitted in plain text to the server. This is obviously a danger, and therefore it is typically opt-in for most applications. There are many other use-cases for client-side encryption, but the biggest appeal to me is the offering of choice to the user. If someone doesn't trust my server (or even their own browser) to store their plain text data, I absolutely understand and want to offer the best tools to help keep their data safe.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great summary! I'd love to hear about example use cases for client side crypto, if anyone in the community has them!
I'm happy to share my own use case. The app I mentioned, octo, is a writing app for developers. It is an offline-first PWA, and the primary storage is IndexedDB. The hosted version of the app (at octo.app) also syncs to Firebase when logged in via GitHub OAuth. Client-side encryption allows the user to keep their data secure on their own machine (when stored in IndexedDB) and also on any remote server (such as Firebase in this case). Because the data is encrypted on the client, the server never sees the data in plain text and therefore the website/server operators are not able to access the user's sensitive information. It's all just about privacy and keeping data in the user's hands.
That makes sense. So the key (user chosen password?) is only used client side? How do you handle forgotten passwords or lost keys?
Exactly. In this article, I just generated a new CryptoKey object, but it is totally possible to use deriveKey to create a CryptoKey object from something like a user-specified password (which makes way more sense in the real world).
This is a great question, and it is the tradeoff for true privacy. There is no way to recover lost keys, because the keys are never transmitted to the server. This also means users cannot recover the encrypted data if they lose said key, because the data is never transmitted in plain text to the server. This is obviously a danger, and therefore it is typically opt-in for most applications. There are many other use-cases for client-side encryption, but the biggest appeal to me is the offering of choice to the user. If someone doesn't trust my server (or even their own browser) to store their plain text data, I absolutely understand and want to offer the best tools to help keep their data safe.