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.)
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)
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.
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.
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.
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.
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.
Just because you can deal with complexity doesn't mean you should accept it, or seek it for that matter.
I think Adam Langley has already started such a project, but it's only been a "spare-time" project:
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
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.
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.
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?
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...