[fc417fc802]

This is entirely the wrong lesson to take from this. Why are we still using a plaintext protocol in this day and age? Why can we not get an E2EE addition to the email protocol with full backwards compatibility?

Yes, I understand that it would be imperfect since inevitably not all servers would support it thus forcing additional understanding and decisions on the end user. No, I don't care that a user other than myself might leak my messages in plaintext. Perfectionism in this regard only serves to further shoot us in the foot. Yes, I understand that key distribution is a difficult problem but then that's the case no matter the protocol. Other protocols have solutions that work reasonably well at this point.

There's no justification for the current status quo.

Alternatively I'd be fine using matrix for all my PII related needs (healthcare, government, subscription services, etc, etc) but somehow I don't see that happening any time soon.

[laughing_man]

Getting from here to there is going to be tough, but I agree 100%. Not only should email be E2EE, but it should include a certificate scheme such that you know the person purporting to be the sender is actually the sender.

[wvh]

PGP had the right idea, but the system is too hard for the average person.

With "system" I refer to building a web (or multiple!) of trust, based on parameters that you decide upon.

[fc417fc802]

Given that the cryptography would necessarily be asymmetric verifying the sender on a TOFU basis seems like a trivial addition (just sign something). I doubt you can do better than TOFU though unless you tie it to an external ID system (corporate or government or etc issued hardware tokens or similar).

[nottorp]

For large organization data the keys would need to be stored within the organization, not with one particular user as in the case of your personal PII needs.

And then you'd still need to worry about digital sovereignity for the keys.

[fc417fc802]

I don't follow. Are you saying that BigCorp would demand key escrow? They already deploy custom email solutions today so I don't see the issue.

[nottorp]

I am saying you can't keep the keys just on a stick in the employee's pocket since multiple people need to have access to the data.

And if those keys are stored by a company subject to US jurisdiction, we're back to the same problem.

[fc417fc802]

Well yes, if you hand your keys over that is indeed a problem. Of course handing your keys over to the provider rather defeats the purpose of E2EE so hopefully no one is doing that.

Key escrow is the usual solution to an employer needing access to employee materials.

[nottorp]

> Key escrow is the usual solution

Yes, and you move the problem to "is the entity/process/whatever handling key escrow under US jurisdiction"?

[fc417fc802]

Yes, obviously, but key (/account/identity/etc) management is typically a much narrower and well defined problem to solve and in many cases it will already have been solved (centralized management of user accounts, employee ID cards that contain physical tokens, and other such things).

[fsflover]

How about the metadata? Perhaps if you mean something like self-hosted Matrix, then I agree.

[vrganj]

For a public institution you want some sort of accountability / auditing mechanism, so you can't just do E2EE encryption between users.

Otherwise, a public servant could do sketchy stuff behind the public's back with no paper trace.

What you don't want is hostile foreign capitalists leaking your data to their local authoritarians. They are not your public and shouldn't have the data in the first place.