This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it might instead accept instructions to transmit audio from particular parties that Google wants to spy on.
I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed.
This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android, twice: once with the "Play Service Framework", which is a collection of APIs added to Android but theoretically independent of it, and again with Google Glass, which ran an entirely closed-source fork. In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.
That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.
If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.
edit: s/Google Chrome/Chromium/g
> This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android
Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.
> In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.
Did you do a write up of this study? I'd be interested to read it :)
It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]
> and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.
No, Google Play Services was first released in 2012, whereas Google's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning.
[1] https://en.wikipedia.org/wiki/Android_(operating_system)#His...
[2] http://android-developers.blogspot.com/2008/09/announcing-an...
The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".
Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code.
It's highly suggestive.
> If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.
Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up?
I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not need to trust Google engineers to tell you this; the open source Chromium code has the logic to decide whether to run the plugin.
I have posted a detailed response (including the link to the place in the Chromium source code where the module gets run) on our bug tracker at http://crbug.com/500922#c6.
Isn't Chromium behind the enterprise chromebox/chromebook stuff too? And does this mean that Chrome itself may, or has already, install eavesdropping software and activate it without my knowledge?
Edit: I see from a sibling comment that OS X has this eavesdropping software installed, so that leads me to believe that everyone running chromium devices will have this activated, and that it's going to be part of Chrome soon, if it isn't already.
I know it's hyperbole to call it "eavesdropping software", but I also know how many people here were unsettled by "OK Google" and "Alexa!" (Amazon Echo), and I really do want to understand how folks here feel about the intrusion.
By its turn, Chromium's only selling point was that it was free of the eavesdropping features.
From my POV, the thing that's actually bothersome about this issue is that a closed-source blob is automatically inserted into a project that I -and others- had understood to be completely open-source.
The fact that the Chromium Google Hotword code was later made opt-out -rather than opt-in- through a build-time configuration option is similarly troubling.
[0] IIRC, Chromium does support enterprise TLS snooping/interception devices, but those certs have to be loaded into Chromium before such devices will work.
Didn't foreign government agencies already do that? (e.g. NSA?)
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.
Granted.. This is a binary blob downloaded without consent which is an issue, its just not an issue with the Debian archive distributing unvetted code.
Consider what this backdoor does. It listens to any conversation in the vicinity of the phone and reports it to a remote site. You can't see its keyword list. You can't tell when it's transmitting to the mothership.
Has anyone filed a US-CERT report with Homeland Security on this?
"Yeah, we know. It's ours. Don't worry about it. Go about your business. Pick up that can, while you're at it."
What phone? Last I checked this was for the desktop build of Chromium
Google's not even trying to not be evil these days.
This fix is an opt-out with a compilation flag. Also, I don't know much about Chromium development process, so it might be irrelevant, but I only see source updates, without any updates in the documentation.
Note that as soon as you go to ANY WEBSITE using Chromium, you are entrusting that site to download you arbitrary data, which could include NaCl binaries, which you're then going to trust Chromium to execute.
The problem here is not mainly that it downloads and executes code via NaCl, though it's iffy that it does so with no simple way to disable it.
The problem is if it does so and grants that code access to API's' that should be privileged and something the user ought to be aware of.
https://codereview.chromium.org/1160243004
(Names removed as don't think they're important to repost. And not intending this as incendiary. At some point someone needs to ask "How much are we impacting usability by stripping features?")
"1 week ago (2015-06-09 02:17:42 UTC) #19
On 2015/06/09 01:34:04, _ wrote: > On 2015/06/09 01:13:10, _ wrote: > > Done, but I'm going to voice my opposition to this. When I took over the > > hotwording code, there were a number of obscure hoops to jump though to get > this > > to work locally. They've been eliminated. Having to find these pair of > #defines > > and changing them is more obscure to a newcomer than a build flag (that can > > easily be traced through the code). >
> What about having a run time flag for enabling hotwording? We would always > enable hotwording for Google Chrome builds, and check for it in Chromium builds. > That way, Chromium users can make the decision to use the feature, rather than > the Chromium distributor. And it won't require hotwording developers to build > with GOOGLE_CHROME_BUILD or do any #ifdef hacking.
We shouldn't be exposing feature-enables to end users as runtime switches.
Honestly, I think the right thing to do is for Chromium users to get this by default but have a build switch that can be used to disable it for projects like Debian that feel more strongly about not having any external binary blobs used for anything. I don't think simply disabling this in general for Chromium is correct. It's not true that Chromium by definition should not make use of such blobs, and I think the damage to developers and to more pragmatic users of Chromium-based projects is greater than we should be willing to pay."
There are large security differences between what NaCl allows for web content, and what it allows for what Google considers internal parts of Chromium, even if they run in NaCl. Like this blob here, and also Flash, the PDF plugin, and others. All those do a lot more than what a random website would be allowed to.
If so, I will never run it again.
Javascript isn't far off binary in terms of readability nowadays with the level of packing/minification, so legibility isn't a deciding factor. Therefore if you can't trust the native client sandbox, why trust javascript, or even HTML from third parties? Native client is part of Chromium, you can audit the source code just as much as for any other language your browser speaks, so why make this distinction?
1) opted-in by default
2) not ask user for permission (or notify him in any way)
3) hide the extension from the extension list
4) record audio without permission
How sad.
I remember when I was a toddler and they taught me that Santa's elves and God's angels where spying me to make sure I was good. They later told me it was a lie. It became true soon enough.
Fighting for privacy is impossible. We should fight instead for transparency, that means, spying those with power. And we should fight for equal rights, that means, making it hard for people to hurt you with the private knowledge they have from you.
The conspiracist in me wonders why both these major browsers have downloaded and maybe executed binary blobs. Is it purely a convenience feature in the browser? Is it a secret order? That last question would have been silly a decade ago but we all know it's entirely possible now.
The reason why there's a blob is because for that binary, Cisco pays the patent licenses.
So you can verify the source for any issues, verify whether it matches the binary, and work around MPEG-LA licensing at the same time (there are caps, and Cisco seems to have calculated that even when running into them, they're still better off with having webrtc support h.264 everywhere).
I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :(
Pocket is just a button that does a couple of AJAX calls to the Pocket site.
Both do have closed source code online, but when you click them it's pretty obvious that they are talking to some online service which may or may not snoop. You even have this "danger" when using Sync in any browser. In all these cases it's very clear what's going on.
When you use Pocket you know that the URL of the page you were visiting was sent to some service. When you use Hello you know that some routing service might be able to snoop on your call (I believe there's some encryption here though, but I'm not sure). When you use Sync you know that you're sending data to the server.
When you enable "Ok Google" detection in an open source software one would expect that the "Ok Google" detection is done locally in open source, verifiable code, and only after this detection is triggered, will sound be sent to the server. If this blob was instead some open source code, one would be able to verify that sound is only sent to the server when it is expected. But now that it's a blob, you don't have this guarantee. It could theoretically send periodic sound snippets to the server without you noticing, since it's listening on the microphone all the time.
That's the difference. Firefox's proprietary integration has verifiable triggers. It won't talk to a proprietary service unless you ask it to, and when it does you can verify what data it is sending.
On the other hand, this blob has no verifiable triggers. Yes, it is disabled by default (verifiably, apparently), but when enabled the data it collects and sends is not verifiable.
(Firefox also does have some blobs -- one for H.264, but the code behind it is open source, the blob is distributed for licensing reasons, and one for EME, but the EME blob is downloaded only with a confirmation which informs the user what is going on)
https://projects.archlinux.org/svntogit/packages.git/commit/...
thanks to the maintainer and the FOSS community in general.
...that is until the domain admin checks his email and opens a malicious PDF.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51
Downvotes? So you agree with this?
"I seriously consider the good faith of an such upstream which does these kinds of things"
"But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or forcibly cooperate with NSA and friends)."
"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."
"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."
Really if you condone this attitude then I can only say...well I won't say it but it isn't nice. Not only that, everyone seemingly ignores the: "Note that the binary blob is executed throught native client, which is not enabled by default" part.
You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.
Since no one really know which binaries have been downloaded there and what they actually do, and since it cannot be excluded that it was actually executed, such systems are basically to be considered compromised
A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident.
Many people are used to it because of all the training received by the "Java Auto Update", "Google Update Helper" and similar software receiving blank permission to monitor, download and execute closed source software with the same permission as the logged in user.
Despite of that a person that goes to the lengths of using Debian (instead of Ubuntu) and Chromium instead of Chrome certainly expects more from their sources than to allow this kind of behaviour.
It is a security incident and should be treated as one both by Debian and by the community in general.
Whereas source code being downloaded, compiled and run is not? Or a script being downloaded and run?
It is the dismissive response which is not appropriate. The responder asserts that the blob is safe and trustworthy, how would anybody know?.
But the tinfoil hattery is completely baseless.
It could theoretically be a rootkit, but without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.
Whether we agree or not is not really relevant. Advising people to not read a bug report because one of the comments in the discussion associated with the report doesn't appeal to you is... strange, to say the least.
How do you manage any kind of discussion format if opinions (however wrong they may be) you don't like make you leave the discussion entirely?
In this case the original report is informative, what comes after (up to 2 posts now) probably isn't going to be.
