Live data from Hacker News

Gmail E2E is as terrible as expected

michal.sapka.pl

31–40 of 70 posts

Re: Gmail E2E is as terrible as expected

#31
post #24

People in China could not open a url sent in Gmail. I happened to be in China, I tried to open the webpage and it worked, no firewall. I hovered on the link in Gmail and Chrome told me left bottom it was just that exact url. But when I opened the url it got blocked by the great firewall. Why? Any link in Gmail secretly gets replaced by a link to Google that tracks you and then redirects you to the original link. The…

That’s a classic technique to track click through rates. Google.com has done this forever. The technique is to make an actual link in HTML ( ) then add an event handler which cancels the link’s default behaviour when you click it - and replaces it with javascript, or a tracking link. I understand why Google.com wants that data. But in an email client it’s extremely obnoxious.

If it’s replaced with a tracking link, I think it might be just as effective to use the `ping` property on browsers that support it

Re: Gmail E2E is as terrible as expected

#32
post #7

This was already happening, unfortunately. The user's mail agent is deemed untrustworthy (and so is the user), so every service which needs to send confidential data just turns your email into a notification with a link. There are so many of these, but often they are limited in scope. For sectors like healthcare you have companies offering this type of service to companies which need to adhere to security theatre sta…

Yep, while I like moving all snail mail to email, I hate that (almost) every single service now just sends a "monthly/quarterly report now available in your account area!" email. A rare few of them at least offer the option of just sending it attached (with the default being a useless reminder email), but most are essentially a chore, because nearly everything here uses phone+2FA as login rather than a password or pa…

Passkey does seem like it should include functionality to encrypt and sign all email and SMS automatically. A missed opportunity.

Re: Gmail E2E is as terrible as expected

#33
post #7

This was already happening, unfortunately. The user's mail agent is deemed untrustworthy (and so is the user), so every service which needs to send confidential data just turns your email into a notification with a link. There are so many of these, but often they are limited in scope. For sectors like healthcare you have companies offering this type of service to companies which need to adhere to security theatre sta…

> The user's mail agent is deemed untrustworthy (and so is the user)

Bluesky follows this pattern for the benefit of the user. The internet tradition has always been: if you want to control it, you have to host it.

Re: Gmail E2E is as terrible as expected

#34
post #13

The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. Then there were a whole plethora of products were build around Lotus Notes Domino that provided a central place for securing outgoing E-mail using either S/MIME or GPG keys. All of this on premises. Then came the Cloud and obliterated these products. And for what? edit: typos

> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. It was never really solved, PGP email is a usability disaster. Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire c…

Ah, the usual "A is an unpopular standard, so we decided to do our own proprietary thing". Guess what: for it become popular, it actually has to be implemented. If Google implemented it in Gmail, many of these purported issues would go away . It would still not truly be E2EE mail, but then again neither is this monstrosity.

Re: Gmail E2E is as terrible as expected

#35
post #10

What happens if the sender's Google account ceases to exist for whatever reason? What if Google ceases to exist? I know that there are a lot of HIPAA "secure email" solutions that also do this, but I don't want this to become more common practice then it already is...

I just keep all my Gmail synced into local Thunderbird via IMAP.

Re: Gmail E2E is as terrible as expected

#36
post #29
post #7

This was already happening, unfortunately. The user's mail agent is deemed untrustworthy (and so is the user), so every service which needs to send confidential data just turns your email into a notification with a link. There are so many of these, but often they are limited in scope. For sectors like healthcare you have companies offering this type of service to companies which need to adhere to security theatre sta…

I struggle with how the secure email solutions are inherently more secure than just dumping the pdf or ticket details in the email body. Every vendor's secure email portal I have ever used was ultimately authenticated using my email account. Any one-time passcodes are sent to the same email. Password recovery? Email. If a malicious user is on my PC or otherwise intercepting my mail, they could access 100% of the solu…

I don't think that's true for my bank or Czech government services. Plenty others do practice "security by email", though.

Re: Gmail E2E is as terrible as expected

#37
post #13

The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. Then there were a whole plethora of products were build around Lotus Notes Domino that provided a central place for securing outgoing E-mail using either S/MIME or GPG keys. All of this on premises. Then came the Cloud and obliterated these products. And for what? edit: typos

> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. It was never really solved, PGP email is a usability disaster. Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire c…

It’s a disaster because email providers don’t want to offer E2EE or make it easy.

Is it that hard to generate a certificate for each email address client side and store that, and the private key encrypted with the user’s password, on the provider’s server?

The majority of email is gmail and Google could make that E2EE by default.

Countless products that have successfully implemented public key distribution (proton mail, instant messaging, …).

Re: Gmail E2E is as terrible as expected

#38
post #9

Earlier quoted context omitted.

The anti-establishment fervor of open source crypto developers is the reason this is a problem though. Most people, for most things, don't need to verify trust outside of normal government channels. i.e. any business I correspond with, trust is via the government that they are a business bound by the relevant legal system I live in. Same story with communicating with basically anyone: if their GPG key was signed by t…

It depends a lot on the government in question too. In the US very few people would trust the government to handle something like this. The certificate authority system is run by big tech companies and nonprofits, for example, not the government. Trusting the government as a peer makes sense for government sites, but for anything else, it just makes censorship way too easy. Even among businesses, we normally trust th…

You've just listed out a bunch of alternate trust roots which, with appropriate infrastructure, could also easily provide practically secured E2E communications which would be adequate for real world use.

The point isn't "trust the government" the point is trust is contextual and the notion of "key signing parties" always missed it (and if you actually go and read up on the concept, government ID documents were considered to be something to ground whether a signature should be issued by someone so it was already baked into the system anyway).

Re: Gmail E2E is as terrible as expected

#39
post #7

This was already happening, unfortunately. The user's mail agent is deemed untrustworthy (and so is the user), so every service which needs to send confidential data just turns your email into a notification with a link. There are so many of these, but often they are limited in scope. For sectors like healthcare you have companies offering this type of service to companies which need to adhere to security theatre sta…

Not that I love any of those particular secure document web services, but I do vastly prefer web pages and URLs for retrieving documents and would happily live in a world where email was a receptacle for notifications.

Re: Gmail E2E is as terrible as expected

#40
post #38

Earlier quoted context omitted.

It depends a lot on the government in question too. In the US very few people would trust the government to handle something like this. The certificate authority system is run by big tech companies and nonprofits, for example, not the government. Trusting the government as a peer makes sense for government sites, but for anything else, it just makes censorship way too easy. Even among businesses, we normally trust th…

You've just listed out a bunch of alternate trust roots which, with appropriate infrastructure, could also easily provide practically secured E2E communications which would be adequate for real world use. The point isn't "trust the government" the point is trust is contextual and the notion of "key signing parties" always missed it (and if you actually go and read up on the concept, government ID documents were consi…

Well, I think that's actually the point, no? This was never a technical challenge (not for a few decades, anyway), but a question of which authority to trust.

Companies rolled their own out of a commercial need. The FOSS community didn't trust the government or big companies so never fully solved the problem. Users just don't care.

Post reply on HN