Gmail is Making It Easier For Businesses To Send Encrypted Emails To Anyone (theverge.com) 39
Google is rolling out a new encryption model for Gmail that allows enterprise users to send encrypted messages without requiring recipients to use custom software or exchange encryption certificates. The feature, launching in beta today, initially supports encrypted emails within the same organization, with plans to expand to all Gmail inboxes "in the coming weeks" and third-party email providers "later this year."
Unlike Gmail's current S/MIME-based encryption, the new system lets users simply toggle "additional encryption" in the email draft window. Non-Gmail recipients will receive a link to access messages through a guest Google Workspace account, while Gmail users will see automatically decrypted emails in their inbox.
Unlike Gmail's current S/MIME-based encryption, the new system lets users simply toggle "additional encryption" in the email draft window. Non-Gmail recipients will receive a link to access messages through a guest Google Workspace account, while Gmail users will see automatically decrypted emails in their inbox.
PGP (Score:3, Interesting)
Re: (Score:3)
PGP is a pile of fail for several reasons. "What To Use Instead of PGP" by Soatok (2024-11-15) [soatok.blog] recommends using Signal, and if necessary, buying a compatible smartphone and cellular service subscription for each party with whom you communicate.
Re: (Score:3)
Signal is total crap. You need a cell phone to use it. They don't have a web app. There is no good way to keep your full history except locally on your phone (which can be lost). They have a "windows desktop" app but you still need a cell phone to be able to use it!
Using a phone number as an ID was a big mistake from the start. The sooner Signal is killed, the sooner we can adopt a useful alternative.
Re: PGP (Score:2)
Re: (Score:2)
Of course I know how encryption works. It seems you don't, if you believe one has to provide a cell phone number as the identifier as the only way to encrypt communication.
Re: (Score:2)
I seem to remember that the free tier of Gmail also requires either activation of a newly purchased Android-powered device or a phone number to verify a new account. What would have been a better way to deter spammers from signing up and sending scam hooks to Signal users?
Re: (Score:2)
I think you can get a Gmail account by providing another email address. But anyways nobody forces you to get a Gmail account to send emails to Gmail users. You can get any other email provider or even host your own. You can't do that with Signal.
I don't think providing a phone number effectively reduces spam anyways. Signal would be just fine if you had the option to join by providing an email address instead of a cell phone number.
Deliverability will suffer (Score:2)
You can get any other email provider or even host your own.
Until you try to send mail to a user of the big three (Gmail, Outlook, Yahoo). If you're hosting your own mail, your domain won't be on the big mail providers' allowlist, nor will your MTA's IP address. Your messages will go directly to readers' spam folders if you're lucky; otherwise, they'll be dropped without notification.
Re: (Score:2)
I've hosted my own email for going on 10 years now, and have no deliverability issues to the Big Three. I set up SPF, DKIM and DMARC correctly (and for bonus points DNSSEC) and I haven't had any problems.
Apple, though, often misclassifies my emails as spam. Luckily, I don't have all that many correspondents with an Apple-hosted email address.
Re: (Score:2)
Email is insecure and presents one of the biggest cybersecuri
Re: (Score:2)
Yep, PGP is the only standard, currently, for trusted encrypted email.
That's not true. S/MIME has also been around forever and is widely used in government email systems and by the DoD. I'd wager if an enterprise is doing encrypted email it's probably via an internal X.509 authority and S/MIME via Exchange rather than PGP.
Re: (Score:2)
Re:PGP [and delusions of my grandeur?] (Score:2)
Or are they delusions of security? I'm not skeptical about the mathematical part of the security (though the details are over my head), but it's the implementations and the environments that will determine how much real security there is when you use it. How can you be certain the implementation you are using doesn't have a back door? And how can you be certain that the environment in which you are using PGP hasn't been breached so your keystrokes are captured before your email is encrypted and the decrypte
Re: (Score:3)
What I mostly want from Gmail is an escape path to a better email system not controlled by a corporate cancer. Or at least a less malevolent corporate cancer than the google has become.
You might want to give Protonmail a try. Their web interface is kinda sucky, but they have bridge software which allows the use of clients such as Thunderbird. They also have a calendar, VPN, and Proton Drive.
They're privacy-centric, and headquartered in Switzerland. They have - at least for now - tech support which replies to users' emails and actually does stuff to resolve issues. Their free version is pretty good, but I was impressed enough that I actually paid for a mid-level plan with more storage and
Re: (Score:2)
Mod parent up though it's too late to matter.
Re: (Score:2)
Yes, but Thunderbird now uses its own thing, unlike before when you could use standard gnupg with enigmail. I wish they purchased/took over the old enigmail plugin.
So for me it is mutt if I need to send encrypted emails.
Uh huh... (Score:5, Informative)
Non-Gmail recipients will receive a link to access messages through a guest Google Workspace account
Sounds like an opportunity to have your users market your services for you in the so-called name of "security".
Re:Uh huh... (Score:5, Insightful)
Yeah this seems actually horrific for privacy, not good. Google encouraging people to store private messages on their own servers, which they have the keys for, and training people to click on links to see "encrypted emails", which is a common phishing vector.
What we need are protocols that make it easy to exchange validated keys, and have encryption as much as possible be client side. Webmail is already problematic, and Google seems to have taken everything one step further and actively encouraged insecurity.
I wonder why they would do that right now [senate.gov] when people are worried about governments abusing centralized communications resources more than ever?
Who controls the keys? (Score:5, Insightful)
Sure it's "encrypted" but who is controlling the keys and who can and can't read the message? Google is, obviously.
Re: (Score:2)
Re: (Score:2)
Sure it's "encrypted" but who is controlling the keys and who can and can't read the message? Google is, obviously.
I have no idea how this is implemented, but to a first approximation that doesn't need to be the case. Google already has infrastructure in place to enable securely syncing secrets between end-user browsers without making those secrets available to Google, so Gmail could enable encrypted email that Google itself cannot decrypt or read.
That said, since all of the code to do the encryption and decryption will be served to the clients by Gmail, Google will always have the power to subvert the security if it
Re: Who controls the keys? (Score:2)
More Google f*ckery (Score:5, Insightful)
Yet another attempt to make standard protocols proprietary.
Google needs to be broken apart.
Re: (Score:3)
Let's see if it works seamlessly with Proton Mail.
Re: (Score:2)
Yet another attempt to make standard protocols proprietary.
That argument would be more compelling if they were displacing some existing widely-used email encryption standard, or if the idea of standardized email encryption were new and easy to build and deploy. The fact is that the last few decades have thoroughly demonstrated that open, easy to use and secure email is a "pick any two" case: You can have open and secure but hard to use (e.g. PGP, S/MIME), open and easy to use but not secure (normal email) or easy to use and secure but not open (what Gmail is laun
Re: (Score:2)
If Google would license its technology at no cost, then I'd have less of a problem with it. But it's simply using it as a wedge to move more people onto Gmail and make other SMTP implementations less attractive.
As to why Google should be broken apart, the answer is because it's a monopoly that is abusing its monopoly power [cnn.com].
Re: (Score:2)
If Google would license its technology at no cost, then I'd have less of a problem with it.
I doubt there's any technology to license here. I'm sure it's just leveraging ownership of a widely-used platform to provide a feature on that platform. Any other email platform with both servers and clients could provide the same, within its garden. Crossing those garden boundaries is where this problem gets impossible to solve.
As to why Google should be broken apart, the answer is because...
So, nothing to do with email encryption, i.e. just confirmation bias.
Re: (Score:2)
Any other email platform with both servers and clients could provide the same, within its garden.
I notice that Microsoft's "Purview" also provides encrypted email for Outlook, but also only to entities with a subscription. So... this is really just Gmail catching up with Outlook.
Re: (Score:2)
Does MSFT's purview let you send an encrypted email to a non-MSFT Outlook user?
If it's all kept entirely within the walled garden, it's less of a problem.
Re: (Score:2)
It's not confirmation bias to say that Google is a monopoly... that's a fact. It's also not confirmation bias to claim that it abuses its monopoly power.
Google has a history of taking open standards and gradually making them either proprietary or changing them without proper community consensus, all the while cheerfully violating your privacy. Its Chrome browser is an obvious example [contrachrome.com] of this. And because of its monopoly power, it can force these changes onto almost everyone.
Phishers rub their hands with glee... (Score:5, Insightful)
"Oh, Google is training people to click links to view encrypted messages? Yum!"
What could possibly go wrong?
Security theatre (Score:3)
Encrypting email is a fool's errand (Score:3)
I didn't read the featured article because The Verge happens not to be included in my current news subscription package. I'm relying on "Google makes end-to-end encrypted Gmail easy for all – even Outlook users" by Connor Jones [msn.com] and "Google Rolling Out End-to-End Encryption for Gmail Workspace Accounts" by Michael Kan [msn.com].
That said, I've read takes elsewhere that encrypting email in the first place is a fool's errand for several reasons. (Source: "The PGP Problem" (July 16, 2019) [latacora.com])
- First, the subject, recipient list, and other headers are still plaintext. Kan's article states that this hasn't changed in Google's new service.
- Second, mail user agents make it too easy to quote text from an encrypted mail to an unencrypted reply sent as a CC. It's unclear what "the restricted version of Gmail" that Kan describes will allow, though Jones's article compares it to "Confidential Mode, which prohibits recipients from forwarding, copying, printing, or downloading emails" in some unspecified way. (In particular, I don't know to what extent "Confidential Mode" interferes with accessibility to blind users who use a screen reader.)
- Third, an exploit of CBC and CFB modes called "Efail" can be used to reveal plaintext in both PGP and S/MIME. What mode does this use?
Re: (Score:1)
To save myself time, I wrote an article on "The PGP Problem":
The PGP Problem: A Critique [59.ca]
You make good points about Efail and MDC (Score:2)
You make good points in the linked critique. Regarding Efail and reference implementations:
If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument.
[...]
CFB (Cipher Feed Back) is actually sort of awesome.
CFB mentioned; I'm eager to see how you address Efail. (I'm also curious about what makes CFB better than counter mode, but that might be a separate discussion.)
There is no such “reference PGP implementation”.
In 2002, when Trevor Perrin found the IETF OpenPGP spec to be wrong about the strength of MDC, the spec was changed to reflect what implementations actually do. At the time, this made GnuPG the "reference implementation" of MDC in fact, even if not formally. R
This will destroy heuristic spam filters (Score:2)
...for everyone but Google.
gmail late to the party (Score:2)
Welcome to Office 365.
So, not end-to-end (Score:2)
You know what cryptography and security experts call such a system? "Worthless".