I’m saying that the fact that they accessed the data through compromised accounts is irrelevant. If the data was properly encrypted and only decrypted on the user’s machine with the key.

It was encrypted and only decrypted on the user’s machine. It’s called TLS.

You made a lot of assumptions there.

Well of course I did - all you said was “use encryption” like that meant anything specific.

Your proposed solution has lots of problems and isn’t materially more secure than properly implementing WebAuthn or even requiring MFA. All you’ve added is a public/private key authentication which is what WebAuthn does.

You also need a solution for lost keys, using multiple browsers, etc. or nobody will use it. This is also being provided by WebAuthn.

The problem here is not “encryption” it’s “properly identifying who should have access to the data.” It’s an authentication problem. The data was encrypted from the servers to the browser in a secure manner. At issue here is account security and authentication.

To be clear - you solution would “work” but without the above issues addressed nobody will use it because it will be a giant pain in the ass. It’s not like we don’t know how to share data securely, it’s that doing so is complicated and often relies on users to be sophisticated about security. They’re your weakest link so you need a system that:

1. Is secure
2. Users will use
3. Can easily be used correctly by unsophisticated users and
4. Is easy to automate (not manually generating and handing out keys, etc.)

And this is what WebAuthn promises.

And as for WebAuthn, yeah that would work and it’s definitely better than a password, and would perhaps solve part of the issue,

It only has to solve part of the issue. The end-to-end encryption is covered with TLS.

I don’t see what your solution would do that isn’t covered by existing tech. And it would require a lot of new protocols to be put in place, support by major browsers, good user interfaces, etc.