10 ms·

Google introduces end-to-end encryption for Gmail on the web

213 points by amadeuspagel 4y ago

mark_l_watson 4y ago
Well, I say good for Google! I recently, after years of being a paid ProtonMail customer, cancelled, and settled for Apple Mail with a custom domain. Apple specifically does not encrypt email, but with their new Advanced Data Protection, which I use (I have also been using Lockdown Mode for a few months), I decided that while no large corporation is truly trustworthy, we all need to make a decision of what our personal requirements are, and Apple was “good enough.” What I like about Google’s announcement is that even though this is only enabled now for Workspaces, if Google opens this to all GMail users then a large percentage of e-mail will be gmail to gmail encrypted. This is what disappointed me about ProtonMail: they didn’t have a critical mass of users. I only had one other non-work friend who used ProtonMail.
danuker 4y ago
Only for Google Workspace for now.
rep_movsd 4y ago
How can closed source software ever prove that the communication on the wire is actually secure? I guess since gmail is JS on the client side, some smart programmer can unpack the code and show that the crypto is sound. But until then it's only claims
- throwaway0x7E6 4y ago
  an audit like that doesn't even matter when the client is hosted remotely
  - Closi 4y ago
    It's not, the client is local.
  - EnigmaCurry 4y ago
    I don't think it can be done today, with the remote domain (gmail.com) controlling all the JS on the page. But maybe future hardened browsers could attach a textinput box directly to a sandboxed service worker not communicable with the rest of the JS code? The worker could be updated at a different cadence than the rest of the client, and be audited separately, and with the script contents hashed? We rely on browser sandboxing of different domains today, why not extend it to different parts of the same page? Its probably a hard problem still.
- progbits 4y ago
  Closed source or not, the trust comes from provider serving you the same payload. Even if it was open source it could be changed. So if you care about that you can't trust any webmail. Instead use Thunderbird/mutt/whatever and GPG/PGP, like you could for the last 20+ years.
  - upofadown 4y ago
    You could at least use a browser plugin like Mailvelope...
- brookst 4y ago
  Open source has the same problem. You can review source, great, but you can’t prove it’s the same source that’s executing. From evil compilers to source/binary modification in flight to supply chain attacks, it is probably impossible to prove secure operation of open (or closed) source. All we have are mitigations and risk reduction. If the bar is provably perfect security, nothing can meet it.
  - fsflover 4y ago
    You can verify that the executable came from the same sources: https://reproducible-builds.org/ https://reproducible-builds.org/.
    - okdood64 4y ago
      How do I obtain the all the executables in the chain?
    - brookst 4y ago
      How do you know the tools you use to verify weren’t modified in memory? Seriously. It is not possible to prove 100% security. Between human, electrical, hardware, firmware, and software vulnerabilities, there is always a gap.
      - fsflover 4y ago
        Nothing is ever 100%, but some things are good enough. By the way, I am using Qubes OS for reasonable security.
        brookst 4y ago
        You’ve absolutely illustrated my two points: 1) nothing is ever 100%, and 2) everyone thinks their personal choices are the ideal; anything less secure is playing with fire, anything more secure is unnecessary overkill.
        4y ago
rincebrain 4y ago
Back in 200X, a graduate student acquaintance of mine had, for a research project, written a browser extension which transparently (as I recall, GPG) encrypted your emails in Gmail to people and decrypted those from them. I recall how pleased he was demonstrating it to people, and how much smoother and simpler it was than integrating GPG manipulation in your separate mail client. All that to say, this is something at least some people have thought would be useful for some time, and it's nice to see some people getting access to that functionality. (Now work for Google, not on anything remotely related to Gmail, remarks are my own, etc etc.)
- m348e912 4y ago
  Did he ever publish the browser extension? Seems like a cool idea.
  - rincebrain 4y ago
    I don't actually know. I know a few people have linked things which solve the same problem in other comments, but I checked, and neither of the ones linked so far appear to be related, just nice illustrations that yes, other people have had the same problem to solve. But to the best of my knowledge, he graduated without suggesting we all start using his extension to take over the world, and I've not found any suggestions it was published.
- bertman 4y ago
  Sounds like Mailvelope. https://mailvelope.com/en/ https://mailvelope.com/en/
- yegle 4y ago
  http://getfiregpg.org http://getfiregpg.org was pretty widely used back in the days. Their Gmail integration would be broken from time to time due to the Gmail web update.
