Google Criticized For 'Opaque' Audio-Listening Binary In Debian Chromium

An anonymous reader writes: Google has fallen under criticism for including a compiled audio-monitoring binary in Chromium for Debian. A report was logged at Debian's bug register on Tuesday noting the presence of a non-auditable 'hotword' module in Chromium 43. The module facilitates Google's "OK, Google" functionality, which listens for that phrase via a Chrome user's microphone and attempts afterwards to interpret the user's instructions as a search query. Matt Giuca from the Chromium development team responded after the furore developed, disclaiming Google from any responsibility from auditing Chromium code, but promising clearer controls over the feature in release 45.

Comments

If the hardware is there, assume it will be used

[Anonymous Coward]

That is one reason my desktop doesn't have a mic, nor a camera. If it isn't there, then software can't abuse it.

Even with laptops, back in the early 2000s, I remember a brand that had an analog switch. Flip the switch, no mic, no way for software to access the mic.

We need that functionality back in hardware, just because it should be assumed that software will abuse it.

Comment bubble thing next to the story icon?

[meta-monkey]

No. I do not like change. Put the comment link back below the summary.

Do it.

Do it now.

Do it.

Do.

It.

Re:Comment bubble thing next to the story icon?

[Anonymous Coward]

That's not the worst part. They don't just not know the audience, they don't know how this site is used, or why it's any good.

Nobody is going to share the /. summary of a linked article. The summary is crap most of the time, the good part about /. is the discussion it generates, not the summary itself. You'll either share the linked article (so nothing related to /.) or the article page with the comments after you read the comments.

Put a big-ass share button button on the bottom of the comment page and you'll get more shares and might get more readers after they see the comments. As it is right now nobody will use the share button and newcomers to the site won't even realize there are comments worth reading and will dismiss it as a crappier commentless reddit clone.

Re:Speaking of "opaque" - Dice, WTF re: comment li

[ArchieBunker]

More minimalist bullshit. If you have to stop and think about what a button or image means then the design is broken. What is wrong with the word "comments"? Why must it now be a cartoon speech bubble?

Re:Speaking of "opaque" - Dice, WTF re: comment li

[Anonymous Coward]

Or just clicking the article name? Its the same damn page. This really isn't that hard.

It's not obvious that the article name is where you would click to delve into the article since it's above the summary and most people read from top to bottom. Not only that, but on a collapsed article, clicking on the title expands the post. Why on Earth would I expect clicking the title again would take me to the comments and not to collapse the post back down again?

Re:Turn off in Windows?

[swillden]

Hotword detection is optional in Android. If you don't like it, just turn it off.

The software which provides hotword detection on Android is also not auditable. How do you know it doesn't turn itself on when it detects that you're not looking at it, or monitoring it via adb? Oh no, I don't really think that it does either, but it's precisely the same concern as on Debian. You'd have to not install the google services to be sure you were avoiding it.

If that's your level of paranoia, you're lost, and omitting the Google services doesn't help.

The fact is that you implicitly and deeply trust all the companies in the production pipeline for the networked electronic devices you use, because absolutely any one of them can easily arrange for whatever sort of backdoor they want. It's a little tougher for the hardware component vendors, I'll grant, but if they do the work they're in the best position of all to compromise your security without any possibility that you could find it.

With Android specifically, though, I'm interested in ideas for how we can make the system more transparent. We can't do anything about hardware-level compromises, but I'd like it if the upper layers were more auditable -- and note that having access to source code that purports to be what's running on the device doesn't get you there.

One idea I've been toying with is a framework-level network tap that allows you to divert a copy of every bit that your phone sends or receives, via network, Wifi, bluetooth, NFC or USB, for your perusal and examination. Since most apps use the framework APIs for SSL, it should be possible to snarf this data before it's encrypted, too. Of course, there's a big downside: if this single data collection point exists, it will be a tremendously attractive target for compromise by other parties who want to see what your device sends or receives.

You're a smart person, do you have any ideas for what Android could do to make its operations more transparent? We can't achieve perfection, but if we could get it to the point where Google or anyone else in the supply chain would have to do something which is obviously and solely intended to hide their actions in order to exfiltrate private data, that would be great.

Note that this is not an idle question. I'm a member of the Android security team, and in a position to make these sorts of things happen, or at least dramatically increase the likelihood.