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
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.
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 :-)
(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".
(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
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/
@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.
(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.
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.
(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.
(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.
(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.
(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.
(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 :)
(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.
(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.
(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.
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.
+ 21 Jun 2015; Mike Gilbert <floppym@gentoo.org> chromium-45.0.2431.0.ebuild, + metadata.xml: + Make 'hotwording' optional at build time, bug 552298.
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.
Created attachment 405504 [details, diff] Patch for 2403 branch Working on chromium-44.
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?
(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.
--changed-use avoids unnecessary recompiles when the USE flag change would not affect the installed system, but that's not the case here.
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?
(In reply to Harm Geerts from comment #24) I'm not adding anything to the ebuild beyond what I have done thus far.
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 :-)
I backported this to the latest stable release. Closing.