deleted 4y ago
[deleted]
clementmas 4y ago
I just wish Gmail would let me rename email subjects
- bwb 4y ago
  you can do this, its just hidden, next to the responder is an arrow curving it to the left, click on edit and subject :) i couldn't find this for years either
rdl 4y ago
This is nice for protecting against compelled legal disclosure in the US, but Google could just serve js in the future (targeted to specific users only, if they want) to capture password/key. This is the problem with repeatedly downloading a client which isn't inherently trusted/from the same party holding the ciphertext. Same thing happened LONG ago with hushmail, which used a java applet to do encrypted email -- at some point they chose to serve a "special" applet to some users.
- sowbug 4y ago
  You're not wrong, but is there any common client software today that isn't susceptible to rogue updates?
  - kijiki 4y ago
    It is trivial to serve different javascript to different clients on a request by request basis, making it very unlikely that highly targeted malicious js will be detected. Most thick client update mechanisms make this more difficult (but certainly not impossible) thus greatly increasing the risks of embedded malware being detected. Signal, for example, is reproducibly built, so you can diff the source of each new update and then verify that you get the same binary. This gives you very good assurance that your audit of those diffs is valid to the binary on your phone.
    - sowbug 4y ago
      Thanks. I understand autoupdate and web infrastructure, as well as the Ken Thompson hack that resolves all these cases into the same threat. The question was rhetorical. I doubt that someone who has invested the time in developing code-auditing skills also values their own time so little that they'd audit and build their chat client. And if they're willing to farm auditing out to someone else, or to vouch to other users of the app, then they've lost the plot. Not saying such a person couldn't exist. But the intersection in the Venn diagram seems small.
      - rdl 4y ago
cphoover 4y ago
How will this impact googles ad business? I thought Google was targeting using email content... Also this will impact their ability to use AI for things like spam filtering and smart labeling "You upload a user’s S/MIME certificate and wrapped private key using the Gmail API, with the service account private key file. For each user" If this is end to end encryption why are you uploading a private key to Google? Am I confused?
- progbits 4y ago
  No, content is not used. > When you open Gmail, you'll see ads that were selected to show you the most useful and relevant ads. The process of selecting and showing personalized ads in Gmail is fully automated. These ads are shown to you based on your online activity while you're signed into Google. We will not scan or read your Gmail messages to show you ads. https://support.google.com/mail/answer/6603?hl=en https://support.google.com/mail/answer/6603?hl=en
- da-bacon 4y ago
  Google stopped using email for ad targeting https://www.theverge.com/2017/6/23/15862492/google-gmail-advertising-targeting-privacy-cloud-business https://www.theverge.com/2017/6/23/15862492/google-gmail-adv...
  - cphoover 4y ago
    Interesting how will Gmail handle spam classification with e2e encryption?
    - goguy 4y ago
      Based on their performance recently, badly.
    - devrand 4y ago
      AFAICT this feature is mostly for internal (to your domain) emails as you need to supply your own identity provider for key management. I don’t believe a random external sender will be able to send an E2E encrypted email. Or at least not in a way that would be readable by the recipient.
nonrandomstring 4y ago
This would be amazing if Google use anything like an open standard for their cryptography, so that anyone can write and use interoperable mail client plugins, or use GPG to talk to gmail users e2ee. Why am I haunted by the suspicion that won't be the case?
- amaccuish 4y ago
  It's using S/MIME https://support.google.com/a/answer/13069736?visit_id=638068907796437738-233783484&p=cse_gmail&rd=2#zippy=%2Cprepare-your-account https://support.google.com/a/answer/13069736?visit_id=638068...
  - nonrandomstring 4y ago
    That opens it right up. Pleased to be wrong in my suspicion. I see that it's possible to configure Mutt [1] and Gnus [2] with SMIME. Perhaps 2023 will finally be the year of encrypted email. [1] https://wiki.netbsd.org/users/wiz/mutt-smime/ https://wiki.netbsd.org/users/wiz/mutt-smime/ [2] https://www.emacswiki.org/emacs/GnusSMIME https://www.emacswiki.org/emacs/GnusSMIME
    - upofadown 4y ago
      I wouldn't get too excited. This only seems to be the addition of S/MIME client capability for Google corporate email customers. So the Google corporate customer will still have to procure, renew and pay for a S/MIME certificate for each and every employee. That isn't something that companies have shown much interest in up to this point. This does not affect non-corporate Gmail users...
    - ccouzens 4y ago
      This is also cool because unlike a lot of other end to end systems you don't have to trust the client they provided you with.
