Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Client-side encryption for Gmail in Google Workspace is now generally available

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#91

Post by jsgpg »

jcrites wrote: post #89
bgitarts wrote: post #88

Not available to users with personal Google Accounts. Why not?

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…

OoenPGP.js is open source and developed by ProtonMail https://openpgpjs.org/ https://github.com/openpgpjs/openpgpjs

A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail.

WKD (and HKP) depends upon HTTPS without cert pinning, FWIU: https://wiki.gnupg.org/WKD

  How does an email client use WKD?
  1. A user selects a recipient for an email.
  2. The email client uses the domain part of the email address to construct which server to ask.
  3. HTTPS is used to get the current public key.
  The email client is ready to encrypt and send now.

  An example: 
  https://intevation.de/.well-known/openpgpkey/hu/it5sewh54rxz33fwmr8u6dy4bbz8itz4 is the direct method URL for "bernhard.reiter@intevation.de

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#92

Post by mattzito »

idiotsecant wrote: post #87
mattzito wrote: post #57

Earlier quoted context omitted.

I will just repeat over and over again, that is absolutely not true. Your email data is not used for ad targeting, search personalization, or anything else. Nothing inside of Google Workspace - drive, docs, sheets, slides, chat, gmail, keep, etc. is used for any purpose outside of workspace. Source: worked on workspace for years

Google isn't monetizing my email contents? I have to admit I'm skeptical but if that's the case I can't imagine that staying true forever. What incentive does google have to run Gmail then? How does Gmail make money?

Gmail runs ads in the consumer version, but the ads are powered by the search and activity elsewhere.

But also workspace more broadly wants people to use Gmail in their personal lives so they want to use it at work, which then is a paid business.

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#93

Post by mattzito »

patd wrote: post #77
influx wrote: post #59

Earlier quoted context omitted.

What about Google Purchases reading my Amazon receipts? https://www.cnbc.com/2019/05/17/google-gmail-tracks-purchase... Now my Amazon emails are neutered. Thanks.

He specifically said Google Workspace which is the non-free version of the Google suite.

This applies to the paid and free versions equally

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#94

Post by jcrites »

jsgpg wrote: post #91
jcrites wrote: post #89

Earlier quoted context omitted.

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…

OoenPGP.js is open source and developed by ProtonMail https://openpgpjs.org/ https://github.com/openpgpjs/openpgpjs A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail. WKD (and HKP) depends upon HTTPS without cert pinning, FWIU: https://wiki.gnupg.org/WKD How does an email client use WKD? 1. A user selects a recipi…

How/where exactly does it store the user's private keys?

The initial reaction that I have to client-side encryption with a web browser is: how does the client fetch/obtain the encryption key? (For signing outbound messages, or decrypting/verifying inbound.) Local storage wouldn't be appropriate as the sole storage for something like an asymmetric keypair, and it wouldn't provide the behavior that users expect: being able to log in and use a service from any web browser.

No one interacts with a web browser in such a way that it would be appropriate for the browser's local state to be the sole storage of something important like a private key. So this necessitates a service that the client interacts with during login to fetch its private key.

If you can log in with a browser, then that implies that you're fetching the key from somewhere. In the context of hosted Gmail, then that means that Gmail will be storing and providing your key. In which case it's nominally client-side encryption -- and the system that stores and provides your key might be totally separate from the email systems (and tightly controlled) -- but it's still not what I'd think of as client-side encryption generally. It's not really client-side encryption if the service that you're using to store data is the same service (from your perspective) as the one that stores/provides your key (those responsibilities might be separated from an implementation perspective, but they aren't from a user's perspective).

The service can employ various techniques like encrypting its copy of my private key using a symmetric key derived from my passphrase (and then discarded) -- and this decryption could perhaps be done client-side in the browser -- but ultimately the service still has the ability to obtain my key (at time of next login, if not any time).

If the service that provides a client-side encryption key could be divorced from a particular use-case -- e.g., if I could use my own pluggable key-providing service with Gmail, which my browser uses to fetch my key on login -- then the model would make a bit more sense. (You'd still have to trust a service like Gmail not to steal your key, but at least you don't have to trust it to store the key as well.)

