Google Chrome hotword privacy concerns - What and how

Updated: July 13, 2015

If there's one thing the would-be tech media does well, it is to jump onto the hype wagon, monger fear, and blast off unverified, incomplete stories related to privacy and security. One such story relates to the capability present in Google Chrome and Chromium, which allows you to use the 'OK, Google' hotword in new tabs and Google search pages.

This is nothing new, but the story exploded when a Debian user reported a new, closed-source blob in his download of Chromium 43. This caused the wider community to go crazy, accuse Google of working hand in hand with spy agencies, a variety of orifices were violated, and people moved on to other browsers. Now, one thing that the tech media does not do well is actually HELP people fix the problem. So maybe Chrome or Chromium are spying on you. Is there a way to mitigate this? Let me show you.


First thing

The most basic of things you need to do is ask yourselves: if you do NOT trust Google, then why the hell are you using its products? Why do you use Chrome if you fear the company is trying to profile your behavior, sell you ads and whatnot? Your actions speak louder than words. If you truly fear for your privacy and security, you should not be using the browser.

For that matter, if you don't trust Google, you should not be using any Google product. But then, people are perfectly happy to have their personal data collected on smartphones, they have a rich search history in their browser, because they are actually logged into Google while using the browser, don't ask me why, and they also exchange sensitive private info using email, chat and similar. That's the reality check. If you think your browser will be abused because it has a new functionality, you are ignoring everything else.

Now, the technical details

All right. So, if we look at Chrome, in its settings window, under Search, you have the option to enable the voice functionality. It is disabled by default.

Settings, OK Google

For more details, you may want to navigate to chrome://voicesearch. Here, you can actually see additional technical details regarding the functionality. This is true for both Windows and Linux, and I tested and checked what gives both in Windows 7 as well as CentOS 7, which isn't the obvious choice, but I wanted to give you more than a single source for reference. Two locales, too, just to be on the safe side.

Functionality, enabled or disabled?

If you toggle the voice search on or off, the Microphone yes/no status will reliably change on Windows, but on Linux, it may not reflect the state of the functionality. However, this is slightly misleading, as we will discuss this in a few seconds. Audio capture and NaCl will always remain enabled. Hotword Search Enabled value does not change, regardless of what option you select. The status of the shared library and the extension does not change, regardless of what option you select.

Voice search enabled

Voice search disabled

And in our CentOS 7 box, we have:

Linux voice search

Linux voice search more

There's more useful information here that we need to look at. As mentioned, voicesearch seems to be offered as an extension, plus there's a shared module, too. Indeed, it is the shared closed source binary blob that caused the storm. But let's look at the extension.


The path on Windows points to Program Files, and in Linux, it is located under /opt, as you can see in the screenshot above. However, very strangely, on both platforms, these paths are invalid. There's nothing there.

Extension Id        nbpagnldghgfoolbancepceaanlmhfmd
Extension Version
Extension Path      C:\Program Files (x86)\Google\Chrome\
Extension State     ENABLED

Extension does not exist

Even if you search system wide, like for instance on Linux, you won't find anything except the shared module piece, which is located inside the user profile inside the user's home folder or directory:

find / -name \*hotword\*

Moreover, the extension does not show in the list of extensions, which is another complaint that Chrome and Chromium users had. If something is supposed to be an extension, then it ought to be visible, and the users should have control over its state.

However, if you want to see the extension, you can start Google Chrome with the --show-component-extension-options flag from the command line, and then you will be able to see the full listing, including voice search. You cannot enable, disable or uninstall the extension in any way, another source of frustration and fear.

Hidden extensions

Shared module

The shared module is indeed located where it says, inside the user profile. The path is somewhat convoluted. Both on Windows and Linux, it comes with the same name and extension (nexe). Basically, the shared module includes two files, one which is data, which reads various language configurations and other settings from hotword configuration files.

Shared Module Id        lccekmodgklaepjeofjdjpbminllajkg
Shared Module Version
Shared Module Path      C:\Users\...\AppData\Local\Google\
                        Chrome\User Data\Default\Extensions\
Shared Module State     ENABLED

Nexe file, disable

The configurations come in a series of region/language-specific files, plus a manifest, all in a very ugly JSON format. There's nothing special about this. Standard Chrome extension stuff. Behold:

