Gmail E2E is as terrible as expected | Hacker News Reader

Gmail E2E is as terrible as expected

michal.sapka.pl

186 pointsHypnoticOcelot66 comments

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 standards such as ISO 27001, and because nations often have their own added requirements for specific sectors (think HIPAA in the US or NEN 7510 in the Netherlands) these services tend to remain focussed on single countries.

Then there are the national governments and things like insurance companies. All happily sending message notifications where you need to sign in to their own portals.

Securing email is too complex, so everyone builds their own secured portal thingy, and your mailbox has become a receptacle for notifications. Figuring out a solution would require cooperation, pragmatic lawmaking, and giving up those nice cashcows of moated portals, so it won't happen.

I hate this so much. I will pay for a service that takes all these content-free messages and goes to the website and logs in and extracts the actual message content and puts it in my inbox. Anyone want to make that?

I actually think there is a more general opportunity here with AI. Every app and website and UI I use is optimized by a gaggle of PMs to achieve business objectives that don't necessarily benefit me. AI is getting to the point where soon it will be able to use these non-aligned UIs for me, and present to me a much simpler UI customized just for me, that does what I actually want and no more.

You can probably do this fairly easily already, like this:

- Fetch your emails using any of the common local mail sync tools

- Some processing to clean up the plaintext version, may not be necessary even

- Send it to an LLM to extract a link

- Open up a headless browser, trigger something like SingleFile to extract its content.

Though you'll have to keep the cookie refreshed, but if it is initially logged in, this should be fine since you can also program something to keep refreshing every once in a while.

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 passkey.

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

For that reason I actually have decided to get everything via snail-mail.

