Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail E2E is as terrible as expected

michal.sapka.pl

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Gmail E2E is as terrible as expected

#51

Post by fn-mote »

SparkyMcUnicorn wrote: post #41
josephg wrote: post #24

Earlier quoted context omitted.

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.

I thought Gmail didn't support js execution. Did Google make an exception for themselves?

It’s not JS in the message. It’s the JS of the GMail page.

Re: Gmail E2E is as terrible as expected

#52

Post by Numerlor »

bob1029 wrote: post #29
Freak_NL wrote: 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…

You usually keep old mails around that malware can then silently forward, this is a problem for unencrypted data. To authenticate through email, even if possible, there are hoops the attacker would need to go through and you'd likely be notified of e.g. a password reset mail

Re: Gmail E2E is as terrible as expected

#53

Post by philistine »

Numerlor wrote: post #52
bob1029 wrote: post #29

Earlier quoted context omitted.

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…

You usually keep old mails around that malware can then silently forward, this is a problem for unencrypted data. To authenticate through email, even if possible, there are hoops the attacker would need to go through and you'd likely be notified of e.g. a password reset mail

We could integrate expiry dates for emails after which they get deleted. That's feasible.

Re: Gmail E2E is as terrible as expected

#54

Post by weikju »

TJSomething wrote: post #35
stwrzn wrote: 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.

Doesn’t matter. If using this and I send you an email, and my account disappears, you can no longer read the email you received because it’s merely a link to read something from my account on Google.

Re: Gmail E2E is as terrible as expected

#55

Post by weikju »

tky wrote: post #23

All the takes on this release miss one crucial point: if you want people to adopt E2E encryption, you must reduce friction. For users of Gmail, that means familiar elements and flow to their usual use of Gmail. If this lets even a handful of people use more secure messaging, it’s a win. For Google workspace-centric orgs it’s a good step in the right direction. If you disagree, go set up GPG on a non-tech’s computer,…

Like so many security gestures from Big Tech, it’s a win wrapped in a curse (or lock-in, tracking, what have you depending on the solution. )

Re: Gmail E2E is as terrible as expected

#56

Post by philistine »

stwrzn wrote: 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...

Coming to Google's Blog in 2028:

Focusing on the Future of Secure Communication

[...] Starting next week, E2E emails on Gmail will no longer function, and all your E2E messages on Gmail will be deleted on February 1 2029.

Re: Gmail E2E is as terrible as expected

#57

Post by aborsy »

pas wrote: post #42
aborsy wrote: post #37

Earlier quoted context omitted.

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 ma…

that's not the hard part. it's the out-of-band key exchange. (or key discovery/verification. so basically how to avoid the trust on first time use problem.)

The certificate contains email address as ID, and email is verified automatically or by an initial email verification (TOFU trust model).

If Google, Microsoft and Apple offer E2EE similar to Proton, the majority of email will be encrypted, as long as both sides use the same service, or globally if these companies share public keys for public key discovery.

Re: Gmail E2E is as terrible as expected

#58

Post by bufferoverflow »

jurschreuder wrote: post #22

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 sounds like a China problem, not Google.

Re: Gmail E2E is as terrible as expected

#59

Post by josephg »

ChadNauseam wrote: post #31
josephg wrote: post #24

Earlier quoted context omitted.

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

Huh - I didn't know that existed. Its not supported in firefox or IE11 though - and probably will never be.

(IE11 probably isn't super relevant now - but it was almost certainly more relevant when that tracking code was written. You could use feature detection - but its much easier to just use their hacky javascript everywhere instead.)

https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorE...

https://caniuse.com/ping

Re: Gmail E2E is as terrible as expected

#60

Post by upofadown »

josephg wrote: post #26
p2detar wrote: 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

For PGP keys to work, users also need to publicly broadcast who they know and personally trust. It’s a privacy disaster.

You can just send your PGP key to your correspondents attached to an email. There is even a mime type for it. There is no need for any public broadcasting.

The big problem is verifying identities. The usability of that is an unsolved problem that plagues encrypted messaging of all kinds. So sure, signing PGP keys as a form of introduction is awkward, but at least it is possible. How do you vouch for, say, a Signal user?

Post reply on HN