superkuh 4y ago
What a pointless display of security theater. As long as both end-points are google it doesn't matter. It's like a centralized company using a blockchain instead of a database. Yeah, neat, you implemented it... but it doesn't get you anything except press.
- mort96 4y ago
  This is my feeling about... well, basically every "end-to-end encrypted" product. With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). WhatsApp also claims to be "end-to-end encrypted", but there the app isn't even open source so both ends are just 100% Facebook-controlled without even a facade of transparency. Same with Apple's end-to-end encrypted stuff, where everything is encrypted on their servers but for all I know they can just ask my device that's running their closed software to send them information. I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.
  - crgwbr 4y ago
    Even if the app is open source with reproducible builds, you have to trust the OS. Are you going to audit every line of the entire operating system? If you do that, are you going to audit every transistor in the SoC to ensure the hardware isn’t compromised in some way? No one person can do that. Even if a team of people could do it, do you trust the other people? At some point, you have to trust _something_. If you don’t, you simply can’t use computers.
    - yazzku 4y ago
      This does not take away from the parent's point. You need to trust something, yes; we just don't trust Google in particular in that whole chain of trust.
      - scarface74 4y ago
Not_Admin 4y ago
Emails are inherently flawed for security/privacy. If you're sending something you think nobody should see it don't do it with emails.
- imhoguy 4y ago
  You can say the same about any Internet-connected device communication.
  - Not_Admin 4y ago
    Yes you can, not everything we use needs to have military-grade encryption. Things like email should be kept simple. This is the problem we have with software today, everything is just glued together to produce a pile full of complex shit. "Oh.. lets add end-to-end encryption for gmail so people can be at rest when receiving their spam promotion emails".
wankle 4y ago
I just want them to let me set the same theme we had up until recently. I don't want blueish or soft gray I want what it was the past several years. If they can't do that then give me the legacy look back.
upofadown 4y ago
>Client-side encryption (as Google calls E2EE) was already available for users of Google Drive, Google Docs, Sheets, Slides, Google Meet, and Google Calendar (beta). Those things are client-side encryption. End to end implies more than the one end. Which is a good thing. Who would want to have to compare a key fingerprint just so they could securely store files in the cloud? With client side encryption the identity management comes for free...
cj 4y ago
How is this different from the long existing support for S/MIME which has been available for years in gmail (and available for admin setup via Google Workspace)? Is the main news that S/MIME encryption can now happen in the browser instead of Google’s backend?
a-dub 4y ago
the last time i heard about s/mime was the last time they were talking about section 230. i'm starting to wonder if this is actually just a coincidence...
theptip 4y ago
Folks complaining about how this doesn’t solve the “I don’t trust Google” threat model are missing the point - this is a compliance feature so you can work with PII and still comply with regulations like PCI that require you to encrypt everything in transit and at rest. Previously you’d need an expensive third party product like Virtru, so it’s great news for users that this is just a bundled feature now. “Security theater” is probably fair, as is much of the compliance regime. However this probably does make it harder for a back-office admin to accidentally/absentmindedly save files with PII to their machine in breach of policy, as the UI makes it clear the files/content are Top Secret.
- Existenceblinks 4y ago
  I think so .. it's something I can point a finger to for those who need and trust whatever this is. "compliance regime" explains it all.
- pmontra 4y ago
  But if it is security theater, how is that compliant with regulations? Hopefully regulators could see or could be pointed to see through the curtain. I guess that plenty of people will be monitoring the packets transmitted over their network. The client side encryption/decryption process is described at https://developers.google.com/workspace/cse/guides/overview https://developers.google.com/workspace/cse/guides/overview If I got it right, Google generates a key and sends it to the external service that stores the keys of the user. That service uses a Google API with probably Google's and the user keys [1] to encrypt the message (and this is quite disturbing, imagine if every company would require key management services to use its own API - Office365, Apple, second tier mail providers, etc.) and finally Google stores the encrypted message. Similar procedure to decrypt. At a first glance Google is not able to see the message, except that they provide the browser to most people and the OS too (Chromebooks and especially Android.) However we're back to monitoring the network packets for suspicious traffic to Google. What I'm more concerned about is regulatory capture through compliance. If E2E messages become the new normal either clients like Thunderbird (desktop) or K9 (mobile) implement an interoperable E2E system or more sooner than later it will be impossible to use them to mail customers and maybe friends too. And uncountable IMAP / POP3 / SMTP libraries for a lot of different languages: they eventually have to display the message and encrypt it before sending it. Of course I'm all in for encrypted email but let's hope everybody can jump on it no matter the mail client they use. I'd hate that the only choices left will be GMail, Apple and Office365 (if they'll be able to talk to each other.) [1] https://developers.google.com/workspace/cse/guides/encrypt-and-decrypt-data https://developers.google.com/workspace/cse/guides/encrypt-a...
