[btown]

Encryption keys could themselves be encrypted with a password that the user would type, that is only ever saved in browser local storage, or even only in memory and needs to be retyped on each pageload.

There's nothing preventing the government from forcing Meta to implement a backdoor that exfiltrates the unencrypted key, of course, but that's true of non-web-based systems as well.

[harshitaneja]

I am not sure how would that prevent them having access to the key and subsequently the data? Is there any platform which implements what you are suggesting and prevents the platform access to the data on a web application?

Genuinely asking as I would love to implement something for my customers which gives them control over their data while it resides on my servers.

[Xylakant]

Your parent poster proposes that the key itself is protected by a password that the user needs to enter and that the unlocked key is only stored on the users device (local storage for browsers,…)

The server only serves encrypted data that gets decoded in the browser.

The primary usability problem for that approach is that there’s no way to recover the data (messages) if the user ever forgets the keys passphrase.

Another problem is that all of the rendering that uses such encrypted data needs to happen client side in JS, WASM or similar.

[harshitaneja]

Ah. I misinterpreted this thinking the user password would be used but in this case having a separate password which user would have to reenter erratically.

I am not in security but think that XSS might be a concern here with something so sensitive.

And UX problems that come with it. Sounds interesting though to at least discuss with customers to see if the benefits are worth the costs to them.

[sofixa]

But then if the user forgets their password, there's no way to reset it.