Chromium unconditionally downloads binary blob

I thought the code review on the build change was a little more enlightening. More honest discussion.

https://codereview.chromium.org/1160243004

(Names removed as don't think they're important to repost. And not intending this as incendiary. At some point someone needs to ask "How much are we impacting usability by stripping features?")

"1 week ago (2015-06-09 02:17:42 UTC) #19

On 2015/06/09 01:34:04, _ wrote: > On 2015/06/09 01:13:10, _ wrote: > > Done, but I'm going to voice my opposition to this. When I took over the > > hotwording code, there were a number of obscure hoops to jump though to get > this > > to work locally. They've been eliminated. Having to find these pair of > #defines > > and changing them is more obscure to a newcomer than a build flag (that can > > easily be traced through the code). >

> What about having a run time flag for enabling hotwording? We would always > enable hotwording for Google Chrome builds, and check for it in Chromium builds. > That way, Chromium users can make the decision to use the feature, rather than > the Chromium distributor. And it won't require hotwording developers to build > with GOOGLE_CHROME_BUILD or do any #ifdef hacking.

We shouldn't be exposing feature-enables to end users as runtime switches.

Honestly, I think the right thing to do is for Chromium users to get this by default but have a build switch that can be used to disable it for projects like Debian that feel more strongly about not having any external binary blobs used for anything. I don't think simply disabling this in general for Chromium is correct. It's not true that Chromium by definition should not make use of such blobs, and I think the damage to developers and to more pragmatic users of Chromium-based projects is greater than we should be willing to pay."

It seemed plausible, but I don't know what "NaCl" is, have no familiarity with Chrome internals, and had never heard of this before. Seemed like it was worth checking before making such a decision. I am amazed that Google has repeated Microsoft's mistake with ActiveX - who would think this was a good idea?

I've run a "arecord" on hw:1,0 (via pulseaudio, oh my....) to show that one of the devices (pcm0c) is currently capturing audio. Below is the "hardware status" as reported by alsa. On the pavucontrol UI application (again pulseaudio) the recording application is also shown.

     ➜  ~  find /proc/asound/card* -name status | xargs grep ""
     /proc/asound/card0/pcm0c/sub0/status:closed
     /proc/asound/card0/pcm0p/sub0/status:closed
     /proc/asound/card0/pcm2c/sub0/status:closed
     /proc/asound/card0/pcm3p/sub0/status:closed
     /proc/asound/card0/pcm7p/sub0/status:closed
     /proc/asound/card0/pcm8p/sub0/status:closed
     #### ---v--- this one records
     /proc/asound/card1/pcm0c/sub0/status:state: RUNNING
     /proc/asound/card1/pcm0c/sub0/status:owner_pid   : 1260
     /proc/asound/card1/pcm0c/sub0/status:trigger_time: 108525.846389845
     /proc/asound/card1/pcm0c/sub0/status:tstamp      : 108558.575144693
     /proc/asound/card1/pcm0c/sub0/status:delay       : 96
     /proc/asound/card1/pcm0c/sub0/status:avail       : 96
     /proc/asound/card1/pcm0c/sub0/status:avail_max   : 96
     /proc/asound/card1/pcm0c/sub0/status:-----
     /proc/asound/card1/pcm0c/sub0/status:hw_ptr      : 1570901
     /proc/asound/card1/pcm0c/sub0/status:appl_ptr    : 1570805
     #### ---^---
     /proc/asound/card1/pcm0p/sub0/status:closed

The nomenclature here is hw:N,M corresponds to cardN/pcmMc (c: capture, p: playback).

A major difference is that web content does not have silent access to your microphone, and the ability to monitor you and send information back home.

There are large security differences between what NaCl allows for web content, and what it allows for what Google considers internal parts of Chromium, even if they run in NaCl. Like this blob here, and also Flash, the PDF plugin, and others. All those do a lot more than what a random website would be allowed to.

They are sandboxed "machine independent" binary blobs that chrome translates into the local architecture, see https://developer.chrome.com/native-client for details.

Javascript isn't far off binary in terms of readability nowadays with the level of packing/minification, so legibility isn't a deciding factor. Therefore if you can't trust the native client sandbox, why trust javascript, or even HTML from third parties? Native client is part of Chromium, you can audit the source code just as much as for any other language your browser speaks, so why make this distinction?