kitd 4y ago
Caveat: "What's encrypted in Gmail: Email body and attachments, including inline images Not encrypted in Gmail: The header of the email, including subject, timestamps, and recipients lists"
- anonymoose33281 4y ago
  Oh, that’s… that’s a little concerning.
  - bpodgursky 4y ago
    I mean, come on, recipient lists you can't encrypt. Google needs to figure out where to send the email. Subjects is a concession to search and filters. Nobody is trying to shove PHI into a subject line... doesn't seem like a big deal imo.
    - yazzku 4y ago
      On the other hand Signal has "sealed sender", so while they know the recipient, they don't know the sender: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ I guess another example of why it's hard to retrofit email for security and privacy.
    - dogmatism 4y ago
      >Nobody is trying to shove PHI into a subject line lol
greggarious 4y ago
Of course, right after I get locked out of the account I had since I was a teenager (and years of encryption advocacy) both gmail and icloud roll out changes that I wanted back in 2009. Too little, too late, we will never regain what was lost.
tyiz 4y ago
So they use encryption accessible for CIA?
max-ibel 4y ago
I guess this means search features will only be for metadata (to, from, subject?) That’s a pretty hard sell for power users…
- nicce 4y ago
  Not really. Other vendors gives a date range for your search, download it for cache in client and then searches it. It takes more resources but it is possible.
  - max-ibel 4y ago
    My searches routinely would require searches over GBs of data …
therealmarv 4y ago
This is the development we want to see. Would be great if this would be the main mission for Google for the next 5 years. To enable E2E for most private data (Mail, Drive, Notes) and stop location tracking.
deleted 4y ago
[deleted]

213 points by amadeuspagel 4y ago

Well, I say good for Google! I recently, after years of being a paid ProtonMail customer, cancelled, and settled for Apple Mail with a custom domain. Apple specifically does not encrypt email, but with their new Advanced Data Protection, which I use (I have also been using Lockdown Mode for a few months), I decided that while no large corporation is truly trustworthy, we all need to make a decision of what our personal requirements are, and Apple was “good enough.” What I like about Google’s announcement is that even though this is only enabled now for Workspaces, if Google opens this to all GMail users then a large percentage of e-mail will be gmail to gmail encrypted. This is what disappointed me about ProtonMail: they didn’t have a critical mass of users. I only had one other non-work friend who used ProtonMail.

danuker 4y ago

Only for Google Workspace for now.

rep_movsd 4y ago

How can closed source software ever prove that the communication on the wire is actually secure? I guess since gmail is JS on the client side, some smart programmer can unpack the code and show that the crypto is sound. But until then it's only claims

throwaway0x7E6 4y ago
an audit like that doesn't even matter when the client is hosted remotely
- Closi 4y ago
  It's not, the client is local.
- EnigmaCurry 4y ago
  I don't think it can be done today, with the remote domain (gmail.com) controlling all the JS on the page. But maybe future hardened browsers could attach a textinput box directly to a sandboxed service worker not communicable with the rest of the JS code? The worker could be updated at a different cadence than the rest of the client, and be audited separately, and with the script contents hashed? We rely on browser sandboxing of different domains today, why not extend it to different parts of the same page? Its probably a hard problem still.
progbits 4y ago
Closed source or not, the trust comes from provider serving you the same payload. Even if it was open source it could be changed. So if you care about that you can't trust any webmail. Instead use Thunderbird/mutt/whatever and GPG/PGP, like you could for the last 20+ years.
- upofadown 4y ago
  You could at least use a browser plugin like Mailvelope...
