[HN Gopher] Client-side encryption for Gmail in Google Workspace...
___________________________________________________________________
Client-side encryption for Gmail in Google Workspace is now
generally available
Author : bertman
Score : 150 points
Date : 2023-02-28 14:36 UTC (8 hours ago)
(HTM) web link (workspaceupdates.googleblog.com)
(TXT) w3m dump (workspaceupdates.googleblog.com)
| [deleted]
| JadoJodo wrote:
| > client-side encryption for Gmail is now generally available for
| Google Workspace Enterprise Plus, Education Plus, and Education
| Standard customers.
|
| So nothing for power users?
| DeepYogurt wrote:
| Can't find anything about key rotation. How do they crack that
| nut?
| Cockbrand wrote:
| My understanding is that you create a new key in the external
| key management service, re-encrypt all applicable data in
| Workspace with the new key and then revoke/delete the old key.
| All this is API-based, of course, so it can be automated.
|
| (Testing Cunningham's Law here)
| Kiro wrote:
| Went into this thread thinking "how will HN find an angle where
| this is a bad thing?". Was not disappointed.
| jmclnx wrote:
| Good for gmail.
|
| 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.
| jvolkman wrote:
| You must use your own domain with Google Workspace, which is
| what the post is about.
| jeremyjh wrote:
| What if you want email you send to make it to the inbox of
| gmail, 365 users?
| sucinq wrote:
| I suppose jeremyjh@ meant emailing someone with a Google
| account kind of defeats the purpose of self hosting as your
| message is now at Google's hands. Self hosting probably makes
| more sense if people you're emailing are self hosting too.
| seanw444 wrote:
| Then get a legit-looking domain name and hope you don't get
| algorithmically deranked. It's literally a gamble.
| misterio7 wrote:
| Most hosted mail services have no issues getting to mailbox.
| I've used Gandi, Mailbox, FastMail, and never have any mails
| flagged as spam.
|
| Deliverability is only an issue when self hosting
| (particularly for home IPs)
| josefresco wrote:
| >never have any mails flagged as spam
|
| You don't know this for certain, no one can unless you
| monitor both ends.
| misterio7 wrote:
| I mean, at least for me it hasn't been a problem. I
| currently self host mail on a VPS and everything's awesome.
| YMMV
| pyuser583 wrote:
| The email allow-lists will be a problem.
| coffeeblack wrote:
| Sure, if that's your hobby. I used to do that, but there are
| other things you can do with our time too. So now I use
| ProtonMail with my own domain.
| mr_mitm wrote:
| As a fellow mutt user, I only had to fiddle with the config
| over 10 years ago. After that, you are only reaping the
| benefits of your time investment.
| datpiff wrote:
| > These days, people really should get their own domain and
| host there email there
|
| 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-...
| paxys wrote:
| 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.
| [deleted]
| bgitarts wrote:
| Not available to users with personal Google Accounts.
|
| Why not?
| jcrites wrote:
| 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?)
| jsgpg wrote:
| 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
| ddevault wrote:
| Naturally they have reinvented the proprietary wheel instead of
| implementing PGP, so that their domesticated users are nicely
| corralled in their walled garden.
| a-dub wrote:
| 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 anyone enlighten?
| resfirestar wrote:
| 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.
|
| [1] https://support.google.com/a/answer/10741897
| a-dub wrote:
| ok so it's basically like 0bin for google apps storage.
| that's a step in the right direction... it's confusing
| because they present it in the context of email.
|
| although i suppose that's probably what customers are most
| worried about. corporate scandals tend to frequently be
| rooted in leaked internal communications.
| zugi wrote:
| 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.
| margorczynski wrote:
| 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.
| 0x53 wrote:
| The year is 2023.
| acatton wrote:
| 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.
| tantalor wrote:
| 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.
| sneak wrote:
| No. Signal is not redownloaded from Signal each time you
| launch the app, unlike javascript web apps.
| tantalor wrote:
| You're 100% sure they didn't already ship the code and have
| the ability to flip a flag to enable message interception
| per user?
|
| Or the ability to execute arbitrary external code?
| sneak wrote:
| Signal's feature flags are public as the client is open
| source and anyone can retrieve the feature flags from the
| server.
|
| You can also run your own self-built client (alternative
| implementations are available) and forward the messages
| securely any way you wish.
|
| Such subterfuge would not remain undetected.
|
| Signal is e2ee in ways that iMessage and WhatsApp are
| not.
| kevincox wrote:
| 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.
| pmontra wrote:
| I wonder which tool we can use to decrypt the exported
| messages before importing them into a local (mbox, maildir)
| or remote message store (IMAP.) At worst we can use the JS
| code Google sends us, but extracting it from the gmail JS
| bundle is probably non trivial.
| macspoofing wrote:
| >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.
| Idiot_in_Vain wrote:
| 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.
| 3ul3r wrote:
| WhatsApp build something like that:
| https://engineering.fb.com/2022/03/10/security/code-verify/
| UncleMeat wrote:
| 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.
| Gasp0de wrote:
| 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.
| [deleted]
| kenniskrag wrote:
| It is encrypted by the key service and not by google:
| https://support.google.com/a/answer/10801691
|
| can be self hosted.
| belltaco wrote:
| Title is misleading.
|
| > Not available to users with personal Google Accounts
| Gasp0de wrote:
| Yes, perhaps "for Google Workspace Enterprise Plus, Education
| Plus, and Education Standard customers" could be added to the
| HN title?
| rerdavies wrote:
| Or perhaps change the title to "narrowly available".
| Thaxll wrote:
| This blog is not for personal accounts: "about new features and
| improvements for Google Workspace customers."
|
| RTFM.
| belltaco wrote:
| I was referring to the HN title. The domain that shows up is
| 'googleblog.com' which doesn't indicate it's not for regular
| Gmail.
|
| > RTFM
|
| What manual?
| Gasp0de wrote:
| Does it work with mailing lists?
|
| Edit: Found out that it doesn't:
| https://support.google.com/a/answer/10741897#zippy=%2Cwhich-...
| _theskumar wrote:
| There is no info on how it works! It looks more like a marketing
| stunt!
|
| How the key is generated, where it is stored, and which
| encryption is used.
| sumitgt wrote:
| It's in the references below the blog post
|
| https://support.google.com/a/answer/13069736?hl=en
| kenniskrag wrote:
| see here: https://support.google.com/a/answer/10801691
| cientifico wrote:
| That is not Generally available: 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
| paxys wrote:
| Generally Available in software terms means out of beta, i.e.
| launched.
|
| Whether it is available to everyone for free, requires a
| specific plan etc. is not part of the determination.
| deelowe wrote:
| At Google, generally available means it's no longer in testing.
| It's a development lifecycle term.
| groffee wrote:
| That's weasel word marketing.
|
| They know the majority of their users are going to think
| 'generally available' is exactly what it sounds like, not
| their made up meaning.
|
| https://en.wikipedia.org/wiki/Weasel_word
| dspillett wrote:
| _> That 's weasel word marketing._
|
| Bit of both, maybe.
|
| Internally GA means released to at least some end users
| without caveats like "in beta".
|
| Marketing are just repeating that. Maybe they are being
| deliberately disingenuous, or maybe they are just parroting
| a phrase they don't understand.
| akerl_ wrote:
| If a restaurant near you says their new menu is generally
| available, do you turn up looking for a free meal without a
| reservation?
|
| The Google announcement is pretty direct about the plans
| the feature is included with, and how to enable it.
| DrewADesign wrote:
| While the education plans aren't publicly available,
| apparently there is no minimum for Enterprise Plus
| accounts. Theoretically, an enterprising (unless
| nonplussed) individual could indeed get this feature at I
| think $30/mo.
| Idiot_in_Vain wrote:
| Buy a school sounding domain, copy existing school web
| site -> get an education plan.
| [deleted]
| bogomipz wrote:
| Yes I think if you work at a software company "GA" as a
| status in release management has a well-understood meaning -
| "general availability." However stating something is
| "generally available" in the headline only to followed by the
| lede that states it's actually only GA for a premium tier of
| product users feels a bit disingenuous if not click-baity.
| Crosseye_Jack wrote:
| > At Google, generally available means it's a feature that
| about to be killed off.
|
| ;-)
| Semaphor wrote:
| Not just at Google, MS also uses GA when something is sold,
| no need for it to be free.
| xinu2020 wrote:
| >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.
| we_never_see_it wrote:
| > Also to be available it must first be enabled by a workspace
| admin, then by the end user.
|
| Just out of curiosity, why would you expect anything different?
| londons_explore wrote:
| I'm very surprised it isn't force enabled by the admin, with
| the end user having no say in the matter.
|
| Admins of many orgs don't like letting the user have options
| for things like security.
| resfirestar wrote:
| The feature is meant for especially sensitive documents,
| you wouldn't want it turned on for everything in the
| organization because it limits useful features like search
| and printing. More mature products like Azure Information
| Protection let you require encryption for certain documents
| based on policy, but that doesn't seem to be part of what
| Google is announcing here.
| JoshTriplett wrote:
| > you wouldn't want it turned on for everything in the
| organization because it limits useful features like
| search and printing
|
| Some organizations _would_ want to prioritize encryption
| over search /printing. (Also, there's no reason search
| and printing _couldn 't_ work with encryption.)
| prophesi wrote:
| At the very least, I can confirm that ProtonMail and
| Apple's Mail clients let you search through the message
| contents of encrypted email. I'm sure there's a
| performance hit, and admins wouldn't be able to search
| through the encrypted emails of their Workspace users,
| but that's a much more reasonable tradeoff.
| londons_explore wrote:
| 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).
| JoshTriplett wrote:
| > 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.
| prophesi wrote:
| Yep. Not sure how Apple/Proton implement it, but that's
| exactly what Tutanota does.
| https://tutanota.com/blog/posts/first-search-encrypted-
| data
| killjoywashere wrote:
| It's more of an issue that people have to interact with
| vendors outside their direct ecosystem, who maintain
| different email systems. I can have all the PKI
| infrastructure I want, if my contracting officer has to
| coordinate payment of a $10M or $100M deliverable with a
| foreign company with different laws around encryption, I
| may have no choice but to send some things unencrypted
| until we can mutually agree on certain processes.
| kybernetikos wrote:
| Yeah, It's understandable that they would use this as a
| differentiator, but in reality, we all gain when encryption is
| rolled out more broadly.
| shadowgovt wrote:
| Who is "we" in this context?
| Neil44 wrote:
| Similar to Microsoft 365 - you need a higher end subscription
| there too.
| idiotsecant wrote:
| Not surprising, the main point of gmail is vacuuming up all
| that sweet, sweet email data.
| mattzito wrote:
| 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
| idiotsecant wrote:
| 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?
| Scion9066 wrote:
| Two ways I can see as an outsider: 1. Google
| Drive/One/whatever subscriptions to pay for more storage
| if you want to keep your old emails/files in their cloud.
| 2. Keeping people signed into their Google account for
| email could make them easier to track as they're also
| identified/signed in elsewhere on the web.
| [deleted]
| meghan_rain wrote:
| It makes me happy to know that most people think Google
| abuses their emails, and you have to fight a frustrating
| uphill battle to convince them otherwise. :)
| influx wrote:
| 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.
| patd wrote:
| He specifically said Google Workspace which is the non-
| free version of the Google suite.
| eli wrote:
| FTA: _" We don't use any information from your Gmail
| messages to serve you ads, and that includes the email
| receipts and confirmations shown on the Purchase page"_
|
| Other companies like unroll.me, however, were absolutely
| data mining your receipts and then selling the results.
| fauigerzigerk wrote:
| 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.
| latchkey wrote:
| This is not just tick a checkbox and it is done. Enabling it
| is non-trivial as it requires setting up a whole bunch of
| stuff, like integrating with a third party key service
| provider (or setting up your own).
| fauigerzigerk wrote:
| I didn't mean to say anything about how hard it is to
| implement.
|
| What I'm saying is that the point of implementing this
| feature may not be that it's expected to be tremendously
| useful for a lot of actual users.
|
| Rather I think the point is to not leave the "has client-
| side encryption" box unchecked in any comparison charts or
| scoring systems that may influence purchasing decisions.
| jeffbee wrote:
| Sure, it ticks this exact box that the help article mentions:
|
| > Your organization operates in a highly regulated industry,
| like aerospace and defense, financial services, or
| government.
___________________________________________________________________
(page generated 2023-02-28 23:02 UTC)