Google Criticized For 'Opaque' Audio-Listening Binary In Debian Chromium 85
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.
"Ok, Google, are you snitching to the NSA?" (Score:1)
I can see why they'd be less than transparent about it..
Re: (Score:1)
When you stop visiting it.
Re:"Ok, Google, are you snitching to the NSA?" (Score:5, Funny)
Oh come on, you all know those engineers at Google, actually wrote that code in a HEX editor in straight machine code. It is completely open source. Just because you don't know machine code, doesn't mean Google is violating open source methodology. Say you didn't know APL and I created an APL program, and gave you the source. Am I not sharing the source with you?
FYI: Tongue in cheek.
Re: (Score:3)
I can see why they'd be less than transparent about it..
Nah, not the NSA. They spy for the one spying organzation bigger than the NSA: Google ;)
Re: (Score:2)
i, for one, like the idea of this feature. i just wish it would listen for a "f*ck you google" keyphrase and then immediately delete all google services related cookies from my browser. the "f*ck you google" subroutine should work completely locally but i'm ok with it increasing some kind of counter on google's servers. they should be able to see how many million people said "f*ck you google" this month.
Turn off in Windows? (Score:3)
Re: (Score:3)
unplug it, or if its embedded, remove the audio driver for it, or set the 'volume' control so it cannot hear anything anyway. And put some tape over the little hole it listens through.
Now.. good luck doing that on your phone.... best just to remove the app (if you can) or trust Google not to have slipped this stuff into Android as part of its voice activation feature (for your convenience, of course)
Re:Turn off in Windows? (Score:4, Informative)
unplug it, or if its embedded, remove the audio driver for it, or set the 'volume' control so it cannot hear anything anyway. And put some tape over the little hole it listens through.
Now.. good luck doing that on your phone.... best just to remove the app (if you can) or trust Google not to have slipped this stuff into Android as part of its voice activation feature (for your convenience, of course)
Hotword detection is optional in Android. If you don't like it, just turn it off.
Re:Turn off in Windows? (Score:4, Interesting)
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.
Re:Turn off in Windows? (Score:5, Insightful)
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.
Re: (Score:2)
having access to source code that purports to be what's running on the device doesn't get you there.
hence the superiority of the gentoo/lfs/etc approach :) but building Android is a serious nightmare... even if they wanted to give you the code.
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.
That seems like a fairly obvious thing to do; if it's in the kernel, then a user can reasonably work out whether it does what it's supposed to. Aren't there some facilities in the Linux kernel which could trivially be used to provide that functionality?
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.
There's always a down side. I perceive untampered Android security as pretty good, though. As long as you need root
Re: (Score:2)
having access to source code that purports to be what's running on the device doesn't get you there.
hence the superiority of the gentoo/lfs/etc approach :) but building Android is a serious nightmare... even if they wanted to give you the code.
No kidding. There's a reason my workstation has 40 cores and 128 GiB RAM.
I perceive untampered Android security as pretty good, though.
I do, too, actually. Far better than I thought it would be. It's refreshing to hear someone outside of Google say that, though :-)
As long as you need root elevation, it seems like the kind of thing that you can keep users from shooting themselves with accidentally. What more can you hope for?
Well, the current direction is to create a lot of firewalls between components that even root can't breach, using SELinux. This is obviously to reduce the impact of privilege escalation exploits, and even more important to eliminated many of them because many exploits today are actually exploit chains, so if
Re: (Score:2)
I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though.
So, how do you keep applications from knowing that the tap is in use? :)
Re: (Score:2)
I may be unduly pessimistic about the dangers of such a "central I/O tap", because I haven't had time to look at it hard. I will, though.
So, how do you keep applications from knowing that the tap is in use? :)
That would be the easy part. There'd just be no way for them to tell.
Re: (Score:1)
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.
Good luck. I captured all the traffic that a nexus 7 sends during initial setup, and it was immense. Numerous hosts, protocols, you name it. A few hundred megabytes total. Very hard to make heads or tails of (especially given the encrypted content).
Re: (Score:2)
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.
Good luck. I captured all the traffic that a nexus 7 sends during initial setup, and it was immense. Numerous hosts, protocols, you name it. A few hundred megabytes total. Very hard to make heads or tails of (especially given the encrypted content).
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And the idea would be to get as much as possible out before it's encrypted. It would still be tough to analyze, but people would figure it out.
Re: (Score:2)
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And if that data is flagged in such fashion as to not count against one's data cap?
Re: (Score:3)
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
And if that data is flagged in such fashion as to not count against one's data cap?
Android doesn't send any particular different parameters during setup. There's really no way the carrier could even know the difference. And if the device could send something that meant "hey, doing setup, don't charge this" you know custom ROMs would arrange to send that *all* the time, or at least as often as they can get away with.
Re: (Score:2)
It couldn't be that bad, or people on mobile networks would burn most of their month's data setting up a new device.
I don't know under what conditions Android will decide to install some subset of your installed apps to a new install; is it just when it thinks it's the old device? Sometimes when I reload my phone with another OS (I run SOKP on my Moto G 2014 (titan) and just did a clean flash of the latest) the play store wants to reinstall all my apps, sometimes it doesn't. I use Ti Backup so that it doesn't have to, and sometimes I have had to interrupt it trying to be helpful. That could easily come to hundreds of meg
Re: (Score:2)
Re: (Score:2)
You are absolutely, positively 100% wrong.
Really? Care to support that claim?
Re: (Score:1)
best just to remove the app (if you can)
I just got a tablet running Lollipop and in fact you cannot remove Chrome (without rooting).
Re: (Score:1)
If you can't see the Windows source, how exactly do you know what it's doing? It could easily claim to be muted, but in fact recording everything you say.
Re: (Score:1)
Go home, shill.
If the hardware is there, assume it will be used (Score:3, Insightful)
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.
Re: (Score:2)
No, this is why we use open source, so that things like this doesn't happen. Chromium is just not that opensource friendly.
Re: If the hardware is there, assume it will be us (Score:1)
Open Source software is not guaranteed to not have backdoors. Just because something is opensource doesn't mean it is safe or that someone (beside the original author) ever looked at it.
But while it is easier to spot backdoors in OSS than in closed source products it is also easier, for a trained eye, to spot defects and vulnerabilities that can be used for malicious purposes.
For this reason I second every hardware device that can limit the software from spying on me. A physical switch can seem old fashione
Re: (Score:2)
Maybe Dice ought to hire some of those "usability" experts advertised on their main site.
Who do you think came up with the changes in the first place?
Re: (Score:2)
. If they don't, then they're not UI experts.
They're not. "Usability Experts" these days are using "UX", to differentiate them from the people who actually understand such useless concepts as "use cases" and "suitability to purpose."
Re:Speaking of "opaque" - Dice, WTF re: comment li (Score:5, Insightful)
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: (Score:1)
You mean the one in the topright of every article that looks like a speech bubble and has the number of comments?
Protip: when the article has no comments that balloon isn't there. In fact, when an article has zero comments, it's not obvious that you even can click through to the comments page. There's no 'Read more', either, since that's been hijacked by the godawful 'share' links. The only place you can click is on the title. Above where you were just reading.
Re:Speaking of "opaque" - Dice, WTF re: comment li (Score:4, Insightful)
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: (Score:2)
You mean the one in the topright of every article that looks like a speech bubble and has the number of comments?
No, he means the "speech bubble" that COVERS OVER the rightmost 4 or 5 characters of each and every Article Title.
Re: (Score:1)
When you say no to beta anal fisting, you still get it very slowly, one finger at a time.
Re: (Score:2)
goatse! [goatse.ch]
Comment bubble thing next to the story icon? (Score:5, Insightful)
No. I do not like change. Put the comment link back below the summary.
Do it.
Do it now.
Do it.
Do.
It.
Re: (Score:1)
And what's with this "Share" button being so prominent now? Does anyone actually want to share things on Slashdot?
Re:Comment bubble thing next to the story icon? (Score:5, Funny)
Re: (Score:3)
Assuming we did want to share /. stories with someone, we only paste URLs into our chat clients, never "share" them on "social media" platforms.
I paste /. URLs into Jabber and IRC chats all the time.
Re:Comment bubble thing next to the story icon? (Score:4, Insightful)
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: (Score:2)
Re: (Score:3)
But the new design saves so much screen real estate!
Oh, wait. Because of that stupid "share" button sitting all by itself that nobody is going to use, you haven't saved any space at all.
Isn't one of the tenets of good website design that it's better make the links obvious so that people can find them? Old users are annoyed by the change because it breaks their expectations. New users are much less likely to find the comment section of Slashdot because there's no clearly-marked link to get to them -- you
Re: (Score:1)
time for better sandboxing / permissions? (Score:2)
The problem isn't so much that Chromium is doing that, it is that most packages run largely unprotected.
What Linux lacks is something similar to what the Android / iOS permission systems attempt to do (but aren't very good at either). All the low level infrastructure is there, but there is support missing at the package and desktop level.
Dice mismanagement? (Score:1)
Off by default (Score:2)
The key point I made in my official response [google.com] was overlooked by this article: the hotword module does not run at all unless you opt in, by going to Chromium's settings and turning on the "Ok Google" feature.
Once you turn it on, it's true that we don't send recordings to Google unless the hotword detector hears "Ok Google", but without explicit opt-in, this module is not listening. It is not even running.