brookst 4y ago
Open source has the same problem. You can review source, great, but you can’t prove it’s the same source that’s executing. From evil compilers to source/binary modification in flight to supply chain attacks, it is probably impossible to prove secure operation of open (or closed) source. All we have are mitigations and risk reduction. If the bar is provably perfect security, nothing can meet it.
- fsflover 4y ago
  You can verify that the executable came from the same sources: https://reproducible-builds.org/ https://reproducible-builds.org/.
  - okdood64 4y ago
    How do I obtain the all the executables in the chain?
  - brookst 4y ago
    How do you know the tools you use to verify weren’t modified in memory? Seriously. It is not possible to prove 100% security. Between human, electrical, hardware, firmware, and software vulnerabilities, there is always a gap.
    - fsflover 4y ago
      Nothing is ever 100%, but some things are good enough. By the way, I am using Qubes OS for reasonable security.
      - brookst 4y ago
        You’ve absolutely illustrated my two points: 1) nothing is ever 100%, and 2) everyone thinks their personal choices are the ideal; anything less secure is playing with fire, anything more secure is unnecessary overkill.
        4y ago

rincebrain 4y ago

Back in 200X, a graduate student acquaintance of mine had, for a research project, written a browser extension which transparently (as I recall, GPG) encrypted your emails in Gmail to people and decrypted those from them. I recall how pleased he was demonstrating it to people, and how much smoother and simpler it was than integrating GPG manipulation in your separate mail client. All that to say, this is something at least some people have thought would be useful for some time, and it's nice to see some people getting access to that functionality. (Now work for Google, not on anything remotely related to Gmail, remarks are my own, etc etc.)

m348e912 4y ago
Did he ever publish the browser extension? Seems like a cool idea.
- rincebrain 4y ago
  I don't actually know. I know a few people have linked things which solve the same problem in other comments, but I checked, and neither of the ones linked so far appear to be related, just nice illustrations that yes, other people have had the same problem to solve. But to the best of my knowledge, he graduated without suggesting we all start using his extension to take over the world, and I've not found any suggestions it was published.
bertman 4y ago
Sounds like Mailvelope. https://mailvelope.com/en/ https://mailvelope.com/en/
yegle 4y ago
http://getfiregpg.org http://getfiregpg.org was pretty widely used back in the days. Their Gmail integration would be broken from time to time due to the Gmail web update.

deleted 4y ago

[deleted]

clementmas 4y ago

I just wish Gmail would let me rename email subjects

bwb 4y ago
you can do this, its just hidden, next to the responder is an arrow curving it to the left, click on edit and subject :) i couldn't find this for years either

rdl 4y ago

This is nice for protecting against compelled legal disclosure in the US, but Google could just serve js in the future (targeted to specific users only, if they want) to capture password/key. This is the problem with repeatedly downloading a client which isn't inherently trusted/from the same party holding the ciphertext. Same thing happened LONG ago with hushmail, which used a java applet to do encrypted email -- at some point they chose to serve a "special" applet to some users.

sowbug 4y ago
You're not wrong, but is there any common client software today that isn't susceptible to rogue updates?
- kijiki 4y ago
  It is trivial to serve different javascript to different clients on a request by request basis, making it very unlikely that highly targeted malicious js will be detected. Most thick client update mechanisms make this more difficult (but certainly not impossible) thus greatly increasing the risks of embedded malware being detected. Signal, for example, is reproducibly built, so you can diff the source of each new update and then verify that you get the same binary. This gives you very good assurance that your audit of those diffs is valid to the binary on your phone.
  - sowbug 4y ago
    Thanks. I understand autoupdate and web infrastructure, as well as the Ken Thompson hack that resolves all these cases into the same threat. The question was rhetorical. I doubt that someone who has invested the time in developing code-auditing skills also values their own time so little that they'd audit and build their chat client. And if they're willing to farm auditing out to someone else, or to vouch to other users of the app, then they've lost the plot. Not saying such a person couldn't exist. But the intersection in the Venn diagram seems small.
    - rdl 4y ago

cphoover 4y ago

How will this impact googles ad business? I thought Google was targeting using email content... Also this will impact their ability to use AI for things like spam filtering and smart labeling "You upload a user’s S/MIME certificate and wrapped private key using the Gmail API, with the service account private key file. For each user" If this is end to end encryption why are you uploading a private key to Google? Am I confused?

