Google Introduces End-to-End Encryption for Gmail (gizmodo.com) 41
Google Workspace is rolling out a new security update on Gmail, adding end-to-end encryption that aims to provide an added layer of security when sending emails and attachments on the web. From a report: The update is still in the beta stages, but eligible Workspace customers with Enterprise Plus, Education Standard, and Education Plus accounts can fill out an application to test the program through Google's support center. Once the encryption update has been completed, Gmail Workspace customers will find that any sensitive information or data delivered cannot be decrypted by Google's servers.
According to the support center, the application window will be open until January 20, 2023, and once users have accessed the feature, they will be able to choose to turn on the additional encryption by selecting the padlock button when drafting their email. But once activated, some features will be disabled, including emojis, signatures, and Smart Compose. The encryption feature will be monitored and managed by users' administrators and comes after Google started working to add more encryption features to Gmail. The report notes that client-side encryption, or CSE, "is already available for Google Drive, including in apps like Google Docs, Sheets, and Slides. It's also in Google Meet, and is in the beta stage for Google Calendar."
According to the support center, the application window will be open until January 20, 2023, and once users have accessed the feature, they will be able to choose to turn on the additional encryption by selecting the padlock button when drafting their email. But once activated, some features will be disabled, including emojis, signatures, and Smart Compose. The encryption feature will be monitored and managed by users' administrators and comes after Google started working to add more encryption features to Gmail. The report notes that client-side encryption, or CSE, "is already available for Google Drive, including in apps like Google Docs, Sheets, and Slides. It's also in Google Meet, and is in the beta stage for Google Calendar."
Re: (Score:2)
I guess it comes from them previously wanting to monetise their access to your data.
Since they hold the encryption keys, sniffing your email is just additional CPU cycles at this point
Re: feels like 2010 again (Score:2)
No thanks (Score:2)
If I want to encrypt stuff I send through gmail I'm not going to trust google to encrypt it for me. If you trust the browser, though, you could use Mailvelope [mailvelope.com].
Re: (Score:2)
Basically my reaction, though I doubt I know anything valuable enough to call for encryption. Even some evidence from my pre-retirement employer... Paraphrasing and translating, but "Nothing you did in your many years here is worth preserving or annotating." Easy come, easy forgotten?
So how about a Slashdot poll on which giant corporate cancer deserves the most "No, thanks" responses? My own top candidates would be Facebook and Amazon and Exxon, but Microsoft (including LinkedIn?) and the google are pretty
Re: (Score:2)
For example though if you are trying to protect things like credit card numbers, there may not be a lot of risk in Google seeing them.
Have been using S/MIME mails for 27 years now... (Score:3)
(*) Yes, you can use your own CA or Web-of-Trust.
Those declaring themselves unable to utilize the existing open standards for encryption and signatures are probably not to be trusted with sensitive content, anyway, so the argument "... but it's too difficult for aunt Ruth!" is irrelevant to me.
Re:Have been using S/MIME mails for 27 years now.. (Score:5, Insightful)
Those declaring themselves unable to utilize the existing open standards for encryption and signatures are probably not to be trusted with sensitive content, anyway, so the argument "... but it's too difficult for aunt Ruth!" is irrelevant to me.
To be fair, encrypting your email to Aunt Ruth has value too, which is why making it easy is important. When even all the trivially unimportant stuff is encrypted, the actually important encrypted stuff no longer stands out from the rest.
Re: (Score:2)
It's worth noting that Gmail has used encryption in transit for years. Connections between mail servers are encrypted where the server supports it.
This extra layer of security is mostly aimed at keeping corporate IT administrators out of your emails.
Re: Have been using S/MIME mails for 27 years now. (Score:1)
Heh, Lotus Notes offers encrypted mail since 1989, so for 33 years now.
20 years too late (Score:2)
No emojis? (Score:2)
Uhm, they still control the code, don't say? (Score:3)
What keeps them from serving a different set of Javascript to a targeted user which also sends the clear text data to Google if they are forced to do so?
Re: (Score:2)
Same issue with the CSE for Google Drive and Google Docs. The inclusion of 3rd party PKI provider gives the perception Google couldn't get access, even if compelled, but that not the case. The private keys are handled in Google managed code (within the browser).
In layman's terms, paying for a Safe deposit box but then handing over your key to the bank for safe storage. In Google's implementation, you are trusting Google managed code to use private key only within the browser, but theoretically they could s
Does anyone believe them? (Score:1)
Re: (Score:2)
Does anyone believe Google wonâ(TM)t be able to read gmail?
Yes.
Would NSA, FBI & CIA let google loose access to gmail, even if google wanted to implement not trivially breakable encryption?
Yes. They already do. Google will transmit just about any email you send. If it's encrypted using whatever tool you want, they'll send it. If you use gmail as an imap server and your mail client encrypts, they'll send it. This is nothing new to how they do business - just easier for paying customers to use.
I suspect this product won't be available to users in some regions. And/or it will be back doored in some regions - with notice in the fine print.
Re: Does anyone believe them? (Score:1)
Re: (Score:2)
There's a big difference between a few people sending encrypted files with a cumbersome workflow and imperfect operational security, and all of gmail being encrypted.
We're not talking about all of gmail. We're talking about business customers who opt in and make the effort. gmail already serves virtually everyone. And all those business accounts are paying money. And all their users have another personal account. They are gathering all the data they want/need. This is a checkbox for some set of business customers.
I would expect a back door in any large corporate encryption product, post 9/11.
Having worked for an encryption company, I would expect nothing of the sort. Except for non-US countries. Too much liability. Too much hassle.
Re: Does anyone believe them? (Score:2)
There's a hugely important elephant in the room.
As far as the spooks are concerned, what you say is not nearly as interesting as who you regularly say it to.
I agree we should be securely encrypting even the most banal conversations so that encrypted communication doesn't paint a target on your back, but Encryption doesn't hide the who part.
They'll still be able to mine and build up their giant connectivity diagrams so they can decide who to target closer. Once that eye of Sauron is on you, good luck evading
Re: (Score:2)
> Does anyone believe Google wonÃ(TM)t be able to read gmail? I donÃ(TM)t believe it. Would NSA, FBI & CIA let google loose access to gmail, even if google wanted to implement not trivially breakable encryption?
Google pays a lot to lawyers to fight "security state" demands in court. Imagine the savings.
The TLA's you mention can already compromise your endpoint device. The MIC just acquired Pegasus, e.g..
only for business accounts (Score:2)
personal gmails (i.e the bulk of gmail) still not supported
Re: (Score:2)
> personal gmails (i.e the bulk of gmail) still not supported
Key distribution is always the hard part. Administrators will have to deal with it.
What about search? (Score:5, Interesting)
IMHO the best feature of GMail is its full text search which is unmatched in my experience. The original selling point was "don't delete, search", and while the "don't delete" part with its 1GB storage got most of the attention back then, the "search" part was also key to its success, and it still is.
With end-to-end encryption, server-side indexing is essentially impossible, so in order to do a full text search, you have to download you entire inbox, decrypt it, and index it locally, which may require GBs of bandwidth, and significant processing power. That's what ProtonMail does btw.
So: either this is a crippled version of GMail, or it is not really end-to-end, or it is something really awesome that I am not aware of.
Re: (Score:3)
You will have to rely on secondary features like tagging. Obviously not ideal, but also far better than anything we have now.
Yes there is GPG and Thunderbird. Try getting your contacts to use it.
Re: What about search? (Score:2)
Proton, tuta, et-al solve this by indexing in the client.
I would hope they are encrypting the index and storing it server-side because it'd be a pretty annoying task to re-index my entire mailbox if I ever connected a second client to it.
Re: (Score:1)
Don't delete. It is not like we will start rejecting incoming email when your mailbox is full. Apart from rejecting emails with false messages when our own infra fails or when devs read one chapter in rfc2822 specs and implement reject policy based on that.
Re: (Score:2)
Well, yes: search within encrypted stuff is hard...
For proper e2e encryption (using GPG), there is still a big discussion within email client dev communities (I mainly know about kmail and thunderbird) about whether encrypted emails should be indexed, as then the content would no longer be encrypted (ie indexed in plain text in the indexing engine). Also the indexing must happen only when the email is explicitly opened. It's a complicated issue.
BTW the same issue is with e2e encrypted chat: should the local
Re: (Score:3)
Danger.... (Score:3)
Is it really end-to-end even if the other end is not on GMail? Or is it only between two GMail mailboxes and therefore a trap to lock people in?
Re: Danger.... (Score:3)
I was wondering the same. How can GMail ensure they will use secure MTA channels if one of the parties do not support, partially support or has broken security configurations on their end? Either the article title is misleading and in reality this is a GMail only internal solution, or I am very curious how Google has, out of the blue, resolved and fixed all SMTP problems found in the past 40 years, without touching other MTAs out there.
LOL (Score:1)
Doesn't it already have end to end encryption? (Score:1)
Re: (Score:3)
This allows the browser to encrypt the emails with your Yubikey. The percentage of companies that want employees to send emails that the legal and compliance teams can't access has to be vanishingly small.
This is probably a feature for something like FedRamp or some other security certification that requires the company to control the keys of all its encrypted data and not delegate the keys to a larger less incompetent Organization (I'm specifically thinking of the health care space here)
Re: (Score:3)
> Your browser accesses Gmail using HTTPS. That means your end is encrypted, and the other end (Gmail server) is encrypted.
Yes, by misdefining the ends, everything is end-to-end encrypted.
thunderbird + openpgp (Score:3)
I use Thunderbird with the OpenPGP plugin to have very strong encryption on the rare occasion I require it. It only works with people who use PGP/GPG, but it's damn secure.
Re: (Score:3)
I use Thunderbird with the OpenPGP plugin to have very strong encryption on the rare occasion I require it. It only works with people who use PGP/GPG, but it's damn secure.
Is it so secure that the intended recipients can't read the email that you send to them? Or is setting up PGP/GPG and the whole key thing much easier now?
Email client (Score:3)
misleading - it's not end-to-end encryption (Score:3)
.
With end-to-end encryption (e2e), encryption and decryption always occur on the source and destination devices (such as on mobile phones for instant messaging). Encryption keys are generated on the client, so as an administrator, you don't have control over the keys on the clients and who can use them. In addition, you don't have visibility into which content users have encrypted.
With client-side encryption (CSE), encryption and decryption also always occur on the source and destination devices, which in this case are the clients' browsers. However, with CSE, clients use encryption keys that are generated and stored in a cloud-based key management service, so you can control the keys and who has access to them. For example, you can revoke a user's access to keys, even if that user generated them. Also, with CSE, you can monitor users' encrypted files.