The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a.<p>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.<p>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.<p>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.
So, if the article was titled "Chromium downloads and activates closed-source eavesdropping software on all its devices, bypassing any OS alerts", would that be too wordy? It's meant to be a little tongue-in-cheek, admittedly, but it seems to me that's exactly what they did.<p>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?<p>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.<p>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.
A bit surprised that there is no security CVE report attached. Debian policy is that binaries are vetted by a debian developer, sorted into Main, Contrib and Non-free, cryptographically signed and later verified by the client package system. The bug could allow arbitrary code to be installed and run without any of the above process if someone MitM the connection between the binary file and the client.
Note that although this bug report was forcibly closed, the fix is "This change adds an "enable_hotwording" build flag that is <i>enabled by default</i>, but can be disabled at compile time."<p>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.<p>Has anyone filed a US-CERT report with Homeland Security on this?
From the comments on the debian bug, this appears to have been fixed in Chromium. <a href="https://code.google.com/p/chromium/issues/detail?id=491435" rel="nofollow">https://code.google.com/p/chromium/issues/detail?id=491435</a>
So when I've called Google Chrome for "spyware" in the past I can now add Chromium to that list.<p>Google's not even trying to not be evil these days.
<a href="https://code.google.com/p/chromium/issues/detail?id=491435" rel="nofollow">https://code.google.com/p/chromium/issues/detail?id=491435</a><p>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.
In a web browser implementation with NaCl support, downloading and executing arbitrary binary blobs is very much a feature, not a bug. The issue here seems to be that Chromium was configured, by default, to download and execute a particular Google-provided binary blob. And now it isn't.<p>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.
I opened a ticket in Chromium's Google Code repo, feel free to jump in: <a href="https://code.google.com/p/chromium/issues/detail?id=500922" rel="nofollow">https://code.google.com/p/chromium/issues/detail?id=500922</a>
Since these things can be opaque, archlinux updated to disable "hotword":<p><a href="https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=c82e0548218e0398c3788730f3a729d714191d0c" rel="nofollow">https://projects.archlinux.org/svntogit/packages.git/commit/...</a><p>thanks to the maintainer and the FOSS community in general.
Another reason to switch to Iridium Browser. It has Google search disabled by default and even if you switch search to Google, Voice search and hot-words stay off until you manually enable it.<p><a href="https://iridiumbrowser.de/" rel="nofollow">https://iridiumbrowser.de/</a>
I advise not reading that bug, some of the later comments will give you brain cancer.<p><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51" rel="nofollow">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51</a><p>Downvotes? So you agree with this?<p>"I seriously consider the good faith of an such upstream which does these kinds of things"<p>"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)."<p>"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."<p>"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."<p>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.<p>You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.