We do deserve end-to-end encrypted communication but then nobody except nerds could be bothered about managing private keys, so in the end providers would manage our keys and still be able to read our messages.

If the problem is that goggle/etc can read your email, not using them for your email is the solution.

Then, yes, there's also an issue where ecommerce sites submerge us in useless email (is "your package has been shipped" an event so important that I must be immediately notified? Because I only care about when the package will be delivered) and could use a "notificaiton settings" page.

Of the sites I use, the worst offender is aliexpress, which sends (IIRC) "order confirmed", "package shipped", "packages reached customs", "package cleared customs" and "package has been delivered" for every friggin' item you ordered.

get a domain name, host stalwart somewhere and set up email with this new domain there, get receipt emails there and autoforward it to your main email with S/MIME, gpg or whatever enabled.

usual disclaimer 'do not host your email blablabla' (at least don't get fucking digitalocean 'droplet' for it), but there's no other way around that, ecommerce won't enable shit.

One of the problems I personally see is the reliance on a standard that was done since the dawn of the internet and got stitches all these years.

Emails as a service is useful, and has several properties that make sense to exist. However, it is simply not easy nor intuitive to have encryption on it (and even then, there are limitations).

What we would need on the long run is simply replace email with a common standard that actually encrypts in transit (at very least) with auto negotiated keys on exchange.

But we would need to change the mind of a lot of people to make that a priority.... (For better or worse, it is the market that states the incentives and priorities. And it is abundantly clear security is not on the top list)

What do you suggest? If they get forced to use something encrypted, they won't choose XMPP for sure, most probably something like whatsapp or telegram.

Being forced to use non standard protocols, and specially non federated ones is also a concern. Where I live, it's assumed that all clients/users must use whatsapp, so they don't answer your questions, you can't ask them anything, you can't share any doc with them if in need for support, it it's not through whatsapp. And everyone seems happy with it.

e2ee by itself is not enough for privacy, metadata counts, and on proprietary communication systems one doesn't even have a clue what data is mined by the company/owners or even worse if they have non disclosed mechanisms to do that or even worse to introduce back doors.

If I'd suggest something, that would be a standard and federated protocol with e2ee like xmpp + omemo. But again, I'd be naive to assume that's a possibility, if forced to do something corporations will choose what's more convenient to them not to the user, and that usually translates into proprietary abusive mechanisms.

Now about nerds using gnuPG/openPGP keys, ohh well, thunderbird chose what to me is the wrong path of not using gnuPG underneath (now by default all keys are exposed unencrypted, unless you choose to use TB's master password for example, between several other limitations, the good thing is that there's sequoia-octopus-librnp to the rescue), but that path allows them to offer a really easy way for users to interact with openPGP keys. On Android K9, now a days Thunderbird, has made it really easy as well to use gnuPG/openPGP keys when accompanied with openkeychain for example. There's nothing obscure neither truly complex about current gnuPG/openPGP usage these days. I would agree like 15 years back one really needed to learn how to maintain the gnuPG keyring, how to add and manage public keys and how to manage your own private keys. But even then there was Enigmail, which after TB chose that path turned into just a shell to help move from Enigmail to the chosen TB's librnp way, and Enigmail made it really easy to do all that gnuPG stuff. Besides thunderbird, which I wouldn't say is a nerdy thing, there were/are several other easy alternatives to use and handle gnuPG/openPGP keys. So, not really nerdy, I'd think just willing to go a bit beyond what the corporations offer you, for "your own convenience". But how many people even care? I'd say we're a sleepy society, accepting everything imposed to us, even when there's no need to, because of the hassle to look for truly privacy respectful, security respectful (from the user perspective, not just the corporations perspective), and also really important user liberties/freedom respectful, which Today's corporations with the help of some communities and the banning culture we all embraced, have been successful in convincing us that's unnecessary in favor of more "practical" alternatives, including proprietary ones...

Given that an E2EE solution requires all online stores switching technologies, it's unlikely to happen. The next best option is using a VPN-like solution for email. I use Privacy Portal email aliases with email encryption for this. There are multiple other alternatives but I like Privacy Portal because it has one of the strictest privacy policies and because I'm a little biased (I'm an engineer on the team).

Emails sent to you from online stores get sent to Privacy Portal's relay servers. These servers act like VPN servers meaning no logs, no writing to disk, zero storage, ... The emails get encrypted in memory with your public PGP key (or certificate) and get sent encrypted to your email provider. Only you will be able to decrypt them on device.

If you use Proton mail as your email provider, it supports PGP encryption by default. You can simply copy your public PGP key from proton and submit it to Privacy Portal and you're done. Proton won't have access to your emails. Alternatively you can use any email provider with an email client that supports PGP (e.g. Thunderbird, K9). And if all else fails you can even use S/MIME with Apple Mail on iOS but that has some drawbacks.

With this solution you would be separating providers into 2 categories:

• The first provider receives the unencrypted data but has no authorization to log or store anything.
• The second provider is responsible for storing your encrypted emails but does not access the unencrypted version.

On top of that, you can also reply to emails without exposing your the unencrypted versions to your email provider because encrypted emails sent by Privacy Portal contain public keys used for decrypting outbound mail before relaying it to its destination.

The cherry on top is that the online store won't have access to your personal email. So if they start spamming you, you can stop the email alias.

They have more power, so they get away with it. Fixing that is not single player. Start with easy stuff, rejecting Discord, Instagram, iOS, and other anti-libre software if you have not already.