Hacker News Reader

Hacker News

Comment by marssaxman | Hacker News Reader

Parent Full thread

marssaxman

Is this true of Chrome as well?

If so, I will never run it again.

View on HN

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.

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?

Reply on news.ycombinator.com