Hacker News Reader

Comment by jameshart | Hacker News Reader

In a web browser implementation with NaCl support, downloading and executing arbitrary binary blobs is very much a feature, not a bug. The issue here seems to be that Chromium was configured, by default, to download and execute a particular Google-provided binary blob. And now it isn't.

Note that as soon as you go to ANY WEBSITE using Chromium, you are entrusting that site to download you arbitrary data, which could include NaCl binaries, which you're then going to trust Chromium to execute.

View on HN

If the default is to allow those arbitrary pieces of code to obtain audio input from the microphone, then that is a major issue. I very much doubt it allows that by default.

The problem here is not mainly that it downloads and executes code via NaCl, though it's iffy that it does so with no simple way to disable it.

The problem is if it does so and grants that code access to API's' that should be privileged and something the user ought to be aware of.

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

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.

Is this true of Chrome as well?

If so, I will never run it again.

Yes, of course it is. Why would it be a thing in the open source version but not the almost-identical closed source version with extra Google goodies. Unless one of those goodies was "remove one of the key aspects of NaCl", which I can assure you, is not.

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 have bad news for you: Chrome is a binary blob of code from Google that has access to your microphone.

I wonder if there is a way to monitor whether the mic is being accessed from a program on linux?

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

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?

I didn't even know this "native client sandbox" existed! Why the hell should I trust it, or anything executed inside it?

I'm tentatively willing to believe that Chrome is probably not trying to pwn my box, because I don't think Google has a compelling reason to do that which would outweigh the flak they would get if they were caught. Allowing them to run arbitrary compiled executables on my machine, however, would require me to transitively extend trust to everyone using their technology, and to do that I would have to be confident that there are not and never will be any security holes in their sandbox. That is an unlikely proposition to say the least and therefore I want nothing to do with NaCl.

In some instances when served with an NSL (or some other mechanism we don't even yet know about), they can be forced through legal policy to cooperate in building something that pwns your box. Google's compelling reason is that they are under the jurisdiction of the American government. Though I share your tentative belief that Chrome/ium isn't necessarily a "pwn vector" per se, I am 100% willing to believe that they are compelled to cooperate in building some kind of vector for the NSA.

You say "they" as in Google, but it would be much more effective to persuade a single developer (and maybe his manager) who can implement such a feature in a open, transparent way (which would display the standard "recording" icon in the omnibar) or in a closed, subversive way (like, this).

Basically lean on "Never attribute to malice that which is adequately explained by stupidity" as much as possible to fly under the radar as long as possible.

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

NaCl is not PNaCl. NaCl blobs don't require translation and aren't machine independent at all.

Reply on news.ycombinator.com