Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 552298 - >=www-client/chromium-43.0.2357.65 add opt-out of chrome hotword shared module
Summary: >=www-client/chromium-43.0.2357.65 add opt-out of chrome hotword shared module
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal major with 1 vote (vote)
Assignee: Chromium Project
URL: https://code.google.com/p/chromium/is...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-16 14:40 UTC by Harm Geerts
Modified: 2015-06-29 03:07 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Upstream changeset (chromium-hotwording-r0.patch,5.02 KB, patch)
2015-06-21 20:34 UTC, Mike Gilbert
Details | Diff
Patch for 2403 branch (chromium-hotwording-2403.patch,5.29 KB, patch)
2015-06-21 21:06 UTC, Mike Gilbert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Harm Geerts 2015-06-16 14:40:40 UTC
Chromium ebuild needs a USE flag to explicitly enable the shared hotword module.

Change message from the chromium bug report:


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.

Reproducible: Always

Steps to Reproduce:
$ chromium --temp-profile &
$ find /tmp/tmp.*/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/
/tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/
/tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/x86-64_ja
/tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/x86-64_ja/hotword.data
/tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/x86-64_ja/hotword-x86-64.nexe
$ file /tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/x86-64_ja/hotword-x86-64.nexe
/tmp/tmp.YClr3VfmnS/Default/Extensions/lccekmodgklaepjeofjdjpbminllajkg/0.3.0.5_0/_platform_specific/x86-64_ja/hotword-x86-64.nexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=24d25d55886dca48921031d6928b0a34f5659830, stripped
Comment 1 Andrew Savchenko gentoo-dev 2015-06-18 11:13:31 UTC
I'd like to raise concern that this issue is a severe security violation, as chromium downloads binary code with unknown functionality, e.g. backdoors are quite possible.

Also please note that this extension is not only unconditionally installed, but doesn't appear on the list of extensions:
https://code.google.com/p/chromium/issues/detail?id=491435#c7
Thus users are not aware that their browser downloads and runs binary blob.

Moreover chromium developers consider such blobs as a part of the source code:
"we consider these extensions to be just another bit of the Chrome code"
https://code.google.com/p/chromium/issues/detail?id=491435#c10
This way chromium is no longer a free software, this doesn't violate BSD license (as far as I know), but this violates user's freedom even without their knowledge.
Comment 2 Hanno Böck gentoo-dev 2015-06-18 12:24:49 UTC
I just tried to understand what's going on and it may be a bit less severe than I first thought.

Yes, the module gets downloaded silently which I think is not good and we should seek to disable this by default. However the code is not started unless you explicitely click an option to enable OK google search.