progbits 4y ago
No, content is not used. > When you open Gmail, you'll see ads that were selected to show you the most useful and relevant ads. The process of selecting and showing personalized ads in Gmail is fully automated. These ads are shown to you based on your online activity while you're signed into Google. We will not scan or read your Gmail messages to show you ads. https://support.google.com/mail/answer/6603?hl=en https://support.google.com/mail/answer/6603?hl=en
da-bacon 4y ago
Google stopped using email for ad targeting https://www.theverge.com/2017/6/23/15862492/google-gmail-advertising-targeting-privacy-cloud-business https://www.theverge.com/2017/6/23/15862492/google-gmail-adv...
- cphoover 4y ago
  Interesting how will Gmail handle spam classification with e2e encryption?
  - goguy 4y ago
    Based on their performance recently, badly.
  - devrand 4y ago
    AFAICT this feature is mostly for internal (to your domain) emails as you need to supply your own identity provider for key management. I don’t believe a random external sender will be able to send an E2E encrypted email. Or at least not in a way that would be readable by the recipient.

nonrandomstring 4y ago

This would be amazing if Google use anything like an open standard for their cryptography, so that anyone can write and use interoperable mail client plugins, or use GPG to talk to gmail users e2ee. Why am I haunted by the suspicion that won't be the case?

amaccuish 4y ago
It's using S/MIME https://support.google.com/a/answer/13069736?visit_id=638068907796437738-233783484&p=cse_gmail&rd=2#zippy=%2Cprepare-your-account https://support.google.com/a/answer/13069736?visit_id=638068...
- nonrandomstring 4y ago
  That opens it right up. Pleased to be wrong in my suspicion. I see that it's possible to configure Mutt [1] and Gnus [2] with SMIME. Perhaps 2023 will finally be the year of encrypted email. [1] https://wiki.netbsd.org/users/wiz/mutt-smime/ https://wiki.netbsd.org/users/wiz/mutt-smime/ [2] https://www.emacswiki.org/emacs/GnusSMIME https://www.emacswiki.org/emacs/GnusSMIME
  - upofadown 4y ago
    I wouldn't get too excited. This only seems to be the addition of S/MIME client capability for Google corporate email customers. So the Google corporate customer will still have to procure, renew and pay for a S/MIME certificate for each and every employee. That isn't something that companies have shown much interest in up to this point. This does not affect non-corporate Gmail users...
  - ccouzens 4y ago
    This is also cool because unlike a lot of other end to end systems you don't have to trust the client they provided you with.

superkuh 4y ago

What a pointless display of security theater. As long as both end-points are google it doesn't matter. It's like a centralized company using a blockchain instead of a database. Yeah, neat, you implemented it... but it doesn't get you anything except press.

mort96 4y ago
This is my feeling about... well, basically every "end-to-end encrypted" product. With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). WhatsApp also claims to be "end-to-end encrypted", but there the app isn't even open source so both ends are just 100% Facebook-controlled without even a facade of transparency. Same with Apple's end-to-end encrypted stuff, where everything is encrypted on their servers but for all I know they can just ask my device that's running their closed software to send them information. I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.
- crgwbr 4y ago
  Even if the app is open source with reproducible builds, you have to trust the OS. Are you going to audit every line of the entire operating system? If you do that, are you going to audit every transistor in the SoC to ensure the hardware isn’t compromised in some way? No one person can do that. Even if a team of people could do it, do you trust the other people? At some point, you have to trust _something_. If you don’t, you simply can’t use computers.
  - yazzku 4y ago
    This does not take away from the parent's point. You need to trust something, yes; we just don't trust Google in particular in that whole chain of trust.
    - scarface74 4y ago

Not_Admin 4y ago

Emails are inherently flawed for security/privacy. If you're sending something you think nobody should see it don't do it with emails.

imhoguy 4y ago
You can say the same about any Internet-connected device communication.
- Not_Admin 4y ago
  Yes you can, not everything we use needs to have military-grade encryption. Things like email should be kept simple. This is the problem we have with software today, everything is just glued together to produce a pile full of complex shit. "Oh.. lets add end-to-end encryption for gmail so people can be at rest when receiving their spam promotion emails".

wankle 4y ago

I just want them to let me set the same theme we had up until recently. I don't want blueish or soft gray I want what it was the past several years. If they can't do that then give me the legacy look back.

upofadown 4y ago

>Client-side encryption (as Google calls E2EE) was already available for users of Google Drive, Google Docs, Sheets, Slides, Google Meet, and Google Calendar (beta). Those things are client-side encryption. End to end implies more than the one end. Which is a good thing. Who would want to have to compare a key fingerprint just so they could securely store files in the cloud? With client side encryption the identity management comes for free...

