The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a.
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.
> 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.
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.
> It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]
Fair point, but AFAIK Android was never released as an open source project until it was Google owned.
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.
You were emphasising the wrong part of my sentence. Many proprietary components that are now part of Google Play Services have existed seperately for longer than the "Play" brand had: https://en.wikipedia.org/wiki/Google_Mobile_Services
> Fair point, but AFAIK Android was never released as an open source project until it was Google owned.
Since we're both being pedantic here, I never said that it was. :) I believe the GP did though (the person you were initially replying to, that is).
> Many proprietary components that are now part of Google Play Services have existed seperately for longer than the "Play" brand had
You're right, and that's one of the things that bothers me about Android's reputation for being an "open" or "open source friendly" OS. Yes, AOSP is open source software (if you leave out the binary blobs necessary for the radios and GPU to work), but even plain vanilla Android as shipped by Google is far from open source. Google has steadily been moving towards a closed/locked down model in many of their projects.
>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.
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".
There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany). Konquorer was still kHTML last time I checked, but there are with webkit ports as well if that's really what you want. Then there's Opera, which on some platforms (eg Linux) is still using it's older renderer rather than Blink (see footnote); and Otter as well. There's quite a few Firefox forks too (eg Palemoon)....and if all else fails, you can always run lynx or elinks :p
So there are definitely quite a few alternatives (the last two were obviously a joke though). Granted many are not as feature rich, but they'll still be HTML5 compliant.
Thank you for the correction on the Google Chrome/Chromium point though. Updated my post to reflect that.
Footnote: has anyone checked if this is a Blink issue or just Chromium? Because Opera, Vivaldi and other browsers use Blink but likely wouldn't have hotword. So that would be even more alternatives available.
>Granted many are not as feature rich, but they'll still be HTML5 compliant.
This is a meaningless statement. HTML5 is a moving target. And on top of that, webpage design has deteriorated to the levels we saw around 2000 again: to be usable, your browser has to mirror the most popular engines well enough that sites work.
Most of the browsers I exampled used popular engines (Blink, webKit, Gecko).
And if you want to get pedantic about HTML5 being a moving target, technically it's not. People often lump the other web front end components (CSS, SVG, EMCAScript, etc) under the HTML5 heading - those components will obviously have their own specification enumerations. Furthermore, a lot of the tertiary technologies that are a moving target are either experimental features / proposed drafts (ie not part of the final specification) or browser specific extensions. Most sites tend to avoid using these without fallback code for non-supporting browsers (demo sites being the obvious exception).
>There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany).
What about Midori (LGPL 2.1)? For some reason it's not available for jessie, but 0.4.3 is available for wheezy, stretch, and sid: https://packages.debian.org/stretch/midori
Firefox does auto-download an OpenH264 binary on systems without a supported H.264 decoder library (if this feature is enabled, which it isn't currently in Debian's iceweasel packages). But note that OpenH264 is free software available under the BSD license:
Firefox downloads binaries from Cisco because Cisco can legally distribute this software in binary form in countries where H.264 patents apply, while Mozilla can't do so directly.
There was also a plan discussed to make it easy to automatically verify that the binary corresponds with the published source code, but as far as I know that work hasn't been done yet:
> 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.
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?
> 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.
Indeed. But that doesn't change my statement.
> 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?
Because you'd still have the same browser choices if you did move :p
In all seriousness though, what are your options:
1. fork Chromium and remove the closed components
2. use another browser
3. moan on the internet
You've got 3 nailed but that doesn't seem to be helping the situation. So maybe you should start a fork instead? Or perhaps go with my suggestion of boycotting Chromium since it actually turns out to be the easiest practical solution despite your exaggerative remark.
> An obvious one, getting an explanation from the vendor / upstream before we proceed to any decision.
I'd already addressed that. In fact you quoted it when you posted your condescending reply. An explanation is worthless if the code cannot be reviewed. Such a feature should either be opt-in and/or open source.
I couldn't care less what explanation Google give, I just don't want this built into my browser.
> It's normal to have a collection of patches in the package file / port.
It is, but then you're relying on your package maintainers to patch Chromium (or compile the software yourself). Thus personally I think it's easier just to use another browser which doesn't need to be patched to remove an unwanted feature.
Hi, I'm an engineer from Google responsible for the hotword module.
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.
Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.
We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time.
The fact is that an end user should not care if software downloads a "binary blob" without running it. This is functionally equivalent to downloading anything from the Internet, a JPG file for example. Chromium downloads a bunch of things on startup, and nobody seems to mind. Just because hotword.nexe happens to be an executable blob doesn't really make a difference.
"The fact is that an end user should not care if software downloads a "binary blob" without running it."
Is that the official position of Google? Reminiscent of when Thomas Hesse from Sony stated: "Most people, I think, don't even know what a rootkit is, so why should they care about it?"
Functionally equivalent to a .jpg how? You mean by the fact that the .jpg is an executable set of instructions telling the system to eavesdrop on me?
Great point. Sure, I get it. By that logic, sending me a mail bomb (and of course, not activating it, because I mean who would do such a thing after painstakingly creating it?) is the same as sending me flowers.
So a picture isn't a picture until you look at it?
Whether or not people should care, some people do care. If Debian has to edit what you distribute to remove proprietary parts of it, you're probably not distributing something that is open source (which means 100% open source).
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.