Update: What’s that? Oh, just the smell of change. After initially standing firm on its implementation of the hotwording module and proprietary Google extension being automatically downloaded in new installations of the Chromium open source browser, a wave of criticism has led to the team pulling it out of Chromium 45 and onwards. The module that manages whether the hotword listening extension is enabled will be “disabled by default” and the proprietary technology that actually listens for “Ok Google” will not download. A member of the team says simply:
In light of this issue, we have decided to remove the hotwording component entirely from Chromium. As it is not open source, it does not belong in the open source browser.
The original story continues below.
It all started with a blinking LED light. Ofer Zelig wrote on his blog today about an odd case where the LED light on his computer, that turns on whenever the microphone or camera is activated, seemed to blink every few seconds or so while he was working on his PC. He investigated in the Windows Task Manager to look for any process that might be to blame – no dice. He shut down some suspicious processes that might have been causing it and says he didn’t have any malware installed, but still to no avail. Turns out, the culprit was none other than Google’s Chrome browser…
Don’t worry, though, there’s really no significant privacy crisis to be found here. Google isn’t activating your microphone and/or camera without your explicit permission so that it can funnel pictures of you in your home to the NSA in order to build its facial recognition database. What’s really going on here is more nuanced, and suggests that Google isn’t as transparent with users of its browser as it could and should be.
So, why exactly was Zelig taken by surprise to see his microphone and/or camera activated by Chrome? You’d think with the browser’s granular permission controls and just-in-time permission requests that ask for permissions only when it need them, that he would know they were going to turn on before they did. But the browser did in fact have his permission – visiting chrome://settings we see…
Boom, there’s the answer. “Ok Google” voice commands were enabled, meaning any time he opens a new tab or visits Google.com from Chrome, the microphone turns on so it can listen for the “Ok Google” command to begin a search. This is opt-in, and Zelig had to have gone through the hotword training and privacy confirmation to end up with this setting checked.
This story could end here, but it turns out many others noticed this and other conspicuous behavior on Chrome’s part regarding hardware access, which led to interesting discussions in the Chromium issues tracker. The extension that powers Chrome’s voice search is not only downloaded automatically upon installing and launching the browser, but it’s also downloaded automatically in the Chromium open source version of the browser; the extension isn’t listed in the chrome://extensions UI which acts like a hub where users go to enable, disable, and delete extensions; also, information pages inside the browser about the voice search functionality are incredibly vague as to whether or not it’s enabled.
Let’s break that all down. Google Chrome is based off an open source browser called Chromium. Chromium is not a Google product, meaning the company doesn’t own the rights to it or directly distribute it – anyone can remix it and make their own browser. Much of the Chrome team – along with thousands of individuals from around the world – contributes code to the Chromium browser to make it better. Google then takes that browser, repackages it with its own proprietary technologies and services layered on top, and distributes it from its own website. But both in Google’s version of the browser and in Chromium, two special tools are installed – a hotword module that listens for “Ok Google” and an extension that manages whether or not the hotword module is activated (i.e. listening).
Yes, the open source version of the browser, which is not owned by Google, automatically installs proprietary Google technology for both managing whether the microphone is enabled and listening for hotwords. In response Google has essentially said, yes, we’ve baked it into the open source browser, but it’s not our job to ensure others distributing their own version of the browser disable it (emphasis mine):
Since a lot of the discussion is centered around Chromium on Linux, I want to address the concern that Chromium is entirely open source and yet it downloads a proprietary module. The key here is that Chromium is not a Google product (we do not directly distribute it, or make any guarantees with respect to compliance with various open source policies). Our primary focus is getting code ready for Google Chrome. If a third party (such as Debian) destributes it, it is their responsibility to enforce their own policy. And I see that they have now done that (as of 43.0.2357.81-1) by disabling the hotword module.
The next concern I mentioned is regarding visibility of voice search in Chrome. Users of the browser are trained to visit chrome://extensions to view and modify the extensions they’ve installed, and yet the extension managing “Ok Google” voice search isn’t visible unless the end-user enables visibility of “component extensions” using a command line string. The way that end-users disable it is by toggling off the “Enable ‘Ok Google’ to start a voice search” option flag in chrome://settings. Here’s what the company says about that (emphasis mine):
We call extensions that are built into or automatically downloaded by Chrome “component extensions” and we do not show them in the extension list by design. This is because as I was saying above, we consider component extensions to be part of the basic Chrome experience… The chrome://extensions UI is a place for users to manage the extensions that they have installed themselves; it would be confusing if that list was pre-populated with bits and pieces that are a core part of the browser.
Finally, many users dug into a page in Chrome about voice search, found at chrome://voicesearch, as evidence that the browser was enabling the tool automatically. The page looks like this:
I’ve pointed out certain columns in the image above where it seems to indicate that voice search has permissions to access and capture microphone audio as well as perform searches; many in the forums say that the rows for “Microphone” and “Audio Capture Allowed” were both toggled yes without enabling voice search. What’s going on here, according to Google, is that the browser has detected a microphone and that “for historical reasons,” the “Audio Capture Allowed” row is always set to “Yes.” These don’t, however, mean the microphone is actually being used or that the browser even has permission to use it. Here’s the full rundown:
NaCl Enabled: Is NaCl available at all? (Nothing to do with Hotword module.)
Microphone: Is a microphone detected? (Does not mean it is being used.)
Audio Capture Allowed: Can Chromium use the mic? (This is there for historical reasons, it’s always “Yes”.)
Hotword Search Enabled: Has the user checked the “Enable “Ok Google” to start a voice search” checkbox in Settings.
Always-on Hotword Search Enabled: Is the hotword module running at all times (not just when on google.com or New Tab Page)? (Only on ChromeOS, unless you change flags flags.)
Hotword Audio Logging Enabled: Is the user signed in, and if so, have they gone through the hotword training and privacy confirmation on Android or ChromeOS? (Required to use Always-on hotword, and only logging if Always-on is turned on.)
Extension State: “ENABLED” means the extension *can run*. It does not mean the extension is currently running. (All extensions are enabled unless explicitly disabled.)
In summary, what’s going on here is more misunderstanding than cause for concern. Google has been moving in the right directions in terms of empowering its users through strengthened privacy controls, adding new granular permissions controls in Android M as well as already having them in Chrome. But with anxiety at an all time high due to the publication of information surrounding United States secret data collection programs, and Google’s thirst for information about its users to target ads against them (still its biggest money maker), it seems like ambiguity around how it treats access to the microphone for its own search engine might be something worth addressing. A couple suggestions from one user in the forum, #4 addressing the extension not appearing in the user-facing extensions UI:
I think a lot of concerns could be mitigated by:
1. Chromium only downloading the extension when the user enables it, not on first connect.
2. Having the module ask for permission to record audio like any other extension would (but then I guess that goes deeper into how core modules are designed)
3. Clean up the chrome://voicesearch page and rename (or elaborate on) the flags so it’s clearer what the module is actually doing at that setting.
4. Adding a “show components extension” checkbox when enabling developer mode without having to set “–show-component-extension-options”
We agree with those.
FTC: We use income earning auto affiliate links. More.
Comments