"Embrace, extend, extinguish" all over again. I am appalled at how many people use Gmail, giving up their privacy, control over E-mail, and leading to an overly centralized system where our mail is controlled by 2-3 companies at most (about 30% of my spam comes from Google servers, they pretty much ignore abuse reports, and I have no way to block it, because they are "too big to fail").
Now we will get a slowly introduced proprietary encryption scheme that will pretend to be "open", but will be carefully controlled so that it is slightly broken for everyone except Google. Several years down the road we'll wake up in a world where people will be annoyed that you can't receive their E-mail and will tell you to "just use gmail".
Replace "Google" with "Microsoft" and "Gmail" with "Outlook" and it's the 1990s all over again.
> I am appalled at how many people use Gmail, giving up their privacy
The article is literally about cross-vendor E2E email encryption. I mean, we all understand that you mean to invoke the Standard HN Litany Against Google here. But surely you at least should nod to the fact that the linked article stands as a point against your position, no?
I think he has a point. Slack and discord used to have IRC and XMPP, which made the decision to switch seem safer in light of the issues we experience today (holding backlog hostage for a fee, advertising, a/b tests). They timed the depreciation of these bridges so that it had minimal impact on their sales due to the existing network effects and captive audiences (employees, mostly).
We have seen this played out over and over and over again. It’s tiring, and it would be great for more people to be aware of these market capture tactics to make them less effective.
I don't know about "the best", but I'm very happy with Fastmail. It has a very nice UI, it has contacts and calendar, uses open standards, and their privacy policy is fine.
I switched to Fastmail when I degoogled, and I've been very happy with it. I genuinely feel that its UX and feature set are better than what I was getting from GMail.
What UI features do you consider important? I feel that email UI is largely standardized, and the main differentiating factor is speed (and Gmail is definitely not fast).
OTOH, what Gmail does with filtering promotional crap (spam, tbh) is decent, but I haven't compared against other mail service providers, so I can't give a comparative opinion.
another vote for fastmail, I got my own domain and been slowly changing my email eveywhere away from gmail. No need to do it all in one go. I barely touch my gmail account anymore, feels so freeing!
Do you mean a self-hosted webmail app? Or a native/multi-platform native email client?
Personally I think Gmail UI is meh - but I no longer use email that much - so terrible UI/ux and no proper quoting/threading support isn't all that problematic.
"send end-to-end encrypted (E2EE) emails to anyone, even if the recipient uses a different email provider" but the video shows Gmail asking the recipient to authenticate. How does that work? If a Gmail user sends an email to my self-hosted server, there is nowhere to authenticate me to.
And it means either Gmail or the actual email stores decryption keys, so what is the threat model in which E2EE is useful here?
The only "advantage" I see is that now recipients must manually archive these "encrypted" emails if they want to keep access to them in the future (so most of them won't). That would be consistent with Google's strategy with AMP's editable emails.
They are saying the truth: those emails are "technically" encrypted.
Just nowhere private on the sender side since they won't even keep the keys private.
Now much less private on the receiver side since they have for "reasons" to login into a gmail hosted server and give them data like their IP address and permit other things like browser fingerprinting.
Fantastic, from the title I almost believed they'd be adding private messaging as done by other email providers almost 30 years ago. But not yet.
This is just Google going after those proprietary “end to end encrypted” email services healthcare and other places use. Technically speaking they don’t accomplish anything but from a compliance perspective they seem to satisfy regulators.
To me this looks strictly worse than if they just used s/mime with some magic to integrate in the Gmail client for ux.
As I read it[1] - Gmail users are given a hidden s/mime key pair, possibly with secret key stored in a hw token/on device.
I can only assume that when mailing an external user without guest/Gmail account, Gmail will generate a (temporary?) key pair for the recipient, encrypt the message under temporary public key of the recipient - then when recipient creates the guest account - either generate a new key pair and re-encrypt or assign the key pair held for the user? To allow Gmail to decrypt the mail in the browser? As well as implicitly trust the sender key for verification?
I struggle to see how this is e2e in any meaningful sense?
When I log into a public terminal at my library - how will the browser access my keys?
I never liked the term "end-to-end encryption". I guess we can now say it's fully meaningless.
The one thing I've learnt in security after many years is there are no shortcuts. If you don't understand the basics, you can't have security. Things like "end-to-end encryption" are just trying to avoid teaching people the basics by using nice words.
People understand if someone has a copy of their front door key then it's no longer secure and they need to change the locks. So it should be simple to understand encryption too. But most interfaces try to hide away the existence of keys, which is the most basic principle of all. If you don't know where your key is, how can you be secure?
Authenticate where? How does the authentication prove that the intended recipient is the one who has clicked on the link and should be able to view? What happens if the email is forwarded with the link? What should one do to forward the email to someone without this encryption?
Organizations may need ways to store, archive and manage received email content from others.
I don’t understand what problem this solves for organizations and how.
Microsoft Outlook 365 has a somewhat similar feature where the email is just a link to hosted content on its servers (this kind of functionality isn’t new or recent on other platforms). It doesn’t require any authentication by the recipient. IIRC, the sender can also decide on the expiry of the content.
> How does the authentication prove that the intended recipient is the one who has clicked on the link and should be able to view?
You log in with a Google account associated with the recipient address. You prove you control the email by putting in a code Google sends you.
> What happens if the email is forwarded with the link?
They can't open it because they don't have access to the Google account associated with your email address.
> What should one do to forward the email to someone without this encryption?
Obviously, encrypted emails are not meant to be forwarded. Nothing prevents you from taking a photo though. Maybe copy and paste will work.
> Organizations may need ways to store, archive and manage received email content from others.
Organizations can't control how they receive information. It doesn't matter what they want in this regard. If a judge orders them to do something about it, that's for the judge to figure out.
> I don’t understand what problem this solves for organizations and how.
It keeps messages private. You don't see why organizations in e.g. health care, law, or the military want increased privacy of messages in a way that is super easy to use? And where recipients can't accidentally forward sensitive messages? A lot of this is determined by compliance requirements too.
I have used a similar service. Anytime you want to access the link, you must enter a code sent to your email. So if you forward the link, and the person to whom you forward it click the link, they need you to also forward the code to them.
Any idea what those are exactly? Does it only work for recipients on teams with SSO? Or is this just gating who can start these supposedly e2e encrypted email threads?
Looks like recipients can be anyone but would be forced to create a guest account if they don't have one. Which sounds like Google meditating key exchange? Which isn't really e2e encryption at least for the initial message.
The demo gif looks so weird. So you send someone an email, and (if it's not a gmail) it asks them the log into some mini gmail looking thing to view the actual message?
> preserving enhanced data sovereignty
As in you need google in order to view any of your data?
> end-to-end encrypted
Ah yes end (googles server) to end (also googles server) encryption. Very useful.
Maybe I'm misunderstanding but this genuinely seems completely pointless at best. It's middleman to that same middleman encryption solving the last mile delivery problem by not sending the actual message.
I assume the point here is to check a box in some big corporate's matrix of required features before they'll move to Google Workspace. Nobody really cares whether its really end to end, they just need some to say the magic letters E2E and they can tick it.
An ad company that has been creating ads for years based on what is in your email, is telling us emails will now be encrypted eh? Why do I have my doubts
How so? You get an email with a link from a GSuite user, you need to put your, I guess, own mail provider user and password and get redirected to a mini-gmail website where you can see the email sent, that can be blocked for copying or removed by the sender as admins can already do in GSuite?
All I want from Google Workspace is a single-user email account tied to my domain name. Instead, I have an overly complex system where I need to grant my own phone permission to watch YouTube videos. It would be nice if they had a more basic version.
"Embrace, extend, extinguish" all over again. I am appalled at how many people use Gmail, giving up their privacy, control over E-mail, and leading to an overly centralized system where our mail is controlled by 2-3 companies at most (about 30% of my spam comes from Google servers, they pretty much ignore abuse reports, and I have no way to block it, because they are "too big to fail").
Now we will get a slowly introduced proprietary encryption scheme that will pretend to be "open", but will be carefully controlled so that it is slightly broken for everyone except Google. Several years down the road we'll wake up in a world where people will be annoyed that you can't receive their E-mail and will tell you to "just use gmail".
Replace "Google" with "Microsoft" and "Gmail" with "Outlook" and it's the 1990s all over again.
> I am appalled at how many people use Gmail, giving up their privacy
The article is literally about cross-vendor E2E email encryption. I mean, we all understand that you mean to invoke the Standard HN Litany Against Google here. But surely you at least should nod to the fact that the linked article stands as a point against your position, no?
I think he has a point. Slack and discord used to have IRC and XMPP, which made the decision to switch seem safer in light of the issues we experience today (holding backlog hostage for a fee, advertising, a/b tests). They timed the depreciation of these bridges so that it had minimal impact on their sales due to the existing network effects and captive audiences (employees, mostly).
We have seen this played out over and over and over again. It’s tiring, and it would be great for more people to be aware of these market capture tactics to make them less effective.
3 replies →
I've seen to many companies call things "open", when they are decidedly not "open" — Google's Android comes to mind, or OpenAI.
I don't see an RFC defining that "cross-vendor E2E email encryption" as a standard, so calling it "cross-vendor" is just fluff at this point.
Valid concern. I have been decoupling my dependency on Google for quite some time now
What is your email solution?
I was looking at ProtonMail. Now FastMail seems good too. So, wondering what is the best option between each.
10 replies →
What's the best Gmail alternative wrt UI features?
Not a clue about what you're seeking. I'm using mailbox, and thunderbird as a client for my devices (android, windows, linux and macos).
It works. For E2EE, I have GPG setup on all of my devices. It costs me a little over €1/month for paid account as I use my own domain.
The experience has been good, and something I absolutely advocate for and promote.
1 reply →
I don't know about "the best", but I'm very happy with Fastmail. It has a very nice UI, it has contacts and calendar, uses open standards, and their privacy policy is fine.
I switched to Fastmail when I degoogled, and I've been very happy with it. I genuinely feel that its UX and feature set are better than what I was getting from GMail.
What UI features do you consider important? I feel that email UI is largely standardized, and the main differentiating factor is speed (and Gmail is definitely not fast).
OTOH, what Gmail does with filtering promotional crap (spam, tbh) is decent, but I haven't compared against other mail service providers, so I can't give a comparative opinion.
3 replies →
Fastmail finally made their android client work offline too.
I've had a good time with them so far and am a happy customer. You can add as many domains you want and just easily leave if you're no longer happy.
another vote for fastmail, I got my own domain and been slowly changing my email eveywhere away from gmail. No need to do it all in one go. I barely touch my gmail account anymore, feels so freeing!
Thunderbird
Do you mean a self-hosted webmail app? Or a native/multi-platform native email client?
Personally I think Gmail UI is meh - but I no longer use email that much - so terrible UI/ux and no proper quoting/threading support isn't all that problematic.
> introduced proprietary encryption scheme that will pretend to be "open"
You could say the same about Signal, how is signal more open than Gmail.
This signal? Is proprietary?
https://signal.org/docs/
https://github.com/signalapp/libsignal
1 reply →
This is a classic "whataboutism"-style argument: derail the discussion by asking "but what about...".
Setting aside whether what you wrote is true, we are not talking about Signal here.
"send end-to-end encrypted (E2EE) emails to anyone, even if the recipient uses a different email provider" but the video shows Gmail asking the recipient to authenticate. How does that work? If a Gmail user sends an email to my self-hosted server, there is nowhere to authenticate me to.
And it means either Gmail or the actual email stores decryption keys, so what is the threat model in which E2EE is useful here?
The only "advantage" I see is that now recipients must manually archive these "encrypted" emails if they want to keep access to them in the future (so most of them won't). That would be consistent with Google's strategy with AMP's editable emails.
The threat model seems to be "there are other email providers beside Google. How can we change that?"
Not necessarily a threat model that benefits you
> If a Gmail user sends an email to my self-hosted server, there is nowhere to authenticate me to.
They'll probably just force external recipients to create a Google account and verify control over the independent email address...
Exactly this. No different from if someone shares a Google Doc with your email address.
And it makes sense. It's the logical way to prove you have access to the email account.
But that's not end-to-end encryption, that's a pastebin with a login
MITM.
This is likely about regulatory compliance. Many industries require encryption and transit.
In other words?
> The only way that would work if Google could decrypt the message!
They are saying the truth: those emails are "technically" encrypted.
Just nowhere private on the sender side since they won't even keep the keys private.
Now much less private on the receiver side since they have for "reasons" to login into a gmail hosted server and give them data like their IP address and permit other things like browser fingerprinting.
Fantastic, from the title I almost believed they'd be adding private messaging as done by other email providers almost 30 years ago. But not yet.
This is just Google going after those proprietary “end to end encrypted” email services healthcare and other places use. Technically speaking they don’t accomplish anything but from a compliance perspective they seem to satisfy regulators.
Over here "encrypted email" is actually them just sending you a link and a password to a web form in separate mails.
There you enter the password and unlock the content.
"secure mail" my ass.
Looking at the screenshot, this is another recipe for disaster.
A pop-up where you need to authenticate with credentials...
I'm sure no-one will abuse this.
> end-to-end encrypted emails
> without the hassle of exchanging keys
> access the encrypted message via a guest account
Feels like shifting the goalposts and trying to brand a new working definition of E2EE
Can't you read the faq before comment? The "guest account" is hosted on IdP, not necessary google.
https://support.google.com/a/answer/14757842
To me this looks strictly worse than if they just used s/mime with some magic to integrate in the Gmail client for ux.
As I read it[1] - Gmail users are given a hidden s/mime key pair, possibly with secret key stored in a hw token/on device.
I can only assume that when mailing an external user without guest/Gmail account, Gmail will generate a (temporary?) key pair for the recipient, encrypt the message under temporary public key of the recipient - then when recipient creates the guest account - either generate a new key pair and re-encrypt or assign the key pair held for the user? To allow Gmail to decrypt the mail in the browser? As well as implicitly trust the sender key for verification?
I struggle to see how this is e2e in any meaningful sense?
When I log into a public terminal at my library - how will the browser access my keys?
[1] https://support.google.com/mail/answer/13317990?sjid=1138879...
It is not end-to-end if Google has your key.
Well they did go to the trouble of using the date April 1st in the gif!
It don't.
The "Assured Controls" add on put keys on smartcard / hsm not owned by google.
I never liked the term "end-to-end encryption". I guess we can now say it's fully meaningless.
The one thing I've learnt in security after many years is there are no shortcuts. If you don't understand the basics, you can't have security. Things like "end-to-end encryption" are just trying to avoid teaching people the basics by using nice words.
People understand if someone has a copy of their front door key then it's no longer secure and they need to change the locks. So it should be simple to understand encryption too. But most interfaces try to hide away the existence of keys, which is the most basic principle of all. If you don't know where your key is, how can you be secure?
Authenticate where? How does the authentication prove that the intended recipient is the one who has clicked on the link and should be able to view? What happens if the email is forwarded with the link? What should one do to forward the email to someone without this encryption?
Organizations may need ways to store, archive and manage received email content from others.
I don’t understand what problem this solves for organizations and how.
Microsoft Outlook 365 has a somewhat similar feature where the email is just a link to hosted content on its servers (this kind of functionality isn’t new or recent on other platforms). It doesn’t require any authentication by the recipient. IIRC, the sender can also decide on the expiry of the content.
> How does the authentication prove that the intended recipient is the one who has clicked on the link and should be able to view?
You log in with a Google account associated with the recipient address. You prove you control the email by putting in a code Google sends you.
> What happens if the email is forwarded with the link?
They can't open it because they don't have access to the Google account associated with your email address.
> What should one do to forward the email to someone without this encryption?
Obviously, encrypted emails are not meant to be forwarded. Nothing prevents you from taking a photo though. Maybe copy and paste will work.
> Organizations may need ways to store, archive and manage received email content from others.
Organizations can't control how they receive information. It doesn't matter what they want in this regard. If a judge orders them to do something about it, that's for the judge to figure out.
> I don’t understand what problem this solves for organizations and how.
It keeps messages private. You don't see why organizations in e.g. health care, law, or the military want increased privacy of messages in a way that is super easy to use? And where recipients can't accidentally forward sensitive messages? A lot of this is determined by compliance requirements too.
I have used a similar service. Anytime you want to access the link, you must enter a code sent to your email. So if you forward the link, and the person to whom you forward it click the link, they need you to also forward the code to them.
Headers incl. subject are still not encrypted. We've already had that tech 30 years ago.
> We've already had that tech 30 years ago.
S/MIME? Yeah; the tragedy is no-one could figure out a user-friendly UI/UX for the whole thing.
The tragedy is that they seem to have wrapped s/mime in some property nonsense to get this to work (see bottom of):
https://support.google.com/mail/answer/13317990?sjid=1138879...
the ms implementation of smime was pretty good and just worked
(quite something for microsoft)
Only available for Google Workspace: Enterprise Plus with the Assured Controls add-on.
Any idea what those are exactly? Does it only work for recipients on teams with SSO? Or is this just gating who can start these supposedly e2e encrypted email threads?
Looks like recipients can be anyone but would be forced to create a guest account if they don't have one. Which sounds like Google meditating key exchange? Which isn't really e2e encryption at least for the initial message.
Only the higher/highest tier Google Workspace users can send these kind of emails. Anyone can read them.
Those option allows storing private key on smart card.
I think this is just to compete with stuff like Mimecast.
Pretty sure admins can still audit emails even if they're E2EE.
The demo gif looks so weird. So you send someone an email, and (if it's not a gmail) it asks them the log into some mini gmail looking thing to view the actual message?
> preserving enhanced data sovereignty
As in you need google in order to view any of your data?
> end-to-end encrypted
Ah yes end (googles server) to end (also googles server) encryption. Very useful.
Maybe I'm misunderstanding but this genuinely seems completely pointless at best. It's middleman to that same middleman encryption solving the last mile delivery problem by not sending the actual message.
I assume the point here is to check a box in some big corporate's matrix of required features before they'll move to Google Workspace. Nobody really cares whether its really end to end, they just need some to say the magic letters E2E and they can tick it.
An ad company that has been creating ads for years based on what is in your email, is telling us emails will now be encrypted eh? Why do I have my doubts
> that has been creating ads for years based on what is in your email
They stopped that a long time ago. Close to a decade ago IIRC.
It's still free, therefore they didn't.
I don't like cynical takes, even on BigCo like Google, but this totally feels like a "someone wants to get a promotion" type of project.
No, there is a real enterprise need for this, for compliance in certain sectors.
This is about the last kind of thing a company or engineer or PM would build just for fun.
This is a feature that will be genuinely used a bunch. Its use gets mandated, in fact.
How so? You get an email with a link from a GSuite user, you need to put your, I guess, own mail provider user and password and get redirected to a mini-gmail website where you can see the email sent, that can be blocked for copying or removed by the sender as admins can already do in GSuite?
4 replies →
Thing is, with big corporations, cynical takes are usually the correct ones.
All I want from Google Workspace is a single-user email account tied to my domain name. Instead, I have an overly complex system where I need to grant my own phone permission to watch YouTube videos. It would be nice if they had a more basic version.