>Availability
>
>Available to Google Workspace Enterprise Plus, Education Plus, and Education Standard customers
>Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers
>Not available to users with personal Google Accounts
Also to be available it must first be enabled by a workspace admin, then by the end user.
To me this feature looks like a box ticking exercise with an eye toward government contracts. Microsoft has it so Google needs it too in order to avoid looking less secure to decision makers who may not know whether or not it will ever be needed.
Availability
* Available to Google Workspace Enterprise Plus, Education Plus, and Education Standard customers
* Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers
* Not available to users with personal Google Accounts
i think i read all the blog posts and announcements, yet i can't for the life of me find a technical explanation of what exactly this does.
it looks like it could be like s/mime, or possibly a scheme for encrypting the contents of messages stored in gmail accounts. where are the keys stored? what is the threat model?
Can you only send encrypted messages to recipients who also use Google? If it isn't S/MIME then as far as I'm concerned it almost isn't email. Anyone can already make encrypted ZIP files or other proprietary encrypted attachments and send them via email. If it's not S/MIME, it feels like just a convenience layer on top of that.
It’s primarily for industries with strict regulatory/compliance requirements on managing sensitive data. The more detailed description is at [1]. Keys are stored in a cloud service, admins and end users use SSO to retrieve a key whenever they need to access an encrypted document. This is supposed to let companies do things like enforce rules on forwarding or printing sensitive emails, revoke access to particular documents if needed, and reduce the scale and risk of leaks if Google or an individual user account was breached. Of course, it’s not perfect in practice.
These days, people really should get their own domain and host there email there. If you do not know how to do this, there are plenty of cheap hosting companies you can use.
And if you want to encrypt, use gnupg or that thing Thunderbird now uses. I am a mutt user and gnupg with mutt is rather easy.
This is purely marketing AFAIT. I don't see how it provides any protection against the 5 eyes or having one's google account breached. The encryption/decription is done with javascript code served to your browser by google (= can be hijacked/changed/…)
The only way to do client side encryption is PGP on a native client distributed by a third party.
I think the primary benefit is that in theory you can cut Google off at any time. If you disable the key service they can no longer decrypt your data. So if you decided that Google is no longer trustworthy you can leave and they can't access your data.
Of course this is sort of an odd game where you need to cut their access off before they backdoor it, so you have to somehow predict that Google is going to become malicious and beat them to the punch. If you a reacting to something that they are doing it likely isn't helping much.
Another possible advantage is that you could potentially have logging on key access which could give some idea of data usage. So if Google starts requesting keys for all of your stored data then you can be suspicious that they are siphoning up your data. (Or doing some background maintenance? Who knows?)
In practice this is probably mostly checkbox theater where it is a feature that Google and their users can list.
Except that we've got two decades of evidence of people regularly fucking up PGP leaking the contents of entire email threads. If the only thing that works is PGP then nothing works.
If the key is encrypted with your password, I don't see how that compromises security by a lot. If they adapt the javascript to break encryption on a large scale, that would sooner or later come out.
Yes, they could target specific people, deliver different javascript and break their encryption, but in general it's still a huge security gain. It makes it impossible for Google to handover E-Mails retrospectively to police or spy agencies.
Not saying much. Same is true about any e2e encrypted messaging (Telegram, Signal, etc.)
There's no way to tell if they are intercepting your messages clientside, and you'd have to monitor all the network traffic (which would be encrypted with their keys) to detect exfiltration.
>I don't see how it provides any protection against the 5 eyes or having one's google account breached.
It isn't supposed to protect you from government agencies. Really what this feature is, is 1) e2e of email, and 2) integration with an external enterprise key management service.
#2 means that at very least, your org will have access to your keys and therefore all encrypted mail, and if they have access to that, then they are open to things like subpoenas from law enforcement.
Wonder if there's a browser plugin that can calculate SHA 256 checksum for a page and all linked JS - to help verify that the encryption/decription code has not been compromised.
I'm surprised it took them this long. Outlook/Exchange has supported IRM protected emails since 2007. Little things like these show why Microsoft has an unassailable lead in enterprise software and Google, despite all of its resources, is forever playing catch up.
Maybe they're trying to penetrate more the Enterprise market where usually people are very nervous about not having on-prem e-mail and full control of the data.
This is supposed to give them some guarantees that the data is locked&safe outside of their premises.
Naturally they have reinvented the proprietary wheel instead of implementing PGP, so that their domesticated users are nicely corralled in their walled garden.
I’m speculating about how this works, but it probably doesn’t make sense for general-purpose email.
For emails between members of one workspace/domain, you can conceptually perform key exchange to implement client-side encryption. You also don’t have spam concerns within members of a workspace.
There’s no general way to do key exchange between different email domains, and you do have spam concerns (which to address requires scanning the content).
There’s no protocol for doing such things over different email domains in a way that’s compatible and interoperable across software stacks. This technology is proprietary, and would make spam challenging to deal with (which again is not a problem within one workspace).
It’s also not clear to me whether this is really client-side encryption, so much as encryption at a layer higher than the email stack. (It’s pretty hard to do client-side encryption in the browser, in a way that matches user expectations. How do you store/retrieve the encryption key?)
[+] [-] xinu2020|3 years ago|reply
Also to be available it must first be enabled by a workspace admin, then by the end user.
[+] [-] fauigerzigerk|3 years ago|reply
[+] [-] we_never_see_it|3 years ago|reply
Just out of curiosity, why would you expect anything different?
[+] [-] kybernetikos|3 years ago|reply
[+] [-] Neil44|3 years ago|reply
[+] [-] idiotsecant|3 years ago|reply
[deleted]
[+] [-] cientifico|3 years ago|reply
[+] [-] deelowe|3 years ago|reply
[+] [-] paxys|3 years ago|reply
Whether it is available to everyone for free, requires a specific plan etc. is not part of the determination.
[+] [-] a-dub|3 years ago|reply
it looks like it could be like s/mime, or possibly a scheme for encrypting the contents of messages stored in gmail accounts. where are the keys stored? what is the threat model?
can anyone enlighten?
[+] [-] zugi|3 years ago|reply
[+] [-] resfirestar|3 years ago|reply
[1] https://support.google.com/a/answer/10741897
[+] [-] jmclnx|3 years ago|reply
These days, people really should get their own domain and host there email there. If you do not know how to do this, there are plenty of cheap hosting companies you can use.
And if you want to encrypt, use gnupg or that thing Thunderbird now uses. I am a mutt user and gnupg with mutt is rather easy.
[+] [-] datpiff|3 years ago|reply
It seems to be a giant pain in the ass, and might be impossible in some circumstances
https://cfenollosa.com/blog/after-self-hosting-my-email-for-...
[+] [-] jeremyjh|3 years ago|reply
[+] [-] coffeeblack|3 years ago|reply
[+] [-] jvolkman|3 years ago|reply
[+] [-] pyuser583|3 years ago|reply
[+] [-] Kiro|3 years ago|reply
[+] [-] JadoJodo|3 years ago|reply
So nothing for power users?
[+] [-] acatton|3 years ago|reply
The only way to do client side encryption is PGP on a native client distributed by a third party.
[+] [-] kenniskrag|3 years ago|reply
can be self hosted.
[+] [-] kevincox|3 years ago|reply
Of course this is sort of an odd game where you need to cut their access off before they backdoor it, so you have to somehow predict that Google is going to become malicious and beat them to the punch. If you a reacting to something that they are doing it likely isn't helping much.
Another possible advantage is that you could potentially have logging on key access which could give some idea of data usage. So if Google starts requesting keys for all of your stored data then you can be suspicious that they are siphoning up your data. (Or doing some background maintenance? Who knows?)
In practice this is probably mostly checkbox theater where it is a feature that Google and their users can list.
[+] [-] UncleMeat|3 years ago|reply
[+] [-] Gasp0de|3 years ago|reply
Yes, they could target specific people, deliver different javascript and break their encryption, but in general it's still a huge security gain. It makes it impossible for Google to handover E-Mails retrospectively to police or spy agencies.
[+] [-] tantalor|3 years ago|reply
There's no way to tell if they are intercepting your messages clientside, and you'd have to monitor all the network traffic (which would be encrypted with their keys) to detect exfiltration.
[+] [-] macspoofing|3 years ago|reply
It isn't supposed to protect you from government agencies. Really what this feature is, is 1) e2e of email, and 2) integration with an external enterprise key management service.
#2 means that at very least, your org will have access to your keys and therefore all encrypted mail, and if they have access to that, then they are open to things like subpoenas from law enforcement.
[+] [-] Idiot_in_Vain|3 years ago|reply
[+] [-] Gasp0de|3 years ago|reply
Edit: Found out that it doesn't: https://support.google.com/a/answer/10741897#zippy=%2Cwhich-...
[+] [-] paxys|3 years ago|reply
[+] [-] margorczynski|3 years ago|reply
This is supposed to give them some guarantees that the data is locked&safe outside of their premises.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] ddevault|3 years ago|reply
[+] [-] DeepYogurt|3 years ago|reply
[+] [-] belltaco|3 years ago|reply
> Not available to users with personal Google Accounts
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] bgitarts|3 years ago|reply
Why not?
[+] [-] jcrites|3 years ago|reply
For emails between members of one workspace/domain, you can conceptually perform key exchange to implement client-side encryption. You also don’t have spam concerns within members of a workspace.
There’s no general way to do key exchange between different email domains, and you do have spam concerns (which to address requires scanning the content).
There’s no protocol for doing such things over different email domains in a way that’s compatible and interoperable across software stacks. This technology is proprietary, and would make spam challenging to deal with (which again is not a problem within one workspace).
It’s also not clear to me whether this is really client-side encryption, so much as encryption at a layer higher than the email stack. (It’s pretty hard to do client-side encryption in the browser, in a way that matches user expectations. How do you store/retrieve the encryption key?)
[+] [-] 0x53|3 years ago|reply
[+] [-] _theskumar|3 years ago|reply
How the key is generated, where it is stored, and which encryption is used.