Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chromium unconditionally downloads binary blob

bugs.debian.org

Post reply on HN
Print view View original

141–150 of 180 posts

Re: Chromium unconditionally downloads binary blob

#141

Post by fapjacks »

marssaxman wrote: post #134
snops wrote: post #129

Earlier quoted context omitted.

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?…

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 re…

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.

Re: Chromium unconditionally downloads binary blob

#142

Post by finnn »

Animats wrote: post #137

Note that although this bug report was forcibly closed, the fix is "This change adds an "enable_hotwording" build flag that is enabled by default , but can be disabled at compile time." Consider what this backdoor does. It listens to any conversation in the vicinity of the phone and reports it to a remote site. You can't see its keyword list. You can't tell when it's transmitting to the mothership. Has anyone filed a…

>vicinity of the phone

What phone? Last I checked this was for the desktop build of Chromium

Re: Chromium unconditionally downloads binary blob

#143

Post by nivla »

zoner wrote: post #50

Switched to Firefox as the primary browser just to be sure :)

Wasn't Firefox recently called out for including proprietary integration from Pocket and Hello on their new versions by default which cannot be removed but only disabled? [1]

I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :(

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

Re: Chromium unconditionally downloads binary blob

#144

Post by rhelmer »

nivla wrote: post #143
zoner wrote: post #50

Switched to Firefox as the primary browser just to be sure :)

Wasn't Firefox recently called out for including proprietary integration from Pocket and Hello on their new versions by default which cannot be removed but only disabled? [1] I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :( [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

Can you please cite where you read that proprietary blobs are used? IIRC the Pocket client is open-source, and so is the Hello client (it's basically a webapp that uses WebRTC)

Re: Chromium unconditionally downloads binary blob

#145

Post by nivla »

rhelmer wrote: post #144
nivla wrote: post #143

Earlier quoted context omitted.

Wasn't Firefox recently called out for including proprietary integration from Pocket and Hello on their new versions by default which cannot be removed but only disabled? [1] I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :( [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

Can you please cite where you read that proprietary blobs are used? IIRC the Pocket client is open-source, and so is the Hello client (it's basically a webapp that uses WebRTC)

You maybe right, that was bad wording on my side, thanks and corrected. I meant to write "Proprietary Integration", since it is only and only compatible with its respective companies/applications.

Re: Chromium unconditionally downloads binary blob

#146

Post by mehrdada »

sqeaky wrote: post #108
pbhjpbhj wrote: post #39

Earlier quoted context omitted.

>this is like calling someone a murderer because he went to the same high school as a murderer // I'd say a closer analogy would be because he had the same blood splatter pattern on his clothes as a murderer. But neither is a useful analogy they're just biased by our perspective on Google.

Think about these peoples starting point. They want a complete OS and application set built from source that is completely auditable. This is direct circumvention of that. Additionally, you can never prove you have removed all of your security flaws. The best you can do is search harder to become more confident that none exist. There is no way to prove that a privilege escalation flaw does not exists. Now arbitrary c…

I think you are underestimating how much stuff you can actually prove. There's an entire field doing software verification which deals which formalizing aspects of the execution environment and proving absence of certain properties, i.e. classes of bugs, in a system. Sure, your proofs might rely on some "assumptions", but testing, a mere search for the bugs, is surely not the only way to ensure correctness.

Re: Chromium unconditionally downloads binary blob

#147

Post by JohnTHaller »

nivla wrote: post #143
zoner wrote: post #50

Switched to Firefox as the primary browser just to be sure :)

Wasn't Firefox recently called out for including proprietary integration from Pocket and Hello on their new versions by default which cannot be removed but only disabled? [1] I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :( [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

The client side code for Pocket integration is open source, so you can look at it if you'd like. You can disable it just by removing the Pocket icon from the toolbar. Plus, as Firefox uses lazy loading, once the Pocket icon is removed, the integration code will never be run.

Re: Chromium unconditionally downloads binary blob

#148

Post by prewett »

qwe123 wrote: post #98
laumars wrote: post #97

Earlier quoted context omitted.

> I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed. That would prove nothing since there'd be no evidence to back up said s…

>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful. The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".

Actually, no, apparently Firefox downloaded an OpenH264 blob [1]. See message 51 at the bottom (presumably "FF" means "Firefox").

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51

Re: Chromium unconditionally downloads binary blob

#149

Post by dbbolton »

laumars wrote: post #103
qwe123 wrote: post #98

Earlier quoted context omitted.

>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful. The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".

There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany). Konquorer was still kHTML last time I checked, but there are with webkit ports as well if that's really what you want. Then there's Opera, which on some platforms (eg Linux) is still using it's older renderer rather than Blink (see footnote); and Otter as well. There's quite a few Firefox forks too (eg Palemoon)....…

>There are other webkit browsers without Chromium's extended libraries such as Surf and Web (Epiphany).

What about Midori (LGPL 2.1)? For some reason it's not available for jessie, but 0.4.3 is available for wheezy, stretch, and sid: https://packages.debian.org/stretch/midori

The latest version on Midori's site is 0.5.9: http://midori-browser.org/download/debian/

Re: Chromium unconditionally downloads binary blob

#150

Post by mbrubeck »

prewett wrote: post #148
qwe123 wrote: post #98

Earlier quoted context omitted.

>If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful. The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".

Actually, no, apparently Firefox downloaded an OpenH264 blob [1]. See message 51 at the bottom (presumably "FF" means "Firefox"). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51

Firefox does auto-download an OpenH264 binary on systems without a supported H.264 decoder library (if this feature is enabled, which it isn't currently in Debian's iceweasel packages). But note that OpenH264 is free software available under the BSD license:

https://github.com/cisco/openh264/

Firefox downloads binaries from Cisco because Cisco can legally distribute this software in binary form in countries where H.264 patents apply, while Mozilla can't do so directly.

There was also a plan discussed to make it easy to automatically verify that the binary corresponds with the published source code, but as far as I know that work hasn't been done yet:

https://github.com/cisco/openh264/issues/893

Also, if you have the correct gstreamer H.264 plugin installed, Firefox should use that instead of downloading OpenH264.

Post reply on HN