This is the most likely attack vector for any automatically updating program on your computer, not just End-to-End.<p>What would stop a maliciously updated Chrome from recording all your keystrokes in the browser [all of your password; passphrases] as well as copying where you were at the time?<p>Etc.<p>This is one of those things where if you think the Government is going to silence you for being a dissenting voice and/or steal your info because of it...you grab an open source project, you compile it, you use that. You don't grab closed source software that automagically updates.<p>I don't think its reasonable to expect Google to protect the user from -every- potential attack vector.
This isn't a bug / complaint / observation of a vulnerability of End-to-End per se, you could argue Microsoft could be NSL'd to do the same to a user's operating system.<p>To counter this you'd need a secure, distributed way to release updates in Chrome. I don't think that's quite in scope of what this project is trying to accomplish.
Maybe the solution is to have the automatic downloads of chrome be anonymous and build the system in such a way that changing it would not be possible.<p>Basically, change the chrome automatic updater to not send any identifying information when it requests a update. That way, you can be sure that Google couldn't just target 'you' with a update.<p>Then, you just need to rely on the fact that people would be watching the chromium code for any changes which would negate the above anonymity.<p>The real challenge would be for Google to develop a way where they could not still identify people from their other data (IP, cookies, etc..) when they were requesting a update.<p>Maybe have a third party host/store chrome update binaries? Something like amazon S3 or something which would not data share with Google.
It is a hard problem, and it's a positive sign that Google acknowledges the problem. Providing end-to-end security also goes against the trend of expanding the non-open parts of their Android app suite.<p>In addition to the reported bug, this plugin is handing cleartext back to Google-controlled code. Web apps and good security are still miles apart.<p>But this is still a significant change from a year ago when we heard internet portal CEO kvetching about the NSA and not even mentioning and-to-end encryption.<p>There is still a VERY long way to go before this counts as democratizing end-to-end security. Any portal that has real time communication tools and a social graph could also provide tools for automating Web-of-trust and key exchange.<p>All journeys etc.
I think its a moot point, if the government is the attacker, who tries to spy on you specifically, there is absolutely NOTHING you can do to prevent that from happening.<p>The US government has (literally) secret laws, that grants themselves the right to go to another country and kill someone without due process or trial or any kind of repercussion if they 'accidentally' kill innocent bystanders.<p>Its sort of laughable to talk about end to end encryption and possible NSL when you really think about it.
You know, if we had DRM infrastructure we could actually trust, this wouldn't be a problem. Granted, having DRM we can trust may well be itself an insurmountable problem.
It doesn't seem like they're ignoring it. They just don't have a quick fix for this hard problem.<p>If you've got an easy answer, please post it on the bug!
What's the precedent for a company ever being required to ship backdoored products to their customers by government legal order, NSL'd or otherwise?<p>"The FBI once lobbied for the government to give them that power!" or "look at these service companies that had evidence in their possession they were required to turn over!" are non-answers.