3 ms·
Assuming you are storing only encrypted data on the server and cannot read it without the user's password, what happens if the user loses their password? Are th
by n0us 10y ago
Assuming you are storing only encrypted data on the server and cannot read it without the user's password, what happens if the user loses their password? Are they just left with a bunch of unreadable data that came from the server?
Doesn't this approach also make it difficult to share information between other users?
Having offline-first, client side encrypted apps seem to have a lot more problems than just "you know who" spying on you.
- geofft 10y agoThe big use case for this would be for workplace use, not for social / community use. In that case, since it's the company's account system (whether it's actual SSO, or just access to the email account where password resets go) that authoritatively identifies users, it's reasonable for the company's IT department to have a way to issue replacement keys that can also decrypt the data. Encrypting data client-side doesn't make it difficult to share information between other users of the same system: all you do at the protocol level is send them a message with the data, or perhaps with a key for decrypting a stored file. It's really just a matter of UI to make it smooth. If anything, it makes it slightly easier because you can use any transport mechanism you like for sending the ciphertext; you're no longer obligated to route everything through HTTPS connections to a single server. So, for instance, you can throw encrypted uploaded files in an S3 bucket, and maintain availability for existing data even if the service provider is having an outage, because users can access and decrypt that data using their client. It does make it more difficult to share it outside the system (to people without accounts) without storing it decrypted.
- n0us 10y agoThanks that actually makes a lot of sense.