A Debian bug report indicated on Tuesday that the most recent version of the Chromium browser downloaded a "Chrome Hotword Shared Module" extension as a binary without source code.
Further investigation revealed that the extension was linked to "Ok Google", a voice search and actions service that uses the computer's microphone to run commands when the user speaks a command followed by instructions.
The company used the feature on Android and other mobile devices for some time already but has moved it to the Chrome web browser as well in the meantime.
The main idea behind the feature is to give users options to use their voice to run commands instead on devices supporting the feature.
Google is criticized for dropping the code for several reasons:
You can check the chrome://voicesearch page in Chrome or Chromium to find out whether the feature is enabled on your end.
The most important values on the page are "audio capture allowed", "hotword search enabled", "always-on hotword search enabled" and "hotword audio logging enabled".
Google provides two options to disable OK Google currently. The first is to pass the parameter enable_hotwording=0 when Chrome is build, the second to make sure the feature is disabled on chrome://settings.
There you need to find Search and make sure that "Enable "Ok Google" to start a voice search" is not checked.
A Google employee responded to several of the complaints that users made about the dropping of the binary.
Hotword activates and records without asking for user permission
Google states that the extension, while installed by default without option to opt out or uninstall it, won't run by default as it needs to be enabled explicitly by the user first.
First and foremost, while we do download the hotword module on startup, we *do not* activate it unless you opt in to hotwording. If you go into "chrome://settings", you will see a checkbox "Enable "Ok Google" to start a voice search". This should be unchecked by default, and if you do not check it, the hotword module will not be started.
It also mentions that it does not see a difference between downloading the module (without running it) and not download it.
Providing an extra step to install the module would be unnecessary friction for our users. There is literally no difference between downloading the module (without running it), and not downloading it, except a tiny amount of bandwidth saved. There is no difference from a privacy or security standpoint, because unless we run it, it can't do anything, no matter what behaviour it might contain within.
That's actually something where the employee errs. What the employee fails to take into account is the trust factor. While it may very well be the case that there is no difference from a privacy or security standpoint, we only have Google's confirmation that this is the case but no option to verify that claim due to the binary nature of the code.
Dropping the code automatically may be the user-friendly way of deploying OK Google on user systems but it is at the same time invasive, suspicious and a trust issue.
Not showing the extension in the extension list
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 (it is an implementation detail that they are separate extensions). 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.
Now You: What's your take on this?Advertisement
Ghacks is a technology news blog that was founded in 2005 by Martin Brinkmann. It has since then become one of the most popular tech news sites on the Internet with five authors and regular contributions from freelance writers.