Arbitrary code controlled by a single organization (Google) is still arbitrary code.

In then sense of "arbitrary code [...] if someone MitM the connection" it certainly is not.

I missed that the parent comment added that conditional. I suppose I should have responded directly to them instead of under this comment then.

> If someone has MitM'd Google, it's gonna be a bad day for a lot of people.

Didn't foreign government agencies already do that? (e.g. NSA?)

They spied on unencrypted data as it was transferred between data-centers. They can't decrypt or MITM anything because they don't have google's keys, and chrome using HSTS cert-pinning means that the cert is fixed and can't be faked with one for google from another top-level CA.

> They can't decrypt or MITM anything because they don't have google's keys

Hard to prove a negative.

Then show an example that proves the NSA has Google's keys. If you want to do proofs, how about you put your money where your mouth is?

This isn't proof that the NSA has googles keys, but it outlines how the NSA uses stolen keys to decrypt information. I'd imagine google would be one of their main targets.

http://www.newyorker.com/tech/elements/how-the-n-s-a-cracked...

> ... they don't have google's keys

Assumptions, assumptions.

Yeah. Spies have regularly provided data, for free or minimal compensation, to nation-state actors. Sometimes, this is information they know will result in the deaths of others. Often, the very act of doing it may result in the death of the perpetrator if caught.

Appeal to patriotism, a few million bucks, and immunity from prosecution? Surely someone highly placed at AppGoogAzonSoft is susceptible to that.

As far as we know only on insecure channels. Google had "private" pipes that they thought they didn't need to encrypt between datacenters and they didn't think they needed to encrypt that data. That was the MITM we knew about. I don't believe we know of them MITM'ing a cryptographically secure channel.

>I don't believe we know of them MITM'ing a cryptographically secure channel.

... two years ago.

Can I have a good citation on that? I'm interested in knowing more about it. Also, I'm not sure if you're referring to snowden or something else.

Although Bruce Schneier suspects new leakers behind recent reports, for now anyway most data about NSA capabilities that we have comes from Snowden documents. From this data it indeed follows that NSA didn't break cryptography two years ago. But it would be plain unprofessional of them not to raise the game by this time, especially given world's backslash against leaks.

I'm not saying that NSA nowadays have means to break strong crypto. But they surely should have responded to the growing usage of crypto in some way. My money goes on increasingly employing insiders.

Actually, I'd say the probability of three-letter-agencies planting backdoors after Snowden leaks have increased: developer community hasn't responded with radically new tools and techniques that would allow us to detect and root them out on mass-scale, at the same time journalists burned lots of NSA's precious toys while IT-companies rendered others useless by mass-deploying crypto and modernizing their infrastructure.

Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection. Secret downloads has the problem to display certification errors and similar things to the users, so they would likely have to reimplemented quite a few code paths to make that work properly. https and tls is also not mentioned in either bug threads, which is a worrying sign.

If it uses TLS, then the bug is less exploitable but does still violate security policy of the vetting process, signed code and license classification (closed-source blob). At minimum, it leaves anyone vulnerable to arbitrary code injection from Google.

> Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection

If this was some random enterprise Java app, yes, that would be a reasonable assumption but you're talking about one of the most heavily audited codebases in existence, which has one of the best security teams in the world working on making TLS stronger and aggressively pinning certificates. Their track record would merit actually looking at the source rather than simply speculating.

It really looks like it uses the normal way to download extensions; the Web Store.

I'd be more concerned that the only thing the patch seems to do is not activate the hotword extension. It seems to still download and install it. I mean, maybe I'm wrong here. I think that checking through https://chromium.googlesource.com/chromium/src/+/f269d3b5482... for ENABLE_HOTWORDING is the right thing to do if one wants to understand the change that was made.

But this isn't a 'secret' download. Google isn't trying to hide it at all, it's just a feature for the browser. So there is no reason to try to avoid problems associated with certificate errors.