cj 4y ago

How is this different from the long existing support for S/MIME which has been available for years in gmail (and available for admin setup via Google Workspace)? Is the main news that S/MIME encryption can now happen in the browser instead of Google’s backend?

a-dub 4y ago

the last time i heard about s/mime was the last time they were talking about section 230. i'm starting to wonder if this is actually just a coincidence...

theptip 4y ago

Folks complaining about how this doesn’t solve the “I don’t trust Google” threat model are missing the point - this is a compliance feature so you can work with PII and still comply with regulations like PCI that require you to encrypt everything in transit and at rest. Previously you’d need an expensive third party product like Virtru, so it’s great news for users that this is just a bundled feature now. “Security theater” is probably fair, as is much of the compliance regime. However this probably does make it harder for a back-office admin to accidentally/absentmindedly save files with PII to their machine in breach of policy, as the UI makes it clear the files/content are Top Secret.

Existenceblinks 4y ago
I think so .. it's something I can point a finger to for those who need and trust whatever this is. "compliance regime" explains it all.
pmontra 4y ago
But if it is security theater, how is that compliant with regulations? Hopefully regulators could see or could be pointed to see through the curtain. I guess that plenty of people will be monitoring the packets transmitted over their network. The client side encryption/decryption process is described at https://developers.google.com/workspace/cse/guides/overview https://developers.google.com/workspace/cse/guides/overview If I got it right, Google generates a key and sends it to the external service that stores the keys of the user. That service uses a Google API with probably Google's and the user keys [1] to encrypt the message (and this is quite disturbing, imagine if every company would require key management services to use its own API - Office365, Apple, second tier mail providers, etc.) and finally Google stores the encrypted message. Similar procedure to decrypt. At a first glance Google is not able to see the message, except that they provide the browser to most people and the OS too (Chromebooks and especially Android.) However we're back to monitoring the network packets for suspicious traffic to Google. What I'm more concerned about is regulatory capture through compliance. If E2E messages become the new normal either clients like Thunderbird (desktop) or K9 (mobile) implement an interoperable E2E system or more sooner than later it will be impossible to use them to mail customers and maybe friends too. And uncountable IMAP / POP3 / SMTP libraries for a lot of different languages: they eventually have to display the message and encrypt it before sending it. Of course I'm all in for encrypted email but let's hope everybody can jump on it no matter the mail client they use. I'd hate that the only choices left will be GMail, Apple and Office365 (if they'll be able to talk to each other.) [1] https://developers.google.com/workspace/cse/guides/encrypt-and-decrypt-data https://developers.google.com/workspace/cse/guides/encrypt-a...

kitd 4y ago

Caveat: "What's encrypted in Gmail: Email body and attachments, including inline images Not encrypted in Gmail: The header of the email, including subject, timestamps, and recipients lists"

anonymoose33281 4y ago
Oh, that’s… that’s a little concerning.
- bpodgursky 4y ago
  I mean, come on, recipient lists you can't encrypt. Google needs to figure out where to send the email. Subjects is a concession to search and filters. Nobody is trying to shove PHI into a subject line... doesn't seem like a big deal imo.
  - yazzku 4y ago
    On the other hand Signal has "sealed sender", so while they know the recipient, they don't know the sender: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ I guess another example of why it's hard to retrofit email for security and privacy.
  - dogmatism 4y ago
    >Nobody is trying to shove PHI into a subject line lol

greggarious 4y ago

Of course, right after I get locked out of the account I had since I was a teenager (and years of encryption advocacy) both gmail and icloud roll out changes that I wanted back in 2009. Too little, too late, we will never regain what was lost.

tyiz 4y ago

So they use encryption accessible for CIA?

max-ibel 4y ago

I guess this means search features will only be for metadata (to, from, subject?) That’s a pretty hard sell for power users…

nicce 4y ago
Not really. Other vendors gives a date range for your search, download it for cache in client and then searches it. It takes more resources but it is possible.
- max-ibel 4y ago
  My searches routinely would require searches over GBs of data …

therealmarv 4y ago

This is the development we want to see. Would be great if this would be the main mission for Google for the next 5 years. To enable E2E for most private data (Mail, Drive, Notes) and stop location tracking.

deleted 4y ago

[deleted]