New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 64 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Opt-out Chrome Hotword Shared Module

Reported by yy.y.ja...@gmail.com, May 23 2015 Back to list

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36

Steps to reproduce the problem:
1. Start chromium on-line

What is the expected behavior?
chromium does not download Chrome Hotword Shared Module if requested via command line/compile-time default/etc.

What went wrong?
chromium downloads the module immediately after the machine is on-line

Did this work before? N/A 

Chrome version: 43.0.2357.65  Channel: stable
OS Version: 
Flash Version:
 
Labels: -Cr-Enterprise Cr-UI-Browser-Search-Voice
Adjusting labels to re-route the right group of people.
Cc: mgiuca@chromium.org
Labels: -OS-Linux OS-All
Owner: amistry@chromium.org
Status: Assigned (was: NULL)
It would have been nice to mention this is from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 9 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f269d3b548203e217e8c0080c2e22e7ae3efb51e

commit f269d3b548203e217e8c0080c2e22e7ae3efb51e
Author: amistry <amistry@chromium.org>
Date: Tue Jun 09 19:18:39 2015

Add build flag to disable hotwording.

Hotwording downloads a shared module from the web store containing a NaCl module. There is a desire to build and distribute Chromium without this happening. This change adds an "enable_hotwording" build flag that is enabled by default, but can be disabled at compile time.

BUG= 491435 

Review URL: https://codereview.chromium.org/1160243004

