More Encryption, More Notifications, More Email Security
security.googleblog.com
security.googleblog.com
I certainly appreciate the effort is better than nothing, however, how often are those notices served to US/European citizens? It's one thing to stand up to government overreach in foreign countries, but how about the country where you (and a large percentage of your users) reside? They specify attackers, but I'm assuming this notice to the end user does not apply to the US/EU governments requesting your data and them complying?
Another gripe I have is that TLS has probably been broken by the NSA^1. It's better than nothing to alert us about the other party not using it, but really provides limited protection. PGP/GPG is really the only assurance you have and the plugins for different desktop apps are nearly always buggy. I end up just manually encrypting/decrypting with GPG because a buggy encryption integration is not a comforting thought. If they really cared about keeping your privacy safe, they'd have an end-to-end encryption tool/integration.
[1]: http://blog.cryptographyengineering.com/2013/12/how-does-nsa...
Hm.
Maybe some day email will fade away giving its place to an IM, though I'm not sure it will always be spam-filter free.
Based on a quick search, you are right that the phrase "permission based email" has been SEO'ed into uselessness by email marketing services. What should it be called? Screening? But the spam filtering services have almost SEO'ed that into uselessness.
Having just read a former google abuse team member's take on end to end encryption and anti-spam[1], this topic now looks a lot more complex. Regarding IM's, he mentions how spam-free WhatsApp is and argues that spam is a lot easier to fight when you have central control because you can change anything at any time at any point (client or server).
[1] Mike Hearn, https://moderncrypto.org/mail-archive/messaging/2014/000780....
Leave it up to the users to decide whether they want to use end-to-end encryption despite a potential spam problem. It's also not like people couldn't use multiple email addresses.
How many times have we heard companies "China has a 1 billion people - imagine if we only got 1% of that market with our product!". But we're talking about a feature of a product here, not an entire product that only gets 1% of a market's userbase.
0.1% here, 1% there, another 10% over there - all of these features add-up to create a great product that everyone loves because of the aggregate of features but also because of that "one" feature they love individually.
Another thing to remember is that the enthusiasts are the market-builders. You can't just win with a product that surveys well with 80% of the market. I don't think most of the phone or smartphone customers in 2007 wanted a touchscreen phone. Probably (well, literally, actually) only 1% of the market wanted it then.
Also, we don't know how important this feature could be to gain Google more trust. Telegram for instance has gotten promoted as a private messenger that uses end-to-end encryption - and yet its end-to-end encryption isn't even enabled by default (so same scenario that I was talking about), while its "normal" encryption is probably worse and less secure than what Google uses for Hangouts.
It might be a harder sell to implement E2E crypto, although perhaps the same argument might apply some day. The notifications are probably just low-hanging fruit.
Not to mention, from what I heard out of the mouths of ordinary folks, that protection is literally one of the leading reasons GMail took over. It was nearly spam-proof, and people loved it. (That and lots of free storage)
But honestly, as you have highlighted, these announcements should be insulting to users' intelligence.
"Dear Users: Please allow us to store copies of all your sensitive data, including every email ever sent or received, in perpetuity. In return, to the extent the law permits us to do so, we'll let you know (_ex post facto_) when some other third party is having a look at it."
The solution to the problem if indeed there is a problem here is not going to come from Google.
The problem _is_ Google.
The only parties who need a copy of an email are the sender and the recipient. If you really care about privacy, security, whatever, then "store and forward" and "POP" via some third party (Google, etc.) is not the proper way to implement email.
Hypothesis: Google does not charge for Gmail because, quite simply, no one would pay.
Emphasis on "need". Most recipients also like to have a third-party anti-spam service also have a copy of their email.
Assuming the encryption costs are low enough, spammers and virus senders would like nothing better than to cripple anti-spam learning tools by having each recipient recieve a cryptographically unique opaque blob. This would force users to develop their own training corpus and react to new spam and virus outbreaks individually.
You may argue that you could still use anti-spam locally, but it wouldn't be as good. While I wouldn't mind sending decrypted spam out to a server and getting updates to my local anti-spam program, no one would want to send legitimate mail, so the service would have no "ham" to train against.
I suppose encryption could help in the fight against spam by requiring CPU time to encrypt the email. 10 seconds per email would be hard to notice for a real human responding to messages, but might make spam unprofitable.
I'm not sure I catch your drift. Users in any country may get targeted by governments of any country. You might say that governments should be allow to do whatever they like to their own citizens, but in this day and age, that's hardly an easy distinction to make.
They're alerting you of "attacks" to obtain your data, but not necessarily government requests for your data.
In that vein, end-to-end would protect those users even if you can not alert them. Your hands are tied with something like PGP because you couldn't access it even if you wanted to. Someone mentioned your end-to-end extension. Will you be releasing end-to-end to the Web Store soon? Or some other killer end-to-end solution?
That doesn't mean that GPG is bad or that it isn't a strong tool, it means that for mass adoption then we need to make the tools easier to use.
Without help.
If he can do it, anyone can.
Someone here suggested that "PGP isn't too hard - you just need to spend 30 minutes studying cryptography before you use it" which pretty much makes my case for me!
In any case, it would be much simpler to direct someone to Proton mail, which uses OpenPGP.
Just because you can deal with complexity doesn't mean you should accept it, or seek it for that matter.
How do you determine the keys associated with the people you wish to communicate with? (The web of trust and going to key-signing parties are about a thousand miles from 'everything just works'.)
I agree with you that if you want to actually improve the security of the people who are right now not using any encryption, make encryption easy to use. Even if this means that it might not fit the threat-model of those targeted by state-actors.
IMHO, PGP could actually be used for this (even if it might not be the perfect fit) by using Trust On First Use, better interfaces and more integration into mail clients. The problem is that it is right now a tool used and made by those who want really strong security. This includes e.g. encouraging you to set a passphrase, which makes it more secure, but also more of a hassle for most people.
[1] This is obviously only true if you don't fear it being compromised / your security requirements are low. But then, if you need strong security, use full disk encryption and Qubes or something similar.
I use Yubikey Smartcard both on my workstation and on my phone. The setup works, but its both exepnsive, takes a long time to set up and its fairly difficult to do. Now that I have the setup, I can only use it with a few friends.
Keybase is working on a more scalable solution. Every device has different keys and messages are encrypted for each device. This allows them to revoke individual devices. While deploying this to most non technical people, is still quite a challenge, at least its an attempt at solving the multi device problem. I can at least imagen how with their approch we could get wide use, while with traditional gpg I cant really see it.
I'd rather explain this with necessity to learn concepts of public key cryptography, which takes time and efforts to understand. Most of people don't know about that and are not interested to know that. Interface is secondary issue: it won't take a lot of time to setup your keys given you know crypto.
My girlfriend have successfully passed the EFF's guide to PGP in half an hour (with a bit of my guidance), coping well with some inconsistences of the guide. https://ssd.eff.org/en/module/how-use-pgp-windows
I think Adam Langley has already started such a project, but it's only been a "spare-time" project:
I'm getting a little annoyed by the folks demanding I do something I don't think is necessary. I'd rather have all the features Google gives me by not enabling end to end encryption, why must everyone have the highest possible level of security on every single thing they do?
You may think it's stupid, but I genuinely don't care if the government reads my emails (with a warrant), or if Google indexes them. I still fundamentally trust the government, and I believe that any incidental processing of my emails that the NSA might be doing is searching for what we currently consider to be terrorist activity. If the definition of "terrorist" shifts beyond reasonability, then my habits will shift as well, but we're not anywhere near that.
It's a lot like having my Netflix account require a 32 character password -- just not necessary. For my bank? Sure. But Netflix? I just don't care.
People who know more about this: does Signal have verifiable builds too?
My description of subversion-resistant build:
https://news.ycombinator.com/item?id=10182282
Subversion-resistance in systems and builds in general:
Or because... oh, wait. You alluded to it yourself:
> There are some doing reproducible builds with untrustworthy compilers.
I expect that the bar required to verify (or design and build from scratch) a high-performance optimizing compiler [0] is substantially higher than the bar to rework your build system to give the same outputs for the same source code.
[0] And -in the case of systems with VMs- a high-performance VM.
After FOSS compiler types build it, users can get the reproducible source and build the tool. Then that builds the other apps from source. See how easy that is?
Note: Wirth et al built a safe language, simple ASM, CPU, OS, apps, and all with a few people in a few years. The ASM-3GL-Compiler build is WAY easier than you think. It bootstraps faster one after.
No. I mean exactly what I said:
> I expect that the bar required to verify (or design and build from scratch) a high-performance optimizing compiler (and -in the case of systems with VMs- a high-performance VM) is substantially higher than the bar to rework your build system to give the same outputs for the same source code. [0]
Remember that this addressed your assertion that:
> None of [the projects doing reproducible builds] have verifiable builds. ... Verifiable builds are a larger problem they're ignoring because it's not a fad yet. [1][2]
If you can't see how my statement addresses the quoted claim, then more's the pity.
[0] https://news.ycombinator.com/item?id=11363783
[1] https://news.ycombinator.com/item?id=11362470
[2] Italics added for emphasis.
That's a large problem. The compiler part is smaller with lots of work in CompSci, FOSS, and private sector (eg books). There's tools with source available on net for imperative and functional languages that are safer, too. Ignored almost entirely by safety or security oriented projects in compilers and general FOSS in favor of harder-to-analyze, less secure stuff. However, they'll happily bring up fad-driven stuff like Thompson attack or reproducible builds as The Solution.
Here's the actual solution. You start with a simple, non-optimizing toolchain designed and documented for easy understanding and implementation. It has extensive test suite. User worried about subversion implements that in tooling of their choice on own machine. Wirth simplified it with P-code interpreter that was easy to inplement with compiler and apps targeting it. Once first compiler is done, it compiles the HLL source of its own code. Now, you can use it to compile a high-performance compiler's source or add optimizations to it. Most of this work is done so it's a natter of FOSS compiler types or project teams just integrating and using it.
They won't, though, because proven practices and components for secure, software engineering are rarely use. They do popular stuff instead which screws them up in other ways. At least the malicious or buggy source from the potentially subverted server run throigh a black box with similar issues has identical binary coming out. Take that NSA! ;)
To make sure that you do: It's obvious that you recognise the difficulty of creating a trustworthy compiler. Given that you have that information, it's rather disappointing that you chose to assert that this problem was being "ignor[ed] because it's not a fad yet".
> The problem is that this problem isnt solved in a vacuum...
That's one problem. Another problem is that the skills, competencies, and interests of one programmer differ (sometimes wildly) from that of another programmer.
Asserting that a randomly selected programmer isn't tackling the Verified Compiler problem just because it's not currently in vogue will likely be wrong as often as asserting that a randomly selected native Korean speaker doesn't also speak Greek because speaking Greek isn't currently in vogue.
This is one case among many. I counter it here all the time. There's literally dozens of works, including certification requirements, on securing this aspect of things. Yet, people have ignored all that from academia to industry every time we bring it up. Then, there's two things that pop up in every online discussion: Thompson attack or (recently) reproducible builds. Literally the smallest aspects of the problem with trusted distribution covered under old criteria. Why does that matter now but not before? It's a social phenomenon.
In 70's-80's, people designed, assured, and pentested guards with great results. Firewalls were a watered down version that came later with features but not assurance. Push guards on firewall proponents, even developers, then you'll just get ignored. They will work on whatever is making rounds on favorite IT or INFOSEC sites, though.
Compiler and OS people. They usually write their stuff in a monolithic style in C despite decades of bad results that way. Showing even one person (Edison), three (Lilith/Oberon), or handful (MINIX 3) can do entire system safer with less people and time will not change this. Showing them ML or something with C compilation for portability will not change this. They systematically reject this while doing whatever is their tradition or becomes in the vogue.
People making secure messaging apps have solid code and endpoint OS's to draw on. They rarely use them. They often use whatever most projects use or roll their own because it's fun. This is true even when shown risks, zero days, or benefits of alternatives.
All of these are social phenomenon that have nothing to do with technical difficulty. If anything, they're doing things that are harder to avoid the more robust option. This is systemic in our industry in compilers, OS's, and certain types of libraries. It's not about what a random Korean or Greek speaking programmer tackling a random project won't do. It's about the fact that almost all compiler-related work is ignoring the ways it got done robustly and more easily before. Same with SCM. There's exceptions, especially in functional, but the rule supports my point.
Most likely explanation for them chasing the same senseless stuff in mass even when shown evidence to the contrary... stuff that's easier... is that they chase fads for social reasons.
(before anyone takes me seriously: this was a joke. Messaging must be ephemeral, anything else won't scale.)
If you're not a libertarian, it matters that law enforcement has to get a search warrant, rather than breaking the encryption and snooping on whatever they want.
https://www.schneier.com/cryptography/paperfiles/paper-keys-...
Note that all the techniques they have allow stealthy, persistent access with ability to forge evidence with write access. I don't have to be libertarian to be concerned about that given all the corruption cases of local and federal law enforcement. Just know human nature & scope of technical problem.
In the case of a cloud service provider, putting the company (and a judge) in the loop is a procedural speedbump. The government doesn't have write access unless the company allows it. Of course if they collaborate all bets are off, but that's the best that separation of powers can give you.
Far as write or collaborate, you should look up the Lavabit case records or summaries. The FBI and court demanded that he hand over the master key compromising all users then lie to them about it. FBI also wanted to put a black box in a privileged position that could probably be used to compromise the service. They've used 0-days before in ops.
So, a backdoor with enough privilege to read everything in the system, install updates with their spyware, and be unnoticeable to OS must be both (a) enormous technical risk and (b) have write access that could enable corrupt officials to frame dissidents. I've worked on potential counters to A but B is unacceptable given fed's and spook's track records.
In the happier case (with better lawyers), a legal procedure gets worked out where the company checks that the search warrants are valid, law enforcement gets the info they want, the company keeps their private key, the government doesn't get to install any hardware, and companies publish "transparency reports" showing that mass surveillance isn't happening.
So, you are told that it happens as you describe. We cant be assured of tgat given leaks.
It's suggesting strongly some kind of end-to-end encryption, like PGP, when there is still nothing. Google still has full access to the plain text versions of these emails as well as the receiving email providers.
It's creating a fake assumption of security that can be more damaging than anything.
End to end encryption is the only thing that will really matter in email security. And even with end to end encryption email is a flawed medium, since it leaks meta data in the process of message delivery. That is kind of a barrier to secure messaging.
I'm not enough of an SMTP/security guru to know what you're referencing. I'm curious, can you share?
SMTP and really email as we know it is inherently insecure. Without end to end encryption and relying on hosted mailboxes, we're inviting "service providers", government and hackers alike to read and tamper with our email.
Gmail is a big privacy problem. Even if you don't use it yourself, nowadays a large percentage of your emails will end up there. And why? It's all about lazyness and low friction.
Computer literate persons (that's you, right?) should really consider to get off their butts and host their own email. It's not hard, it's not expensive and it's not a lot of work to maintain either. It can even be fun and informative. By sticking to gmail, you're no longer credible when complaining about the erosion of privacy on the internet.
Who wants to bet this guy is unwittingly hosting an open relay and sending spam?
The defaults are safe, the various popular guides you'll find on how to setup something like Postfix with Dovecot will result in a safe setup and if you use something like sovereign ( https://github.com/sovereign/sovereign ), you'll end up with a very well configured mail server with very little work.
I'd love to do this -- I ran an email server for a while and it really was informative. But my sent mail got sent straight to the spam bin every time. Ironically enough, Gmail's spam filters are usually so reliable that people don't really check for false positives with any reliable frequency, so I bailed.
Next, add all the usual anti-spam things such as SPF records, DKIM, SSL certificate and a reverse DNS record.
At which point you're back to trusting a third-party to not mess with your data.
I'm surprised that it's not more than that. I can imagine executives everywhere asking their IT people "Why do all of our company's emails have this error on them? They are all red and scary!"
I say this because I caught a developer a few days ago implementing an online payment gateway using a Wordpress "form to email" plugin. The ensuing argument came down to his firm belief that email to gmail is now "encrypted", and thus, this is perfectly safe.
We need to be careful about sending this sort of message.
Giving all your private data to a foreign company, serving interests of investors, acting directly against your and your nations interests is NOT acceptable, and should NOT be common.
Also, would you rather have users willingly giving their data to a foreign company (legally liable, bound to a published privacy policy) or unwillingly to malware authors and credentials phishers? In the current security landscape this is a very real tradeoff to think about.
And in fact, if you train your own neural networks to do this same task – as I’m currently doing – you get the same quality of categorization and spam filtering that Google got.
I consider Google, the NSA, and so on just as trustworthy as a Nigerian Scammer, so I see no difference in giving my data to Google, or giving it to the phisher.
They operate under laws I can’t control, use my data in ways I can’t control, and don’t ask me if they wish to use my data for more other purposes later on.
But yes, sharing training data (or trained networks) between people is the best solution.
Then you combine all networks that others share with you into a new one, and use that yourself.
Continuous recombination and cross-breeding of networks is the idea.
EDIT: As HN prevents me from adding new comments right now (Seriously, HN, allow us to post more than 3 comments per hour, it’s seriously hard to hold a conversation like this), I’ll answer your comment here:
Users would train networks locally based on their own decisions. Those networks would then be submitted to a repo, and you’d get other networks in return. If a network sorts badly (aka, you always undo its sorts manually), you will not get networks with similar sorting capabilities next time.
The concept would automatically prevent people from adding malicious networks – as they’d end up in the local blacklist of users.
Obviously you wouldn’t blacklist the network itself, but a representation of its concept of sorting.
Let's also look at the incentives for these networks that have data you can subscribe to. How are they supposed to keep spammers out? Any sort of vetting and management of the individual networks will be non-negligible, and if it's not funded will be at a disadvantage to the spammers that are doing this for profit.
Finally, I'm not sure that training sets for data like this can be easily combined without a massive amount of reprocessing, if at all. I'm not familiar enough with the classifying networks involved to know, but I suspect that problem alone ranges somewhere from "non-trivial" to "very-hard", if not already solved.
It sounds good, and in a perfect world we'd have well run and managed shared networks of fully anonymized spam/phishing classification training data that was easy to combine into individual personal classifiers without having to heavily re-process large training sets.
I'm just not sure how feasible the individual parts of that are, much less them combined into a whole.
* Neural nets or similar trained models, which we could prove don't leak information on the data they are trained on.
* A way to combine these models, without access to their training data, in a way that works as well as training a new model on the union of the data.
* A way to exclude spammers. If the models vote on each message, perhaps we would be okay as long as fewer than 50% of the contributors are spammers.
Can't remember the last time google stole money from me... Because it's never happened.
As someone who currently and previously has worked at Google, you sir are an irrational lunatic. Hope your tin foil is industrial strength!!
Google has been completely useless in protecting my data and emails.
Google has shared them with governments all over the place, including the US government and the NSA. Some parts obviously willingly, some parts out of negligence.
If Google can’t protect my emails from being read by any government, or being read by any employee or algorithm from Google that wishes to use my data for profiling, advertisements, or any other purpose that isn’t directly required to fulfill the tasks I gave it, then it is not doing what it’s supposed to do.
Also, accusing someone of being a tin foil hat wearer is just making you sound crazy in the post-snowden world.
Snowden has shown us proof that the NSA has had access to all the data from many US companies, including Google.
If you can prove otherwise, please do so – but currently, Google deserves no trust at all.
You're better off just trying to severely limit the amount of confidential information you put in email.
Seriously?
You suggest I censor myself instead of trying to act against the companies and governments that are acting against my freedoms?
Personal attacks are not allowed on Hacker News, whether someone else is wrong or not. Please don't do this again.
False dichotomy. As well, keep in mind that those privacy policies are subject to change w/o consent and are overridden by any country's government. So even with your false dichotomy you're just choosing _who_ steals your data, not if someone does. I'd rather live in a world where I can use services and not give away my data.
I feel that these improvements, while useful, are a sideshow to stop privacy enthusiasts from switching to better encrypted services or tools, while Google (and Microsoft, and Yahoo) continues to mine all of your private conversations for advertising purposes.
In the meanwhile, Apple also has encrypted notes, phones that are encrypted by default, etc.
Google seems to focus purely on transport security.
Then
1. Some device would need to be logged in and online (not always true)
2. You'd need a way to authenticate the new device, which means not only do you need the other device on, but you need it close when first setting it up, and you'd need to manually transfer keys or something of similar bandwidth
3.Either all history would need to transfer, which is a bandwidth hog if history is large (although if device is close then you could transfer over Wifi direct or bluetooth or something), or that other device would need to kept online whenever I want to query history (currently, Google serves this function)
4. If you lose a device, there's no recovery (this is probably the main reason Google won't do it.)
If you really want it, there are apps that do E2E and support Google Talk. See https://chatsecure.org/
________________________
Does anyone with more inside information know what is going on with it? Does it have dedicated team members or is this just an internal side project for a couple people?
Content analysis is the #1 feature required by enterprise email customers. They do _not_ want end-to-end encryption that would prevent content inspection by intermediaries. They do not want that at all.
https://www.security.googleblog.com/
Your connection is not private
Attackers might be trying to steal your information from
www.security.googleblog.com (for example, passwords,
messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
Wildcard certs only validate one subdomain of depth (so *.foo.com cert does not validate a.b.foo.com). HSTS "includeSubDomains" will require a valid SSL cert for all recursive subdomains.
It's a problem, but I don't think it's a problem worth solving.