10 ms·

The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a. This is labelled as being a

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.

laumars 11y ago
> 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 :)
- qwe123 11y ago
  >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".
  - laumars 11y ago
    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.
    - fao_ 11y ago
      And as a last resort, one could always resort to telnet :)
      - mnx 11y ago
        Well... until http 1.x starts being deprecated :)
    - dbbolton 11y ago
      >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 https://packages.debian.org/stretch/midori The latest version on Midori's site is 0.5.9: http://midori-browser.org/download/debian/ http://midori-browser.org/download/debian/
mgiuca 11y ago
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 http://crbug.com/500922#c6.
- cactusface 11y ago
  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.
  - mgiuca 11y ago
    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.
    - cactusface 11y ago
      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).

laumars 11y ago

> 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 :)

qwe123 11y ago
>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".
- laumars 11y ago
  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.
  - fao_ 11y ago
    And as a last resort, one could always resort to telnet :)
    - mnx 11y ago
      Well... until http 1.x starts being deprecated :)
  - dbbolton 11y ago
    >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 https://packages.debian.org/stretch/midori The latest version on Midori's site is 0.5.9: http://midori-browser.org/download/debian/ http://midori-browser.org/download/debian/

mgiuca 11y ago

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 http://crbug.com/500922#c6.

cactusface 11y ago
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.
- mgiuca 11y ago
  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.
  - cactusface 11y ago
    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).