Cr-Commit-Position: refs/heads/master@{#333548}

[modify] http://crrev.com/f269d3b548203e217e8c0080c2e22e7ae3efb51e/build/common.gypi
[modify] http://crrev.com/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/browser/BUILD.gn
[modify] http://crrev.com/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/browser/search/hotword_service.cc
[modify] http://crrev.com/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/browser/search/hotword_service_unittest.cc
[modify] http://crrev.com/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/chrome_browser.gypi

Status: Fixed (was: NULL)
A build-time flag has been added for anyone that wants to build chromium without hotwording. To disable hotwording, pass "enable_hotwording=0" in your GYP_DEFINES, or "enable_hotwording = false" in your GN config. This will prevent the shared module from being downloaded, and also prevent the option from showing up in settings.

Comment 6 by steffz...@gmail.com, Jun 16 2015

May I ask why this extensions is hidden from the extension list at chrome://extensions/ , although the page chrome://voicesearch/ shows it as an enabled  extension? I suggest that sensitive functionality intended to process data from the surroundings (sound input,video input, etc.) should be presented in an open and transparent way, with easy to find controls.

Comment 7 by mr.ana...@gmail.com, Jun 16 2015

>May I ask why this extensions is hidden from the extension list at chrome://extensions/ , although the page chrome://voicesearch/ shows it as an enabled  extension?

This weirds me out as well. The whole behaviour of hotword is pretty conspicuous: Opt-in default, downloading a binary blob without notification, extension being hidden, ability to record audio .. I almost fell out of my chair when I saw that. Great strategy to erode trust of any user who is even slightly concerned with security (which, I assume, a lot of chromium users are). 

Here's a discussion on hacker news concerning the issue (mostly focused on debian): https://news.ycombinator.com/item?id=9724409
Is there a good reason for keeping this proprietary like code licensed from a third party? Chromium has plenty of open-source code based on Google services, so taking the Android approach for this one is out of character. It implies that there's some secret technology to hide which actually makes reverse engineering it a lot more interesting.

It's also odd that it's downloaded at runtime rather than simply being shipped with Chrome like the EME and Flash plugins, which both work in Chromium but are explicitly opt-in.
it's probably closed source for patent reasons (thanks Nuance)
I've written a detailed answer to these questions on the other bug ( Issue 500922 , see Comment 6).

#6: We do not show built-in extensions in chrome://extensions because they are implementation details of Chrome. It would be confusing to users to see things there that they did not install (just like there is no list of C++ modules in the Chrome interface; we consider these extensions to be just another bit of the Chrome code).

#7: This is not "opt-in default". If you do not explicitly opt in (using the "Enable Ok Google" setting in chrome://settings), then this module will not run.

#8, #9: It's proprietary simply because it involves some Google technology (the hotword detection algorithm itself) which we could not open source. We had a choice to either bake it into Google Chrome (and take it out of Chromium), or provide it as a separate NaCl module. Since our policy is to put as little proprietary code in Google Chrome as possible (to keep it almost identical to Chromium), we chose the latter. Since the module does not run unless you opt in, I don't think it's cause for alarm.

Comment 11 by Deleted ...@, Jun 18 2015

Preceding "Enable Ok Google" a preferred step would be to have "Install Ok Google". If the software downloads and installs a closed-source binary, how do we know when it runs and when it doesn't?

I've "opted out" in the Chromium settings (unticked the "Ok Google" setting), but still chrome://voicesearch shows that the extension and module are both ENABLED. Additionally all audio recording options are set to "allow" on that page, even though I have not given the browser any permissions to do that.

The proper opt-in would be to make the module an optional download for those who want to use it.

Comment 12 by Deleted ...@, Jun 18 2015

As a web developer, I like chrome. As a private person, in uninstalled it. You might call it a feature or a core extension, most people consider this spyware.
hotword detection isn't a required feature for a functioning browser. I may install a binary blob to get better 3D acceleration for a linux distribution, for instance, and I accept the risks to get those required features. Opt-out vs opt-in.

Saying the module "does not run unless you opt in" is immaterial and misses the point entirely. Once the blob is on the system the security risks have been increased; an increase that is unnecessary if one has no reason to use the feature(s).
#11: "If the software downloads and installs a closed-source binary, how do we know when it runs and when it doesn't?"

Because the open source software has complete control of when the binary runs. You can look in the source code to see when it decides to start up and shut down the hotword module (I gave instructions on how to do that in the other bug).

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.

#13: "Once the blob is on the system the security risks have been increased". From our perspective, the blob is just another part of the Chrome codebase (just with a weird delivery mechanism). You could make a similar claim for any feature of Chrome, "it shouldn't be installed unless I ask for it." But that's not how software works. We don't download individual features of an application on demand. It's your choice whether to enable a given feature. But users generally don't get a choice of *which* features are downloaded when you download software. That's just never been the way software has worked.

Comment 15 by Deleted ...@, Jun 19 2015

"Providing an extra step to install the module would be unnecessary friction for our users."

What absolute bull pucky!  As soon as I'm done with this browsing session, Chrome is being deleted from all my devices.  No damn way am I going to allow spyware on any of my devices.  If I want someone to use the microphones on my machines, I want to specifically install software to do so.  And installing and activating it without telling users is just plain evil.

"DO NO EVIL" what a farce.


Comment 16 by only...@gmail.com, Jun 19 2015

I'm disturbed by this issue and by how integration of non-free component which is downloaded without consent is being justifying. This is betrayal of trust, plain and simple. I would expect apologies and promises that such thing will never happen again... It should come without saying that there shall be an agenda to reduce (and potentially eliminate) non-free stuff and completely replace it with free libre and open source. Proprietary components are unnecessary and harmful. There should be no discussion how "safely" it is activated. Just remove it entirely. What a shame!

Comment 17 by Deleted ...@, Jun 19 2015

"It's your choice whether to enable a given feature. But users generally don't get a choice of *which* features are downloaded when you download software. That's just never been the way software has worked."

I'm not sure you thought this bit all the way through. Literally the entire purpose of an extension/plug-in system is to allow end users to download individual features of an application on demand, yet being able to install individual features on demand has apparently "never been the way software has worked"? So you're telling me that the software you developed to work that way, doesn't work that way because you want to abuse the feature to stealth install sketchy packages? I'd normally not say anything so cliche, but that is downright doublethink.
#17: Please see  http://crbug.com/500922#c6 , point 3.

From a user perspective, this is not an extension/plugin. This is a core feature of Chrome. That it was implemented as an extension is an implementation detail.

Comment 19 by Deleted ...@, Jun 19 2015

A user cannot have a perspective on something that no user was implicitly informed about. If you implement a "core feature" as an extension, it is still an extension all the same and should be treated as every other extension is.

Implement it to the core or allow users to remove the module.
#18 keep it in Chrome then. This should not be implemented in Chromium. This breaks a lot of Linux distros' rules around open source software (Fedora for example).
Surely we've all had experiences with software where we thought we had disabled some feature, but it turned out we were mistaken. That's why "installed but disabled" is not good enough.

Similarly, we've all sat down at a new workstation and started doing stuff, without first pulling over all of our settings, and disabling features that we want disabled. That's why "installed by default" is not acceptable.

Especially for a feature like this, which is capable of effectively bugging our homes and offices, and sending the data someplace beyond our control. Just because this capability is currently being used in good faith doesn't mean it will continue to be used in good faith in the future.

Comment 22 by i...@mir2.org, Jun 19 2015

There is a lot of wrong criticism here. Google wanted to include a particularly proprietary technology to Chrome. Instead of baking directly it into the code they spend time and resources to develop it as a separated component that runs in a tight sandbox. I suppose it was just easier for them to download it when browser starts the same way as browser checks for updates. Otherwise it behaves the same way as many other opt-in features such as location sharing yet nobody complained that location-related code should not be downloaded unless the user opt-in.

Now, with all criticism here Google may have learned that from a PR point of view it would better next time to bake in the code directly into Google and run it with full privileges. Nobody would then criticize them even if that would be a bad solution from security point of view.


So much missing the point... It's fine to make it an extension. It's fine to make it a transparent extension, it's fine to have it be an opt-in feature that is implemented as an extension. It's not fine to download it *before* the user chose it. That's the only problem here! If it waits until I enable it and then says "To save your disk space this component is not downloaded by default, thanks for enabling it, please wait while Chrome fetches it." Even though it's totally not really to save disk space but rather to save a panic and PR incident when people find this thing they never wanted sitting on their local computer.
Labels: Restrict-AddIssueComment-EditIssue
The bug tracker is for tracking technical development work, not debating policy or, even more, ranting about how Google is evil and you're deleting all Google software from your devices.

Closing to additional comments.
Project Member

Comment 25 by bugdroid1@chromium.org, Jun 24 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a38832be9fef269ae1f3a191a9b69432aaf680c4

commit a38832be9fef269ae1f3a191a9b69432aaf680c4
Author: mgiuca <mgiuca@chromium.org>
Date: Wed Jun 24 01:25:14 2015

Remove hotword installation code at compile time if hotwording disabled.

If enable_hotwording is false, the code to download/install the hotword
shared module is compiled out.

(This should not change behaviour; it was already disabled at run-time,
this just removes the installation code from the build.)

BUG= 491435 

Review URL: https://codereview.chromium.org/1201163002

Cr-Commit-Position: refs/heads/master@{#335843}

[modify] http://crrev.com/a38832be9fef269ae1f3a191a9b69432aaf680c4/chrome/browser/extensions/external_component_loader.cc

Project Member

Comment 26 by bugdroid1@chromium.org, Jun 24 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1d40cc1e1c6dc12d350bf0da668f2ddcac4f5976

commit 1d40cc1e1c6dc12d350bf0da668f2ddcac4f5976
Author: mgiuca <mgiuca@chromium.org>
Date: Wed Jun 24 03:55:01 2015

Revert of Remove hotword installation code at compile time if hotwording disabled. (patchset #1 id:1 of https://codereview.chromium.org/1201163002/)

Reason for revert:
This CL added a compile-time check for ENABLE_HOTWORDING in a file where
ENABLE_HOTWORDING is never defined, thus the hotword shared module would
never be downloaded.

Original issue's description:
> Remove hotword installation code at compile time if hotwording disabled.
>
> If enable_hotwording is false, the code to download/install the hotword
> shared module is compiled out.
>
> (This should not change behaviour; it was already disabled at run-time,
> this just removes the installation code from the build.)
>
> BUG= 491435 
>
> Committed: https://crrev.com/a38832be9fef269ae1f3a191a9b69432aaf680c4
> Cr-Commit-Position: refs/heads/master@{#335843}

TBR=benwells@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 491435 

Review URL: https://codereview.chromium.org/1199343003

Cr-Commit-Position: refs/heads/master@{#335869}

[modify] http://crrev.com/1d40cc1e1c6dc12d350bf0da668f2ddcac4f5976/chrome/browser/extensions/external_component_loader.cc

Project Member

Comment 27 by bugdroid1@chromium.org, Jun 29 2015

Labels: merge-merged-2403
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3

commit ac2b37ff8ca0f3015c0163bc91b456e33b7287f3
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 01:55:47 2015

Add build flag to disable hotwording.

Hotwording downloads a shared module from the web store containing a NaCl module. There is a desire to build and distribute Chromium without this happening. This change adds an "enable_hotwording" build flag that is enabled by default, but can be disabled at compile time.

BUG= 491435 

Review URL: https://codereview.chromium.org/1160243004

Cr-Commit-Position: refs/heads/master@{#333548}
(cherry picked from commit f269d3b548203e217e8c0080c2e22e7ae3efb51e)

Resolved merge conflict: Remove the body of
IsHotwordAllowedDisabledFieldTrial and IsHotwordAllowedInvalidFieldTrial
when ENABLE_HOTWORDING is false. These tests were deleted before the
upstream patch landed.

(Merge approval on  http://crbug.com/500922#c69 )
TBR=thestig@chromium.org,scottmg@chromium.org

Review URL: https://codereview.chromium.org/1218693004.

Cr-Commit-Position: refs/branch-heads/2403@{#412}
Cr-Branched-From: f54b8097a9c45ed4ad308133d49f05325d6c5070-refs/heads/master@{#330231}

[modify] http://crrev.com/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3/build/common.gypi
[modify] http://crrev.com/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3/chrome/browser/BUILD.gn
[modify] http://crrev.com/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3/chrome/browser/search/hotword_service.cc
[modify] http://crrev.com/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3/chrome/browser/search/hotword_service_unittest.cc
[modify] http://crrev.com/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3/chrome/chrome_browser.gypi

Project Member

Comment 28 by bugdroid1@chromium.org, Jun 29 2015

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/ac2b37ff8ca0f3015c0163bc91b456e33b7287f3

commit ac2b37ff8ca0f3015c0163bc91b456e33b7287f3
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 01:55:47 2015

Sign in to add a comment