Would it be possible to implement a standardized pluggable key server model? It seems plausible. Imagine that there was a standard HTTP protocol for this purpose, kind of like how WebAuthN is standardized. I log into Gmail, link it to my key server https://keys.jcrites.example.com>, verify the connection, and then when logging into Gmail, then the web page is allowed to make HTTPS calls to https://keys.jcrites.example.com> to either fetch my asymmetric key, or alternatively make calls to decrypt or encrypt specific content.

In the former case, it implements client-side encryption using a key server I control, while trusting Gmail not to misuse the key; in the latter case, it implements encryption using a keyserver that I control, and makes remote calls for each encryption operation. In that case Gmail would never have my key, although while browsing Gmail.com it could probably make arbitrary requests to the key server to perform operations using the key -- but you could log what operations are performed.

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#95

Post by londons_explore »

JoshTriplett wrote: post #81
londons_explore wrote: post #71

Earlier quoted context omitted.

I'd be interested to know the implementation... Most search-over-encrypted-documents implementations either don't scale well (eg. require the client to do all the indexing and upload the encrypted index), or have reduced privacy (allowing the server to infer which words are in which document).

> require the client to do all the indexing and upload the encrypted index Or just require the client to do the indexing and the searching, and not upload the index anywhere.

And when you log in from a new device...? Do you now need to wait days while 1000,000 emails from the last decade are all downloaded and indexed?

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#96

Post by prophesi »

londons_explore wrote: post #95
JoshTriplett wrote: post #81

Earlier quoted context omitted.

> require the client to do all the indexing and upload the encrypted index Or just require the client to do the indexing and the searching, and not upload the index anywhere.

And when you log in from a new device...? Do you now need to wait days while 1000,000 emails from the last decade are all downloaded and indexed?

That's an issue with or without client-side encryption. Even with IMAP, you have to download the message before its contents can be searched. While subject/sender/recipient can be searched instantly with IMAP, regardless of encryption.

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#97

Post by westurner »

jcrites wrote: post #94
jsgpg wrote: post #91

Earlier quoted context omitted.

OoenPGP.js is open source and developed by ProtonMail https://openpgpjs.org/ https://github.com/openpgpjs/openpgpjs A number of Chrome (and I think also Firefox) extensions include their own local copy of OpenPGP.js for use with various webmail services, including GMail. WKD (and HKP) depends upon HTTPS without cert pinning, FWIU: https://wiki.gnupg.org/WKD How does an email client use WKD? 1. A user selects a recipi…

How/where exactly does it store the user's private keys? The initial reaction that I have to client-side encryption with a web browser is: how does the client fetch/obtain the encryption key? (For signing outbound messages, or decrypting/verifying inbound.) Local storage wouldn't be appropriate as the sole storage for something like an asymmetric keypair, and it wouldn't provide the behavior that users expect: being…

Looks like you are correct: WebUSB and WebBluetooth and WebAuth don't already cover HSM use cases?

/? secure enclave browser

But WebCrypto: "PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange #263" https://github.com/w3c/webcrypto/issues/263

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#98

Post by pseudalopex »

prophesi wrote: post #96
londons_explore wrote: post #95

Earlier quoted context omitted.

And when you log in from a new device...? Do you now need to wait days while 1000,000 emails from the last decade are all downloaded and indexed?

That's an issue with or without client-side encryption. Even with IMAP, you have to download the message before its contents can be searched. While subject/sender/recipient can be searched instantly with IMAP, regardless of encryption.

This is a limitation of your client or server. Not IMAP.

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#99

Post by pseudalopex »

londons_explore wrote: post #95
JoshTriplett wrote: post #81

Earlier quoted context omitted.

> require the client to do all the indexing and upload the encrypted index Or just require the client to do the indexing and the searching, and not upload the index anywhere.

And when you log in from a new device...? Do you now need to wait days while 1000,000 emails from the last decade are all downloaded and indexed?

Maybe if you have that many emails and 3G only and can't load a backup for some reason.

Re: Client-side encryption for Gmail in Google Workspace is now generally available

#100

Post by prophesi »

pseudalopex wrote: post #98
prophesi wrote: post #96

Earlier quoted context omitted.

That's an issue with or without client-side encryption. Even with IMAP, you have to download the message before its contents can be searched. While subject/sender/recipient can be searched instantly with IMAP, regardless of encryption.

This is a limitation of your client or server. Not IMAP.

No, it's a limitation by IMAP that is rectified by the server/client.
Post reply on HN