[HN Gopher] Gmail E2E is as terrible as expected
___________________________________________________________________
Gmail E2E is as terrible as expected
Author : HypnoticOcelot
Score : 149 points
Date : 2025-04-06 19:42 UTC (3 hours ago)
(HTM) web link (michal.sapka.pl)
(TXT) w3m dump (michal.sapka.pl)
| ranger_danger wrote:
| 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".
| kardianos wrote:
| 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.
| perching_aix wrote:
| > lets you revoke (...) access
|
| That's pretty funny.
| zer0zzz wrote:
| Doesn't proton mail also do this for sending encrypted mail to
| folks with no encryption?
|
| They ought to do pgp though
| jitl wrote:
| Can't expect a civilian to manage pgp keys or go to key signing
| parties
| XorNot wrote:
| 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.
| solardev wrote:
| 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.
| XorNot wrote:
| 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).
| solardev wrote:
| 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.
| Freak_NL wrote:
| 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.
| modeless wrote:
| 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.
| jack0813 wrote:
| 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.
| smileybarry wrote:
| 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.
| LexGray wrote:
| Passkey does seem like it should include functionality to
| encrypt and sign all email and SMS automatically. A missed
| opportunity.
| bob1029 wrote:
| 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.
| dvdkon wrote:
| I don't think that's true for my bank or Czech government
| services. Plenty others do practice "security by email",
| though.
| bigthymer wrote:
| 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.
| irq-1 wrote:
| > 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.
| Dylan16807 wrote:
| > 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.
| tshaddox wrote:
| 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.
| solardev wrote:
| 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.
| stwrzn wrote:
| 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...
| toomuchtodo wrote:
| 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.
| solardev wrote:
| 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.
| TJSomething wrote:
| I just keep all my Gmail synced into local Thunderbird via
| IMAP.
| n3storm wrote:
| I guess minimal gmail for e2e is the tariff we have to pay for
| privacy and freedom. wink.
| otterley wrote:
| > 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.
| p2detar wrote:
| 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
| bigfatkitten wrote:
| > 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...
| AshamedCaptain wrote:
| 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.
| aborsy wrote:
| 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, ...).
| pas wrote:
| 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.)
| Telemakhos wrote:
| 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?
| josephg wrote:
| For PGP keys to work, users also need to publicly broadcast who
| they know and personally trust. It's a privacy disaster.
| tptacek wrote:
| This is how most commercial secure email products work.
| fnord77 wrote:
| how else are they going to push ads?
| jonathantf2 wrote:
| This is exactly how M365's solution works. Decrypts if the
| recipient is using MSN or EXO, otherwise punt them to a webpage.
| jurschreuder wrote:
| 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.
| josephg wrote:
| 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.
| ChadNauseam wrote:
| 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
| SparkyMcUnicorn wrote:
| I thought Gmail didn't support js execution. Did Google make
| an exception for themselves?
| mzajc wrote:
| > 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.
| tky wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-06 23:01 UTC)