"description": "Support files for Chrome Hotwording.",
"key": "...MIIBIjB",
"manifest_version": 2,
"minimum_chrome_version": "39",
"name": "Chrome Hotword Shared Module",
"platforms": [ {
"lang": "de",
"nacl_arch": "arm",
"sub_package_path": "_platform_specific/arm_de/"
}, {

The nexe file is indeed a binary, and it is stripped of debug symbols:

file ./.config/google-chrome.../x86-64_en-us/hotword-x86-64.nexe
./.config/google-chrome.../x86-64_en-us/hotword-x86-64.nexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0x555dd22448ca6d88d6311092340a8b92309865f5, stripped

If you want to trace the execution of Chrome and see what happens when you toggle the voice search settings, as well as use the hotword, then you cannot do it without using yet another hidden flag for Chrome. By default:

strace -f -s512 -o /tmp/chrome /opt/google/chrome/chrome
The setuid sandbox is not running as root. Common causes:
* An unprivileged process using ptrace on it, like a debugger.
* A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

You will need to run the program with --disable-setuid-sandbox. However, there's nothing really useful or interesting in the execution, and the button clicks and the checkbox state change does not reflect in system calls or library calls. It's all internal functions. You may think this is suspicious, but it is not. This is perfectly fine.

Mini summary

So what we have at the moment is the following:

Voicesearch microphone state changes when you toggle 'OK, Google' hotword on/off in the system settings, but it is not the only mechanism that can affect this settings. The other two audio settings are unaffected. The hotword, the extension and the share module will always read as enabled, even when they are not used or toggled inside the browser settings menu.

The functionality is listed as an extension, but the said extension does not exist on the filesystem. It does show in the list, when Chrome is invoked with the special flag.

The shared module has the same name on Windows and Linux, and it resides inside the user's profile. It is stripped of debug symbols, and when traced, it does not show any activity related to the voicesearch functionality.

How to disable voicesearch

Now, if you test your browser and microphone, you will see that 'OK, Google' works when enabled and does not work when disabled. Good. You can also always use the mic icon in Google search to perform a voice search REGARDLESS of the above. In turn, Chrome will ask you if you want to permit the use of your microphone:

Plugins asks

If you want to completely disable the browser's ability to listen, then you will want to yank the shared module away. You can change its permissions or move the files into another folder, or even delete them:

chmod 000 ~/.config/.../x86-64_en-us/hotword-x86-64.nexe

If you do this, then you will see the following behavior. In Windows, the status of the microphone will not change in the chrome://voicesearch page, unless you check the box on or off. Even if the hotword file is not present, the browser will function without any errors, and it will not throw any exceptions. However, the voice search WILL NOT work. Moving, deleting or de-permissioning the hotword executable definitely works.

Voice search disabled

In Linux, the state of the microphone will change to No if the shared module is missing, and you will not be able to use the voice search with hotwords - unless you explicitly click the audio button in Google search pages.

The state of the shared module and the extension will read ENABLED, on both platforms, even if you delete the files. However, its type will change from a known, recognizable platform to one that is not defined:

Platform detected

Platform undefined

Now, since we deleted the files, they could in theory come back with the next browser upgrade, so this is something you need to pay attention to. But again, don't use a product you don't trust. If you are really that paranoid about what Google is doing, then you should not mess with Chrome. In fact, the whole purpose of this exercise was to show you that things can be done, things aren't as sinister as they initially appear. You do have the ability to control your system, and you understand what the browser does now.


Google is definitely not helping itself by offering so many conflicting messages in one package. Enabled, disabled, yes, no, there are half a dozen permutations to this functionality, none of which really reflect whether the technology is working and how it's working. But it's rather simple. The GUI settings menu governs the state, really. And if you are really paranoid, you can remove the shared module, and the functionality will be gone no matter what you select in the menu.

I can understand the outrage of Chromium users, but the foundation for their fear is unfounded. Again, Google could have helped itself by making the whole hotword attempt more transparent and easier to navigate and tweak. But there's nothing to indicate any malice. Just wonky coding. Of course, there's the bigger, fundamental question of trust. Here, my advice is rather simple. Do not use the software if you don't feel safe with it. True for Chrome or any other program. Bitching does not help. Dead simple.

There. We're done. This isn't as ugly as the GWX thing Microsoft pulled on its users, but it comes close. Then, we can never really know what this binary blob might do one day, and we have no control over it. Perhaps that's the real concern. But if you must, delete the files and problem solved. The reason why I wrote this article. To give you the choice to decide what's best for you. Oh, and Google did pull the extension out of the Chromium builds, so there. No more worries. Until the next time.