Hacker News Reader

Comment by metric10 | Hacker News Reader

Has anyone actually confirmed that Chrome is continuously sending audio back to Google? I highly doubt that this is the case. Instead, the plug in knows how to recognize "OK Google" all by itself. Once activated, then it starts sending audio data.

IF it where really listening even when inactive, then people would be complaining about it sucking up bandwidth and data allotments.

View on HN

It's not about consistently being bugged though--I see two troubling implications to this;

a) Government A decides target B has valuable communications, and uses this audio capture functionality as an attack vector (ie, a MiTM server modifies the chrome binary blob request slightly to a version where chunked audio is sent back to a control server).

b) (more likely) This binary blob contains a voice recognition algorithm, which can of course detect the phrase "ok, google." Imagine they wanted to detect other phrases, like "drugs" or "travel." Small modifications could easily allow an arbitrary list of "hot" terms to be targeted. Then no audio is even sent back from the user's computer--a small flag in your google account is simply set attaching your profile to "high risk" terms overheard, and databased, where it could later be queried by law enforcement.

It's troubling because there's no transparency, and if you spend a little time brainstorming about the ways this could be used maliciously (most likely by a nation-state) there are many possibilities...

This is true of any auto-updating software, including your operating system and all evergreen browsers.

The problem with this blog post is that the author gets in a tizzy about what could happen, not what is actually happening. What could happen has not been affected by the recent Chromium screw-up, nor is it specific to Chromium.

That's not really a problem; it's a feature. The author is pointing out the significance of defense-in-depth to protect against the scenarios that can happen in light of what has happened.

Except Chromium as a framework is in an interesting position... and I think the threat is not even in how this could be used with malicious intent, but rather how easy it allows for indiscriminate passive logging on a grand scale.

Chrome is a very widely-distributed piece of trusted, self-updating software. It's also (for most users) directly connected to your google account--which is in many ways an intimate mirror to your identity.

You're absolutely right that this issue is not unique to Chrome, and can (and does) arise in any piece of software from native OSes & apps to 3rd party binaries.

I also think Chrome specifically warrants added concern for its ubiquity and de-facto link to your identity.

Anyone can use these techniques to target an individual, network, or system, but Chrome is one of the most widely distributed pieces of software designed with analytics in mind, from a company known for designing algorithms to improve contextual awareness.

What that means is, it's uniquely trivial to add in a few vectors of phonemes to recognize certain words/phrases, flip on an analytics pixel, and instantly have 100's of millions of devices running chrome associate their linked google accounts with this word/phrase.

What sort of transparency would satisfy you in this case?

In this case, either the speech-recognition feature being included in the chromium source (and not as a raw network-reconciled binary), or else have the feature be opt-in, not enabled by default.

c) (even more likely) The algorithm released in the blob is much simpler than the one locked in their servers, and it has many false positives. The audio from false positives is archived to help improve the simplistic algorithm.

I just tried the feature out on my windows pc with chrome, and chrome only reacts to ok google when you have a new, empty tab, or the google search page open and active as the main tab. Additionally i checked with procmon what network activity chrome was making, and while it starts sending stuff AFTER "ok google" is activated, it doesn't send any between me saying it and chrome confirming it.

The theory that it's a small local plugin is also affirmed by the fact that my cellphone can do "ok google" without any sort of network, and is sometimes tricked into activating by audiobooks that make noises completely unlike "ok google".

I'm not sure of the use of the feature if it requires you to touch your keyboard and mouse in order to open up a new window to use it.

It's probably not actively listening to all users. But if it has the capability, then it can be activated upon request by law enforcement or the NSA.

Any computer with a microphone (almost all!) has this capability.

In theory, that's only true if the user has given permission for some remotely-accessible application to activate it. In practice, the NSA almost certainly has ways to accomplish it, but that doesn't mean we should make it trivial.

If compelling Google into changing their software to allow it to record audio for the NSA is trivial so is compelling Microsoft/Apple into changing their OS to allow the NSA to record audio. Chrome doesn't change things if the NSA is willing to make its objectives known to software vendors.

The FBI have activated the microphone of a feature phone in an organized crime case. The phone wasn't on a call, but the mic was activated, evidence was gathered, and was used in trial.

It's interesting to note that the mic can be activated with the cell phone "turned off", as some models at the time didn't fully shut down even being powered down.

Here's an article from 9 years ago on the case that the government decided to make public. http://news.cnet.com/FBI-taps-cell-phone-mic-as-eavesdroppin...

Is that a valid argument for every phone being able to have this capability? Accomplishing this on computer either requires informed consent or some kind of malware/backdoor. On Google Android it's a feature.

You could sneak it through on a client update, if compelled.