When BofA sends me a new statement I need to:

    * click on the link in my inbox
    * wait for the email-provider to scan the email (and Office 365 does sometimes tell me they can't scan the link)

(either)

    * Enter my username & password
    * Select that I want my 2FA via call or text
    * Wait for the call or text to arrive
    * Enter it (now I'm signed in)

(or)

    * search my house for my YubiKey
    * lean over to insert YubiKey
    * click cancel on the Windows popup for the passkey
    * click cancel on the Bitwarden popup for the passkey
    * click Physical key on the Chrome / Edge popup for passkeys
    * put in YubiKey pin
    * lean over again to physically touch YubiKey

(end)

    * Click no on the next credit card offer
    * Navigate to Credit Cards
    * Click the Credit Card
    * Click Documents
    * Click current statement

when I'm on my walk (which I do anyway)

    * insert key in mailbox
    * (no delay) open mailbox
    * (no delay) take out letters
    * (no delay) close mailbox
    * (no delay) remove key
    * walk home
    * open statement
    * validate statement
    * trash statement

Even with passkeys there are too many where the flow can / purposefully is interrupted.

> because nearly everything here uses phone+2FA as login

Here in the US we only wish things were that secure.

Unless by 2FA you mean “code sent via SMS”.

Sadly I mean "code sent via SMS", which is one reason why I haven't automated much of the retrieval for these things.

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 solutions I've got access to right now.

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

I always understood it as, the email with link notification thing started as soon as email providers began regularly scanning users' emails. Before then, an email included all the information you needed without having to login to another site.

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.

> 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.

> if you want to control it

In the context of sending a secure message, the sender maintaining control goes in the negatives column. At best it's a compromise in exchange for specific security features.

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.

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 most obnoxious thing about this I think is that Chrome shows the original link.

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 (<a href=…>) 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

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.

I hate it even more in Google calendar where they don’t even bother to use that JS. I’ll copy a zoom join link from an invitation to send to someone, and I get some sh**y Google redirect URL.

> The most obnoxious thing about this I think is that Chrome shows the original link.

Not defending Google here, but could it be that the tracking page is opened by onclick() while the browser shows the original href attribute?

I've seen some websites do that for various purposes and opening the link in a new tab (middle mouse click) usually bypasses it.

That sounds like a China problem, not Google.

This is how all HIPAA "secure email" works. Outlook, Zoho, clinic comms, BECAUSE it lets you revoke email access.

If you want an opportunity in this space, it isn't actually encrypted emails, but possibly standardizing and streamlining such "message pointers" and address endpoint verification.

> lets you revoke (...) access

That's pretty funny.

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...

Keep HARs from the browser if you need your own record of the messages. Next step would be to determine how to extract the messages from a history of HARs and inject into your own mailbox or other storage system for archiving and search. Perhaps a browser extension to automate this automated logging of message retrieval.

IMO those are different use cases. If that sender or Google itself were to disappear, hopefully the messages would just disappear too. It's better that they become inaccessible rather than public.

Long term archival is a different use case altogether, especially of encrypted materials. It's questionable whether any provider or medium can survive over the long term, so it's better to use an encryption system where you hold the keys and the encrypted data can be migrated to any sort of storage or provider over the years.

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.

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.

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 conversation is exposed. Key exchange with new recipients is tedious to do securely.

Not to mention the extra issues caused by HTML in message bodies.

https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you...

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.

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, …).

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.

This would be a reasonable proposition if the entire Internet mail system was run by 3-4 operators, and there were no mail clients at all other than service provider webmail.

Unfortunately, the real world is much more complicated than that.

While I'm sure some of these flaws also apply to S/MIME, I feel like its client support (even in Apple iPhone native mail app) is far superior to PGP. Apple made S/MIME installation and use across its ecosystem, and I remember it being easy in kMail once upon a time when I used KDE; why didn't S/MIME ever catch on?

It did, but on enterprise level. S/MIME uses the CA hierarchical trust model, which is centrally managed and much more compatible with how internal enterprise structures are built. In a large enterprise you would have IT managing your AD/CS and therefore also managing the issuing, revocation and so on of employee certificates. But for the public this model of management isn't really practical.

I've worked in an org that used S/MIME heavily.

In a managed environment, you also get the advantage of certificates stored in a central directory (LDAP etc), and so certificate selection for the client is seamless.

All you have to do is hit "encrypt" in your mail client, enter your smart card PIN and the machine does the rest.

Indeed using PGP for personal E-mail was never easy and required sufficient knowledge from end users. Using it in corporate setups was a piece of cake and I've seen it personally. I had been using and working on software that manages PGP keys centrally, end users did not have to do anything about encryption or signature verification. The problem was indeed solved. Arguably that is what Gmail tries to (poorly) do right now.

> Not to mention the extra issues caused by HTML in message bodies.

Proton Mail came out with a pretty good statement about this and I fully agree.

> Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk.

https://proton.me/blog/pgp-vulnerability-efail

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?

If I attach a pgp signature in an email, it’s trivial for a MITM attack to replace my signature with their own. Without any way to verify who owns the key that was used to sign your message, what good is it? I suppose I could publish my key on my website too, but that’s a usability nightmare for everyone involved. A mitm attack could also just strip off the signature and alter the message I would be none the wiser.

Signal uses a much more complex key ratcheting system. It’s TOFU, but the key rotates with each message I send. The first message is vulnerable to a MITM attack, but because of the way signal works, if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure. The earlier keys are also published to make messages deniable. (Aka OTR).

Even then, if you want to verify who you’re talking to, you can click on someone’s name in signal and click “View safety number” and verify the code through a separate channel. Like, in person or over a text message or something.

Because your code is different for every conversation, it protects against correlation attacks. That is to say, a 3rd party watching the traffic can’t tell that all of the messages you send to different recipients came from the same person. Email+PGP doesn’t encrypt the most important information - which is the identity of the sender and receiver.

Signal is way better than pgp-over-email in every regard. The UI is better. There’s no encouragement to publish your keys or your social network. And the security ratchet is better than the static key that pgp uses. I’d pick it every time.

We are talking about public keys here, not signatures.

>It’s TOFU, but the key rotates with each message I send.

You seem to be confusing the Signal long term identities with forward secrecy.

>...if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure.

This isn't true. Signal verifies identities the exact same way PGP verifies identities. As with PGP if you haven't checked your "safety numbers" you can't be sure your messages are actually ending up with your correspondent.

>Because your code is different for every conversation, it protects against correlation attacks.

PGP normally uses a different session key for each and every message ... but that isn't really relevant for either the Signal or PGP case if we are talking about correlation. For efficiency and convenience each message is normally tagged with the encryption key fingerprint of the recipient but you can turn that off if that might be a problem in your particular application. At that point there is nothing an observer can use to determine anything about the sender or receiver.

You probably meant to reference Signal's "sealed sender". It doesn't really work in practice:

>https://www.ndss-symposium.org/ndss-paper/improving-signals-...

> And for what?

Job security. The software industry was built on the premise that users would buy all new software and hardware every 3 years. In the mid 2000s they collectively realised that software was ‘good enough’ for most users, and that it doesn’t wear out.

SaaS, the subscription model, “the cloud”, they’re all about making the user pay more than once for the same software.

Isn't this how banks send secure messages too? You can't send secure emails to arbitrary clients otherwise. PGP stands no chance of being adopted by regular users.

This is exactly how M365's solution works. Decrypts if the recipient is using MSN or EXO, otherwise punt them to a webpage.

I think one of the growing threats lately in the community has been over malicious client-side javascript, especially when the client handles end-to-end encrypted content (used on sites like Proton, MEGA etc.), so requiring users to trust Google with the contents of these client pages, and by extension the emails themselves, seems (in my opinion) to defeat the entire point of this feature.

Some work in this area has been done in the form of browser extensions that are used to verify signed assets delivered to the client:

https://github.com/freedomofpress/webcat

https://github.com/tasn/webext-signed-pages

https://github.com/jahed/webverify

https://github.com/facebookincubator/meta-code-verify

But unfortunately for now, none of these are seeing wide adoption and this remains an unsolved issue. It also does not require anyone to use known-good, audited and verified open-source components, meaning even if the client code is signed, it can still be malicious... there must be a greater reason to trust the code than just "trust me bro".

Doesn’t proton mail also do this for sending encrypted mail to folks with no encryption?

They ought to do pgp though

Can’t expect a civilian to manage pgp keys or go to key signing parties

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 the common government key, then hey, good enough for anyone.

The problem is...we don't have the infrastructure for any of this. And GPG key servers are inadequate for maintaining suitable privacy for people if they were used at this scale.

But we certainly could provide the means by existing technologies: e.g. nothing stops us making drivers licenses and other forms of ID smart cards.

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 the middleman (the credit card issuer, and their protections and chargebacks) over the government. If a business screws over a regular consumer, the government isn't really going to do anything.

Maybe you have a more civilized society and functional government where you live. We don't.

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).

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.

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, tell them they need to use Thunderbird or some other helper app(s), and see if you can even go home before being asked to remove it all.

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. )

How does the E2EE happen if you're clicking a gmail link? One thought is the secret bit is tacked onto the anchor part of the URL, but the secret is in plaintext both on the senders sent email and on the recipient side.

email is dead, even gov's use chat clients with emoticons ;)

That email is your internet id and majority countries digital id too ? Who cares, things usually need to be so broken that even elected officials families report problems :) Then we can have some "plans" announced. EU is especially good at this - announcing (and pushing for more centralization no matter what is happening) and not fixing anything, eg. sane CPU's, when ? Rhetoric question because not in this decade...

This is how most commercial secure email products work.

how else are they going to push ads?

I guess minimal gmail for e2e is the tariff we have to pay for privacy and freedom. wink.

> I'm not going into how much this is not E2E, as this has already been proven

By whom? It looks like E2E to me. It’s just that both ends are controlled by the same entity.

Reply on news.ycombinator.com