I still don't like it, but my outrage significantly decreased once I understood that :-)
Comment 3 Ulrich Müller gentoo-dev 2015-06-18 12:48:16 UTC
(In reply to Andrew Savchenko from comment #1)
> "we consider these extensions to be just another bit of the Chrome code"
> https://code.google.com/p/chromium/issues/detail?id=491435#c10
> This way chromium is no longer a free software, this doesn't violate BSD
> license (as far as I know), but this violates user's freedom even without
> their knowledge.

It is still within the terms of the BSD license, but without source code it indeed is no longer free software.

We have the no-source-code license label for this situation, i.e., LICENSE should be changed from "BSD" to "BSD no-source-code".
Comment 4 Andrew Savchenko gentoo-dev 2015-06-18 13:55:12 UTC
(In reply to Hanno Boeck from comment #2)
> I just tried to understand what's going on and it may be a bit less severe
> than I first thought.
> 
> Yes, the module gets downloaded silently which I think is not good and we
> should seek to disable this by default. However the code is not started
> unless you explicitely click an option to enable OK google search.

Unfortunately, no. This extension is enabled even with "Goole OK" disabled. Go to chrome://voicesearch/ and see for yourself, on my system I have:
http://i.imgur.com/ZGk1J7p.png
http://i.imgur.com/Aomi3f0.png
Comment 5 Harm Geerts 2015-06-18 14:23:43 UTC
According to a comment on one of the bug reports regarding this issue:
https://code.google.com/p/chromium/issues/detail?id=500922#c6

It seems the extension is downloaded and activated but the binary is only activated if the user opts in when he/she enables the setting "Enable "Ok Google" to start a voice search" found in chrome://settings/
Comment 6 Mike Gilbert gentoo-dev 2015-06-18 14:25:53 UTC
@chromium: Do we want to add a USE flag to toggle the enable_hotword build flag?

If we do, I think it should be enabled by default to match upstream's preference.
Comment 7 Kristian Fiskerstrand gentoo-dev Security 2015-06-18 14:57:43 UTC
(In reply to Mike Gilbert from comment #6)
> @chromium: Do we want to add a USE flag to toggle the enable_hotword build
> flag?
> 
> If we do, I think it should be enabled by default to match upstream's
> preference.

I'm in favor of the opposite. Its an optional feature that potentially enables voice recording, i.e. privacy related, and users might not know about. That would also allow the core ebuild to build without requiring the necessary "no-source-code" license, which would only be required when activating the USE flag.
Comment 8 Hanno Böck gentoo-dev 2015-06-18 15:07:59 UTC
Either do what Kristian says or disable it altogether.

Just think about this: There's "Chrome" (the proprietary version) and it's free variant "Chromium". I don't see any reason why a user who explicitely chooses the free variant of the Chrom* browser family would expect a binary blob.

But having a local useflag is probably okay, if it's properly documented and unambiguous. We could name it hotword-nonfree or hotword-binary-blob or something alike.
Comment 9 Mike Gilbert gentoo-dev 2015-06-18 15:11:08 UTC
(In reply to Kristian Fiskerstrand from comment #7)
> I'm in favor of the opposite. Its an optional feature that potentially
> enables voice recording, i.e. privacy related, and users might not know
> about.

Users who are concerned about such things should not have "no-source-code" ACCEPT_LICENSE.
Comment 10 Mike Gilbert gentoo-dev 2015-06-18 15:12:47 UTC
(In reply to Hanno Boeck from comment #8)
> But having a local useflag is probably okay, if it's properly documented and
> unambiguous. We could name it hotword-nonfree or hotword-binary-blob or
> something alike.

The USE flag should reflect the function being toggled (hotword), not the license or the method of distribution.
Comment 11 Andrew Savchenko gentoo-dev 2015-06-18 15:33:12 UTC
(In reply to Harm Geerts from comment #5)
> According to a comment on one of the bug reports regarding this issue:
> https://code.google.com/p/chromium/issues/detail?id=500922#c6
> 
> It seems the extension is downloaded and activated but the binary is only
> activated if the user opts in when he/she enables the setting "Enable "Ok
> Google" to start a voice search" found in chrome://settings/

Please see screenshots from comment 4 (or test this yourself if you doubt screenshots): the extension is always active.
Comment 12 Ulrich Müller gentoo-dev 2015-06-18 15:53:01 UTC
(In reply to Hanno Boeck from comment #8)
> Either do what Kristian says or disable it altogether.

+1

Functionality like this which installs additional closed-source code with an otherwise free package shouldn't be enabled by default, regardless of upstream's preference.


(In reply to Mike Gilbert from comment #10)
> The USE flag should reflect the function being toggled (hotword), not the
> license or the method of distribution.

I agree here, the flag should be named after the function.
Comment 13 Harm Geerts 2015-06-18 16:30:18 UTC
(In reply to Andrew Savchenko from comment #11)
> (In reply to Harm Geerts from comment #5)
> > According to a comment on one of the bug reports regarding this issue:
> > https://code.google.com/p/chromium/issues/detail?id=500922#c6
> > 
> > It seems the extension is downloaded and activated but the binary is only
> > activated if the user opts in when he/she enables the setting "Enable "Ok
> > Google" to start a voice search" found in chrome://settings/
> 
> Please see screenshots from comment 4 (or test this yourself if you doubt
> screenshots): the extension is always active.

I have, the extension is active but the binary nacl module is never accessed.
I verified this with sysdig using the procedure:
1. start chromium with a new --user-data-dir
   this will download the extension
2. quit chromium
3. start sysdig
4. start chromium, access chrome://voicesearch which shows it as enabled
5. quit chromium and stop sysdig

The sysdig tracefile (+350MB) shows that the binary nacl module is not accessed even though the extension is active.

(In reply to Ulrich Müller from comment #12)
> I agree here, the flag should be named after the function.

hotword is not very descriptive to users.
I'd suggest voicesearch or okgoogle :)
Comment 14 Mike Gilbert gentoo-dev 2015-06-18 16:37:05 UTC
(In reply to Harm Geerts from comment #13)
> hotword is not very descriptive to users.
> I'd suggest voicesearch or okgoogle :)

voicesearch seems like a reasonable choice.
Comment 15 Andrew Savchenko gentoo-dev 2015-06-18 17:48:42 UTC
(In reply to Harm Geerts from comment #13)
> The sysdig tracefile (+350MB) shows that the binary nacl module is not
> accessed even though the extension is active.

It shows the same when "OK Google" button is toggled. This feature may be on-demand or toggle via other ways. Thus lack of nacl module access in particular case proves only that it is not accessed in that particular case. No further assumptions can be made here.
Comment 16 Alexander Berntsen (RETIRED) gentoo-dev 2015-06-21 13:39:27 UTC
(In reply to Ulrich Müller from comment #12)
> (In reply to Hanno Boeck from comment #8)
> > Either do what Kristian says or disable it altogether.
> 
> +1
> 
> Functionality like this which installs additional closed-source code with an
> otherwise free package shouldn't be enabled by default, regardless of
> upstream's preference.
+1.
Comment 17 Mike Gilbert gentoo-dev 2015-06-21 15:05:42 UTC
I'm adding a USE flag "hotword" to www-client/chromium-45.0.2431.0, defaulting to disabled. The build test is running now.

While "hotword" might not be the most intuitive flag name, it does match our existing local use flags which are all named after gyp build flags. Since the flag is disabled by default, I don't think this will cause a great amount of outrage.
Comment 18 Mike Gilbert gentoo-dev 2015-06-21 20:08:00 UTC
+  21 Jun 2015; Mike Gilbert <floppym@gentoo.org> chromium-45.0.2431.0.ebuild,
+  metadata.xml:
+  Make 'hotwording' optional at build time, bug 552298.
Comment 19 Mike Gilbert gentoo-dev 2015-06-21 20:34:15 UTC
Created attachment 405502 [details, diff]
Upstream changeset

Back-porting this will take a little effort. Here's a starting point.

Hunk #1 succeeded at 381 (offset -35 lines).
Hunk #2 succeeded at 1137 (offset -9 lines).
checking file chrome/browser/BUILD.gn
Hunk #1 succeeded at 18 (offset -1 lines).
Hunk #2 succeeded at 460 (offset 3 lines).
checking file chrome/browser/search/hotword_service.cc
Hunk #1 FAILED at 639.
1 out of 1 hunk FAILED
checking file chrome/browser/search/hotword_service_unittest.cc
Hunk #1 succeeded at 216 with fuzz 1 (offset 59 lines).
Hunk #2 succeeded at 247 (offset 59 lines).
Hunk #3 succeeded at 304 (offset 59 lines).
Hunk #4 succeeded at 375 (offset 59 lines).
checking file chrome/chrome_browser.gypi
Hunk #1 succeeded at 3529 (offset -60 lines).

If someone wants to fix the patch to apply on top of chromium-43 and chromium-44, please feel free to help out.
Comment 20 Mike Gilbert gentoo-dev 2015-06-21 21:06:51 UTC
Created attachment 405504 [details, diff]
Patch for 2403 branch

Working on chromium-44.
Comment 21 Neil Bothwick 2015-06-23 10:12:00 UTC
Because the flag defaults to off, even though the default for this version was previously on, emerge --changed-use @world does not pick it up, leaving the feature enabled. Is there a way to force a rebuild in this situation without a revbump?
Comment 22 Harm Geerts 2015-06-23 13:44:51 UTC
(In reply to Neil Bothwick from comment #21)
> Because the flag defaults to off, even though the default for this version
> was previously on, emerge --changed-use @world does not pick it up, leaving
> the feature enabled. Is there a way to force a rebuild in this situation
> without a revbump?

You can use --newuse (-N) which will select packages when: A USE flag was added to a package.  A USE flag was removed from a package.  A USE flag was turned on for a package.  A USE flag was turned off for a package.

off topic: Is there a use case for --changed-use instead of --newuse ?
The latter seems "better" and what I'd expect --changed-use would do as well.
Comment 23 Neil Bothwick 2015-06-23 18:00:56 UTC
--changed-use avoids unnecessary recompiles when the USE flag change would not affect the installed system, but that's not the case here.
Comment 24 Harm Geerts 2015-06-23 22:47:25 UTC
There is another side of this bug which hasn't been addressed in the current ebuild. If a user has a chromium profile with the hotword module installed it will still remain active even if the use flag is set to disabled and the user wouldn't be the wiser.
Should the ebuild issue a warning about this?
Should it actively search a homedir to see if the module is installed in a chromium profile or let the user do this?
For example using: locate '/home/*/chromium/*/lccekmodgklaepjeofjdjpbminllajkg'
And what are the required actions to clean it up?
Comment 25 Mike Gilbert gentoo-dev 2015-06-23 23:39:53 UTC
(In reply to Harm Geerts from comment #24)

I'm not adding anything to the ebuild beyond what I have done thus far.
Comment 26 Hanno Böck gentoo-dev 2015-06-24 15:06:08 UTC
Just FYI, Google changed the default from enabled to disabled:
https://code.google.com/p/chromium/issues/detail?id=500922#c30

So our default is "upstream default" now again :-)
Comment 27 Mike Gilbert gentoo-dev 2015-06-29 03:07:45 UTC
I backported this to the latest stable release. Closing.