This happened 12 years ago when the FBI tried to eavesdrop on conversations taking place in a car with OnStar or a similar device. Agents wanted to remotely activate the car's microphone; I wrote about the case here: http://news.cnet.com/Court-to-FBI-No-spying-on-in-car-comput...

The 9th Circuit said "no," but the court's reasoning wasn't based on privacy concerns. The reasoning was that companies can only be forced to comply with wiretaps when the order would cause a "minimum of interference" (and the FBI's tap would have disabled the call-an-operator feature if there were an emergency, which exceeded the "minimum of interference" threshold).

This is not unique to Google, which has done a better job than just about any company I can think of at fighting off overly broad surveillance demands; see my post from two years ago for examples: https://news.ycombinator.com/item?id=5725899

Why could Apple, Microsoft, or Samsung not be compelled -- let's assume an actual court order exists -- to deliver a software update to a specific user that allows FBI agents remote access to that device microphone? Or AT&T? Or Verizon? We know from recent history that AT&T is hardly likely to put up a fight.

I wrote more about the outer limits of the Feds' surveillance authority here: http://www.cnet.com/news/how-the-u-s-forces-net-firms-to-coo... Excerpt: "Precedents were established a decade or so ago when the government obtained legal orders compelling companies to install custom eavesdropping hardware on their networks..." And earlier: "In 1977, the U.S. Supreme Court ruled that surveillance law is a "direct command to federal courts to compel, upon request, any assistance necessary to accomplish an electronic interception..."

In terms of a hierarchy of privacy protection, I trust technology > courts > Congress > DOJ oversight > FBI.

I was thinking something similar... that would be a LOT of data being sent back continuously while Chrome was running, which for many people is 24/7. If you had an office of Chrome users the entire office pipe could be eaten up by what is essentially X number continuous VOIP calls.

Right. There's no way this would go unnoticed on any enterprise or government network, and once noticed it would end the use Chrome in those environments. In fact it would have unimaginably huge consequences. It would mean huge numbers of CEOs and government officials in all countries where being bugged, all dependent on Google securely keeping millions of audio streams private. This doesn't pass the giggle test.

Talking of the giggle test, millions of audio streams is just the kind of thing this was designed to snack on - https://en.wikipedia.org/wiki/Utah_Data_Center

Regardless, the black box aspect means this can be targeted to high value individuals and could even be limited to their home or mobile networks. Then again, it's somewhat irrelevant since all sysadmins are already legally owned by security services and sworn to secrecy by the current legal frameworks, no cloak and dagger required. And it would be hard to believe that any competent foreign intelligence org hadn't fully infested such juicy targets as google and high value corporate networks long ago.

There's an old rule that you shouldn't write down anything you wouldn't want to hear read out in a court of law. Same goes for online, and now for when you are in the vicinity of a mobile device.

It would be the worst possible implementation of the feature for a laundry list of reasons.

First of all, they need to send only data when there is something to listen, so above a specific threshold. They can also compress the data. Second, I'm sure that if Google can handle traffic that's generated by youtube they can handle voip traffic.

It can definitely detect OK Google on its own, here's what it looks like when you say "OK Google" when not connected to the internet (and it only shows up after saying it):

http://i.imgur.com/CCTGbsk.png

The problem is that it cannot perfectly recognize "OK Google". There are going to be false positives, things that sound like "OK Google" to the plugin, but are not "OK Google". And it will send those recordings, plus what said after them, to Google servers.

> Has anyone actually confirmed that Chrome is continuously sending audio back to Google

I would change it to:

Has anyone actually confirmed that Chrome is continuously listening?

Tell you what: you get me the source code, and I'll tell you what it's doing.

I'd say it's pretty much a given that it's continuously listening. How else would it know when to respond to an "ok, google" audio cue?

> How else would it know when to respond to an "ok, google" audio cue?

Because you open a new tab or you go to the search bar and then starts to listen IF you have activated that option?

"Ok Google" only works on a new tab page. Look at the microphone icon in the search box to see whether it’s listening for the phrase "Ok Google" or not:

https://support.google.com/websearch/answer/2940021?p=ui_hot...

More importantly, the plugin does not even run unless you opt in to hotwording (by checking the check box in settings). The open source Chromium code makes sure of this. So you do not need to take our word for it.

Please see my statement here for details: https://code.google.com/p/chromium/issues/detail?id=500922#c...

Furthermore, you are right that if you turn on the "Ok Google" setting, the plugin will start listening to your microphone, but will not send audio to Google servers unless it hears an "Ok Google".

good point. However, don't trust them to care about your privacy too much. This is never the case.

> Has anyone actually confirmed that Chrome is continuously sending audio back to Google?

That's not relevant. The problem is that they _could_ do that (for some subset of users, potentially) and in most cases no one would even notice it.

Reply on news.ycombinator.com