Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 49 users
Status: Fixed
Owner:
Closed: Jun 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Mac
Pri: 2
Type: Bug



Sign in to add a comment
Hotword behaviour in chromium v43 (binary blob download)
Reported by mr.ana...@gmail.com, Jun 16 2015 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Steps to reproduce the problem:
1. Download Chrome 43.x.x.x
2. Go offline
3. Install Chromium
4. Open extensions folder
5. Go online
6. See hotword extension with binary blob silently installing itself

What is the expected behavior?
Not quietly downloading and installing an extension that includes a binary blob (!) without: 

a) asking for user permission
b) any sort of notification
c) the extension being shown in the extension list

What went wrong?
I find the new behaviour of hotword (from v43 on) extremely conspicuous: Opt-in default, downloading a binary blob without notification, extension not being shown in extension list (only at chrome://voicesearch/), 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). 

Did this work before? N/A 

Chrome version: 43.0.2357.124  Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 18.0 r0

Here's a discussion on hacker news concerning the issue (mostly focused on debian): https://news.ycombinator.com/item?id=9724409

 
Comment 1 Deleted
Labels: Cr-UI-Browser-Search-Voice
Comment 3 by mgiuca@chromium.org, Jun 17 2015
Cc: amistry@chromium.org
Labels: Proj-Ares OS-Linux
Owner: mgiuca@chromium.org
Status: Assigned
I'll look into this.
Comment 5 by mr.ana...@gmail.com, Jun 17 2015
@phajdan.jr@chromium.org 

Thanks for posting those, I'm sorry if this ticket is somewhat redundant, just thought since the latter ticket has been closed with 'adding a opt-out flag as solution" that hotwords behaviour should be discussed more in general (concerning the points above).
Comment 6 by mgiuca@chromium.org, Jun 17 2015
Status: WontFix
Thanks for bringing this issue to our attention. I have been following this on Hacker news [1] and the Debian bug tracker [2]. I'd like to clear up a couple of misconceptions.

I think there are a number of separate issues here so I'll address each one.

* 1. Hotword activates / records audio without asking for user permission.

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.

You don't have to take my word for it. Starting and stopping the hotword module is controlled by some open source code in Chromium itself [3], so while you cannot see the code inside the module, you can trust that it is not actually going to run unless you opt in.

* 2. Downloading a binary blob into an open source application.

The significance of this depends on whether you're running Google Chrome (the official distribution) or Chromium. Now, you've reported in your "steps to reproduce" using Chrome on Mac.

If we're talking about Chrome: Google Chrome (as opposed to Chromium) is not open source. It contains various bits of proprietary binary code, and always has. Therefore, whether it downloads the hotword module from the web store, or includes it in the distribution, is irrelevant from a trust standpoint. From our standpoint, the fact that the hotword module is a separate extension (rather than built in to the browser) is an implementation detail.

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. We have also made changes from Chromium 45 onwards to make it easier for third party distributors to disable hotwording (see  Issue 491435 ).

Another key point is that the binary blob is not a native executable or library. It is a NaCl module, and therefore subject to the full sandbox of the NaCl platform. The hotword module has the same privileges as any website (except that it automatically has access to the microphone).

* 3. 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.

I hope this explanation is satisfactory. I am closing this as WontFix because it is already an opt-in feature, and Debian has already removed the component in their distribution of Chromium [2].

[1] https://news.ycombinator.com/item?id=9724409
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
[3] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/hotword/state_manager.js
Comment 7 by mr.ana...@gmail.com, Jun 18 2015
Thanks a lot for the detailed write up. The "chrome" in my steps to reproduce was a typo, this type of behaviour I'd deem normal for Google Chrome but irritated me to be bundled up by default inside Chromium. 

Thanks for linking [3], just looking into that.

As for component extensions:
I understand the logic behind that, but at least the *option to have them being shown in the extension list  (e.g. when enabling Developer Mode, in a special color) might help resolve some fears for users who are unfamiliar with component extensions. Just the fact of finding an unlisted extension was disconcerting to me, especially one that automatically downloads itself. 

>The hotword module has the same privileges as any website (except that it automatically has access to the microphone).

The automatic access is something I'm still not really happy about, despite it being a core component, why not have it ask for permission like any other extension?


> but at least the *option to have them being shown in the extension list

There is, but it's behind a command line option, --show-component-extension-options. Also, if the component extension is running, it'll show up in the "Extensions" panel in chrome://inspect.

Comment 9 by mr.ana...@gmail.com, Jun 18 2015
>There is, but it's behind a command line option, --show-component-extension-options. Also, if the component extension is running, it'll show up in the "Extensions" panel in chrome://inspect.

Good to know, thanks. 
Comment 10 by Deleted ...@, Jun 18 2015
^ Censorship? 
I don't know what that image is in #10; it's possible the uploader deleted their own image.
#13: This has nothing to do with that story.
>#13: This has nothing to do with that story.

Indeed. And this is not about throwing around allegations, rather to discuss the behaviour of a module that might raise security / privacy concerns. 

Comment 16 by Deleted ...@, Jun 19 2015
"so while you cannot see the code inside the module, you can trust that it is not actually going to run unless you opt in."

Yep, trusting binary blobs to do what we're told they do. This is what free software is all about.
Comment 17 by mig3...@gmail.com, Jun 21 2015
>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.

BS. Module was activated with disabled option. Open chrome://voicesearch/. State:enabled. 
#17: Same on my machine. Enabled by default without modifying any settings. 
 
Comment 19 Deleted
Comment 20 Deleted
Comment 21 by Deleted ...@, Jun 21 2015
same here can confirm

NaCl Enabled	Yes
Microphone	Yes
Audio Capture Allowed	Yes
[...]
Hotword Search Enabled	No
Always-on Hotword Search Enabled	No
Hotword Audio Logging Enabled	No
[...]
Extension State	ENABLED
A number of people are looking in chrome://voicesearch to check the status of the module. This page is getting misinterpreted quite a bit, so let me give a brief rundown of what all those flags mean:

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

Extensions:
"nbpagnldghgfoolbancepceaanlmhfmd" is an open source component extension; its source code can be found in https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/hotword. If Chromium is built from source, it uses the internal version of the extension (it does not download from the Web Store). This extension has the code that manages whether the hotword module is activated or not (which I pointed at in #6).

"lccekmodgklaepjeofjdjpbminllajkg" is the proprietary NaCl extension which is downloaded from the Web Store. This module listens for "Ok Google", but it only runs when the other extension tells it to run (which is only if you opt in). Again, "ENABLED" does not mean it is necessarily running.

The important one here is "Hotword Search Enabled". If that says No, then the proprietary NaCl module is not running. If it says Yes, the module can run (but it only runs when you are on google.com or New Tab Page). For example, the user in #21 is *not* currently running the NaCl module.

Hope this clears things up.
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"
Comment 25 Deleted
Comment 26 by Deleted ...@, Jun 22 2015
I would expect nothing less from Google.  Extremely lame behavior from an Evil company...  Nothing new here.
Cc: -amistry@chromium.org
By nature, if active, the module has to be listening all the time, in order to capture the phrase. And at least on android, OK Google is actually triggered by a number of other phrases including "OK Computer". As long as this NaCl module remains closed source there is nothing that Google can do to reassure users that this is 100% benign.
Therefore any privacy conscious users should ensure that the NaCl module is not loaded, but along that line, should also remove the microphone from their system.
Comment 29 by Deleted ...@, Jun 23 2015
No "Enable Ok Google" checkbox option for chrome://settings/ in version 43.0.2357.130 on Mac OS10.6
Project Member Comment 30 by bugdroid1@chromium.org, Jun 24 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0366a5184a70b3eefb5fcef2c2e13721669f00d8

commit 0366a5184a70b3eefb5fcef2c2e13721669f00d8
Author: mgiuca <mgiuca@chromium.org>
Date: Wed Jun 24 05:41:33 2015

Disable "Ok Google" hotwording in open source builds by default.

The compile-time flag "enable_hotwording" is now tied to
branding=Chrome (false by default unless making a Google Chrome build).

Note: Chromium will no longer download/install the Hotword Shared
Module, and will automatically remove the Hotword Shared Module on
startup if it was previously installed. To keep this functionality, add
"enable_hotwording=1" to GYP_DEFINES.

BUG= 500922 

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

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

[modify] http://crrev.com/0366a5184a70b3eefb5fcef2c2e13721669f00d8/build/common.gypi
[modify] http://crrev.com/0366a5184a70b3eefb5fcef2c2e13721669f00d8/chrome/browser/BUILD.gn
[modify] http://crrev.com/0366a5184a70b3eefb5fcef2c2e13721669f00d8/chrome/browser/search/hotword_service_unittest.cc

Status: Fixed
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.

Chromium builds from r335874 (version 45) onwards will have hotwording disabled by default and will not download the module. There is no way to enable this feature at runtime. Google Chrome users will be unaffected (although, as always, will have to opt in using settings before the hotword module will activate).

If you want a version of Chromium with hotwording, you have to build it from source, with the GYP define "enable_hotwording=1" (or equivalently, the GN arg "enable_hotwording = true"). This will produce a custom build of Chromium that downloads the proprietary hotword component.

I have also added a field in the chrome://voicesearch page (in 45 onwards) to show you whether the hotword module is installable. If that says "No", then it is not possible to opt in to hotwording (either because the language is unsupported, or because it is a Chromium build).
#31

Oh wow, that's great to hear! Somehow expected this issue to be forgotten or waited out. But think it is the most sensible step, the most consistent in terms of open source dev model. And will probably forestall a lot of (maybe unjustified) paranoia. 
Thanks Matt.
Keep up the great work you guys. 

To elaborate on the chrome://voicesearch line that says "Extension State: ENABLED" ...

If one launches Google Chrome 43 with --show-component-extension-options and navigate to chrome://extensions, one will see the entry for "Hotword triggering" (extension id: nbpagnldghgfoolbancepceaanlmhfmd) says: "This extension is managed and cannot be removed or disabled."

An extension that is enabled is not the same as an extension that is actually running. To see the list of Chrome processes that are actually running, use Chrome's task manager. Hotword Triggering, as well as many other extensions will run briefly at startup. Those that are not actually being used will quit in about 10-15 seconds. If one has the "OK Google" voice search feature enabled, Hotword Triggering will continue to appear in the Chrome task manager. With the Chrome task manager open, one can turns on the voice search feature in the settings, and see the Hotword Triggering extension appear in the task manager. When one disable the setting, the extension will quit in 10-15 seconds.
Since this bug is about binary blobs in Chromium, I want to clarify the impact on end users who are using Chromium.

Chromium 45.0.2441.0 and newer will contain r335874 which disables the "OK Google" feature by default, as mentioned in comment 30 and comment 31. This only applies to binaries built with the Chromium source code with the default configuration and no modifications.

Remember that the Chromium project does not directly distribute Chromium browser binaries to end users. The only Chromium binaries produced by the Chromium project are the test builds in the project's continuous build system. These binaries, should one choose to download them, will have the feature off if they are r335874 or newer.

Most Linux Chromium users get Chromium packages from their Linux distributions or other third party Chromium browser packager. Those who actually packages Chromium binaries for end users can choose to turn this feature on or off, and also make any other changes as they see fit. This is beyond the Chromium project's control. If this issue concerns you, please check with your Chromium packager to see whether they choose to enable or disable this feature.

I will email the chromium-packagers mailing list to make them aware of this bug.
Comment 35 by Deleted ...@, Jun 24 2015
"As it is not open source, it does not belong in the open source browser."
Never were truer words spoken.

As I've always said: If you don't trust me enough to inspect your source code, I don't trust you enough to execute your binary.
Comment 36 Deleted
Comment 37 Deleted
I am sorry but this gesture on the part of Google is itself unnerving to me.  It appears to me that they are too quickly attempting make this disappear from the media's scrutiny.  I am responsible for development in a government agency.  Until now, I was unaware of this issue and I am very unnerved by the implications.  Before I jerk Chrome and all other Google developed software off the machines I would like to have a question answered:  Does the "hotword module" enabled or not, attempt to store and forward captured audio data to an outside server beyond my control?
#36

Sigh. Thanks. So hard to at least fly over the text before posting? Check #31:

>Chromium builds from r335874 (version 45) onwards will have hotwording disabled by default and will not download the module.


If these are the only types of comments that will follow up here I would propose closing. 
#38
This is the bug tracker of an open source browser that forms the foundation for Google Chrome (and a lot of other browsers). If you have complaints about Google's company policy, please contact them directly. 


Let's close this thing
Comment 41 by gsys...@gmail.com, Jun 24 2015
> Chromium builds from r335874 (version 45) onwards will have 
> hotwording disabled by default and will not download the module.

means what?? chromium continues to have this closed-source binary module that user could enable.. deliberately (or accidentally) by perhaps by clicking on a hotlink?
Comment 42 Deleted
#38, I'm not sure about your question, but I've opened up  Issue 504002  to look into it.
Plainly,

As of the newly-landed r335874 Chromium builds, by default, will not download this module at all. 

A binary blob module like this can not be installed by a user via clicking on a link. Such a Native Client module can only be installed by the user deliberately from the Chrome Web Store.

Chromium is open source and it's important to us, as is it is to you, that it doesn't ship with closed-source components, lazily or not. 


Thanks for everyone's attention and input on this one.

If you have any follow-up questions, please file new tickets and we'll get you answers.
Comment 45 Deleted
Can someone please clarify: I understand this was removed from Chromium, but will it still be installed and enabled by default in Google Chrome?
Erm, never mind. I see  Issue 504002  addresses that (although I have to wonder whether there is a difference in meaning between the words "activated" and "enabled". Am hoping no one has stooped so low as to play word games like that).
#47: I understand the concern about the words "activated" and "enabled", which sound very similar. This isn't word games, just slightly different words that have different technical meanings within Chromium.

What's important is whether the NaCl module is activated or running. When it's activated, the browser is listening for "Ok Google" and you have proprietary code running on your machine (in a sandbox ... once again, I have to remind you that this is just as secure as visiting any web page on the Internet). When it's inactive, it isn't listening. Having the extension enabled doesn't really do anything, because that just controls whether the extension is allowed to run JavaScript (and this extension has no JavaScript). Really this is just a side-effect of the fact that we used the extension system as a delivery mechanism.
Comment 49 Deleted
Comment 50 Deleted
Comment 51 Deleted
Considering the prevalence of this issue maybe it would make sense to create a FAQ dedicated for clarification on questions of this sort, Chromium's relationship with Google, it's open source model, proprietary modules etc. 
I know pages like that already exist to some extent but with seemingly more and more non-developer users switching to Chromium, a more compact and easy to undestand page might alleviate some of the concerns shown here. 
#52: I think we could clean up some of those chromium.org web pages a bit and explain the relationship more clearly. Thanks for the suggestion. (I'd be afraid nobody would bother to look at them anyway, but at least we'd have a place to point to.)

Also mr.anatol, in general can I say thanks for being level-headed and rational throughout this whole discussion.
Since there are many comments here which are *not related at all* to the issue (like #36 and #51), I doubt a FAQ would help at all.

As mgiuca said, nobody will read it, except people who actually realize what the issue is about, and what it's not.
#53 #54 
That's sadly true. But it could still come in handy when issues like this pop up and you can just paste the link. 
Comment 56 Deleted
Comment 57 by Deleted ...@, Jun 25 2015
#c48

> What's important is whether the NaCl module is activated or running. 
> When it's activated, the browser is listening for "Ok Google" 
> and you have proprietary code running on your machine

what's important is that proprietary modules exist inside chromium open-source. whether activated or running or not, is immaterial.. imho
#57 indeed - that's why it was removed in Chromium in r335874

Still it's relieving to know the downloaded binary blob was never run, IMHO. (And *that* part is verifiable)
Comment 59 by Deleted ...@, Jun 25 2015
This feature was enabled by default on Chrome in my brand 
new smartphone as well. 
Comment 62 by ver...@gmail.com, Jun 25 2015
Been meaning to add on this discussion for over a week.
It's like you're speaking a different language from the press. (true of course, you need PR to step in sooner in these cases)

From the Guardian: << Google responded to complaints via its developer boards. It said: “While we do download the hotword module on startup, we do not activate it unless you opt in to hotwording.” >> 
That sounds really bad when you forget to add: "... and even if you enable it, no audio leaves your computer, until you say OK Computer/Google. So even when you've enabled it, the only way for Google to receive all your microphone audio is if you keep saying OK Google every 5 seconds." 

That's essential reassurance, because this story has been in search results for [google chrome] for a week, possibly two. The selection of news sites got higher in repute every day, with comment sections alarmingly pessimistic. It wouldn't hurt to brief some PR people when this type of thing starts happening. They have a knack for translating to the layman's viewpoint.

Since some blogs link here, I'll just take the initiative and summarize what we've established:
This is a THREE-part problem, containing a DOUBLE misunderstanding.
1. The module isn't open-source >> Valid criticism, and so it has been taken out of Chromium.
2. Enabled is not the same as activated >> has been explained. You need to opt in.
3. Listening for the hotword is not the same as sending all audio to Google's servers. It happens on your computer.
#62

Great comment. 

>It's like you're speaking a different language from the press.

Isn't that usually the case though? Is in my experience. Especially with todays click-bait articles. And profiting from deliberately misrepresenting facts in order to puff up a story is nothing new either (the guardian editor who quoted that phrase probably read the rest of that comment as well). 

That's why me and others involved in this discussion have been posting the link to this ticket wherever we saw the issue being discussed, so concerned users could get accurate first-hand information instead of having to rely on the speculation of others. 
I know this is usually not welcome since bug trackers are meant purely for technical issues, but in this case I thought it was the most sensible solution, I'm sorry if I caused unnecessary spam. 

Generally I agree though, PR could have been more proactive, but I'm not sure if that would have changed a lot of the reporting. I think establishing the differences between Chromium and Chrome in a more prevalent manner would be a big one, I came across a ton of people making that mistake, even in technical forums. But then the naming isn't overly helpful either. 

@62: We briefed PR very early and they have been proactive about communicating.  That doesn't always mean that reports will print their responses, or (in at least one high-profile case) even reach out to give an opportunity to respond before running a story.

Please don't assume we're unaware of the great deal of misleading coverage of this issue.
Comment 65 Deleted
Comment 66 by ver...@gmail.com, Jun 25 2015
Efforts duly noted. 
It's just that I thought the "even then, only if you keep saying OK Google every 5 seconds" would have made it really hit home.
But it's always a struggle I guess. As you were.
Labels: Merge-Request-43 Merge-Request-44 M-43 M-44 M-45
Discussed offline and it looks like we should be able to merge this fix back to M43 and M44. Adding merge requests.

This will unfortunately require merging four CLs:

- http://crrev.com/333548
- http://crrev.com/335871 (optional, but it adds UI to explain the removal)
- http://crrev.com/335874
- http://crrev.com/336091 (necessary to fix Official builders broken by r335874)

All of these CLs are pretty minor, mostly just changing build configs and tests. Should affect Chromium only (not Google Chrome).

I've tested on Chrome Canary 45.0.2441.3 on Windows to make sure that hotword module is still installed on Google Chrome.
Labels: -Merge-Request-43 Merge-Review-43 Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M43), manual review required.
Labels: -Merge-Request-44 Merge-Approved-44 Hotlist-Merge-Approved
Approved for M44 (branch: 2403)
Comment 70 by Deleted ...@, Jun 26 2015
all that is said here is reassuring but why can't the user have the option to not allow audio capture or not allow microphone access? 

We have to trust that audio isn't being captured and transmitted.  I use a softphone and had to uninstall chrome from my work laptop because I can't trust that my conversations aren't being captured and transmitted.

Any thoughts?
Comment 71 by ivuc...@gmail.com, Jun 26 2015
#70
Do you trust all the other software on your machine not to access your microphone? If so, why? Isn't your feature request better suited for your operating system's developers?
Comment 72 by Deleted ...@, Jun 26 2015
No actually I don't trust other software.

Is it wrong to ask google to provide the user with the ability to control these options that they installed? The OS developers didn't install these.  By not allowing this kind of control leaves one to wonder what's not being said.
#70 - keep in mind the extension never is active unless you explicitly activate it ("Enable "Ok Google" to start a voice search") - so I don't really get what your point is.
Comment 74 by Deleted ...@, Jun 26 2015
sorry, i am not a developer, so, from what you are saying that with the feature sets of the extension being enabled and allowed to have access, there is no ability for google to capture audio without it being explicitly activated?  Can other plugins take advantage of these feature sets being enabled and not tell the user it is capturing audio?
Comment 75 by Deleted ...@, Jun 27 2015
"¬¬
#74 - as far as I understand, the hotword plugin (which is the scope of this bug report after all) can *not* capture any audio without it being enabled. Other plugins can *not* capture any audio without your consent.

In theory, of course Chromium (just as any other application on your machine) can record and send audio anywhere - but since it's open source, you (or anyone else) can verify it does in fact not.

The issue this bug report is about is that a closed-source blob was automatically downloaded, which is responsible for the hotword detection ("ok google"). It was however *not* automatically activated, and without being activated, there's no way for the plugin to capture audio.
#74: Mike, you do have full control over the feature. If you do nothing, it won't listen. If you decide to turn on the feature in Settings, Chrome will listen for "Ok Google" but it won't send the audio to Google unless it hears that phrase.

Other plugins (or, actually, any web page) can listen to the mic as well, but they have to individually ask for permission (you will see it as a pop up bubble). This is true for all modern web browsers.
Project Member Comment 78 by bugdroid1@chromium.org, Jun 29 2015
Labels: -Merge-Approved-44 merge-merged-2403
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/86fb78f02492b2990307ed427c09670f2fff0d3b

commit 86fb78f02492b2990307ed427c09670f2fff0d3b
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 02:42:17 2015

Disable "Ok Google" hotwording in open source builds by default.

The compile-time flag "enable_hotwording" is now tied to
branding=Chrome (false by default unless making a Google Chrome build).

Note: Chromium will no longer download/install the Hotword Shared
Module, and will automatically remove the Hotword Shared Module on
startup if it was previously installed. To keep this functionality, add
"enable_hotwording=1" to GYP_DEFINES.

BUG= 500922 

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

Cr-Commit-Position: refs/heads/master@{#335874}
(cherry picked from commit 0366a5184a70b3eefb5fcef2c2e13721669f00d8)

Fix up HotwordServiceTest on Chrome-branded builds.

The ENABLE_HOTWORDING flag is not available in
hotword_service_unittest.cc, so all tests were assuming hotwording was
disabled (since r333548). This has been failing on Official builders
since r335874.

Since it's hard to resolve this in a simple way (we want to merge these
changes), just disabling the tests is the cleanest option for now.

BUG=503963

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

Cr-Commit-Position: refs/heads/master@{#336091}
(cherry picked from commit 8ef0bc35b1594ad013dc2ae1d6893e0091919271)

Resolved merge conflict: Disabled IsHotwordAllowedDisabledFieldTrial and
IsHotwordAllowedInvalidFieldTrial. These tests were deleted before the
upstream patch landed.

(Merge approval on  http://crbug.com/500922#c69 )

R=thakis@chromium.org
TBR=thakis@chromium.org

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

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

[modify] http://crrev.com/86fb78f02492b2990307ed427c09670f2fff0d3b/build/common.gypi
[modify] http://crrev.com/86fb78f02492b2990307ed427c09670f2fff0d3b/chrome/browser/BUILD.gn
[modify] http://crrev.com/86fb78f02492b2990307ed427c09670f2fff0d3b/chrome/browser/search/hotword_service_unittest.cc

The hotword module will no longer be available from Chromium 44.0.2403.70 onwards.

Re Merge-Review-43: The merge was quite complicated. Four patches (see #c67), three with merge conflicts, and lots of different build configurations requiring manual testing. I'd be hesitant to do the merge to M43 as it's quite complex, but happy to do so if approved by TPMs.
Project Member Comment 80 by bugdroid1@chromium.org, Jun 29 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/528e8f0f7f7c639cdaab3bad6afbfc72b7a92633

commit 528e8f0f7f7c639cdaab3bad6afbfc72b7a92633
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 05:03:32 2015

Disable "Ok Google" hotwording in open source builds by default.

The compile-time flag "enable_hotwording" is now tied to
branding=Chrome (false by default unless making a Google Chrome build).

Note: Chromium will no longer download/install the Hotword Shared
Module, and will automatically remove the Hotword Shared Module on
startup if it was previously installed. To keep this functionality, add
"enable_hotwording=1" to GYP_DEFINES.

BUG= 500922 

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

Cr-Commit-Position: refs/heads/master@{#335874}
(cherry picked from commit 0366a5184a70b3eefb5fcef2c2e13721669f00d8)

Fix up HotwordServiceTest on Chrome-branded builds.

The ENABLE_HOTWORDING flag is not available in
hotword_service_unittest.cc, so all tests were assuming hotwording was
disabled (since r333548). This has been failing on Official builders
since r335874.

Since it's hard to resolve this in a simple way (we want to merge these
changes), just disabling the tests is the cleanest option for now.

BUG=503963

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

Cr-Commit-Position: refs/heads/master@{#336091}
(cherry picked from commit 8ef0bc35b1594ad013dc2ae1d6893e0091919271)

Resolved merge conflict: Disabled IsHotwordAllowedDisabledFieldTrial and
IsHotwordAllowedInvalidFieldTrial. These tests were deleted before the
upstream patch landed.

(Merge approval on  http://crbug.com/500922#c69 )

R=thakis@chromium.org
TBR=thakis@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/86fb78f02492b2990307ed427c09670f2fff0d3b

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

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

[modify] http://crrev.com/528e8f0f7f7c639cdaab3bad6afbfc72b7a92633/build/common.gypi
[modify] http://crrev.com/528e8f0f7f7c639cdaab3bad6afbfc72b7a92633/chrome/browser/BUILD.gn
[modify] http://crrev.com/528e8f0f7f7c639cdaab3bad6afbfc72b7a92633/chrome/browser/search/hotword_service_unittest.cc

Comment 81 by gsys...@gmail.com, Jun 29 2015
#80

> Disable "Ok Google" hotwording in open source builds by default.

> The compile-time flag "enable_hotwording" is now tied to
> branding=Chrome (false by default unless making a Google Chrome build).

so now the chromium open-source contain the google branding too? might as well kill chromium, and just open-source google chrome!
#81

>so now the chromium open-source contain the google branding too?

Not that I could see: https://src.chromium.org/chrome/trunk/src/build/common.gypi
#81 how did you get to that conclusion?
Project Member Comment 85 by bugdroid1@chromium.org, Jun 29 2015
The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/86fb78f02492b2990307ed427c09670f2fff0d3b

commit 86fb78f02492b2990307ed427c09670f2fff0d3b
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 02:42:17 2015

Project Member Comment 86 by bugdroid1@chromium.org, Jun 29 2015
The following revision refers to this bug:
  https://chrome-internal.googlesource.com/bling/chromium.git/+/528e8f0f7f7c639cdaab3bad6afbfc72b7a92633

commit 528e8f0f7f7c639cdaab3bad6afbfc72b7a92633
Author: Matt Giuca <mgiuca@chromium.org>
Date: Mon Jun 29 05:03:32 2015

Labels: -Merge-Review-43 Merge-Approved-43
Comment 88 by laforge@google.com, Aug 23 2015
Labels: -Merge-Approved-43
Clearing approvals older than 60 days
Comment 89 Deleted
Comment 90 Deleted
Sign in to add a comment