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

101–110 of 180 posts

Re: Chromium unconditionally downloads binary blob

#101

Post by crush_fear_27 »

qwe123 wrote: post #83
Tobani wrote: post #62

Earlier quoted context omitted.

As far as we know only on insecure channels. Google had "private" pipes that they thought they didn't need to encrypt between datacenters and they didn't think they needed to encrypt that data. That was the MITM we knew about. I don't believe we know of them MITM'ing a cryptographically secure channel.

>I don't believe we know of them MITM'ing a cryptographically secure channel. ... two years ago.

Can I have a good citation on that? I'm interested in knowing more about it. Also, I'm not sure if you're referring to snowden or something else.

Re: Chromium unconditionally downloads binary blob

#102

Post by Niten »

stevehawk wrote: post #44
IshKebab wrote: post #40

Earlier quoted context omitted.

Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.

How is NaCl not just "Google's version of ActiveX"

Here's an overview:

http://static.googleusercontent.com/media/research.google.co...

Re: Chromium unconditionally downloads binary blob

#103

Post by laumars »

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

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)....and if all else fails, you can always run lynx or elinks :p

So there are definitely quite a few alternatives (the last two were obviously a joke though). Granted many are not as feature rich, but they'll still be HTML5 compliant.

Thank you for the correction on the Google Chrome/Chromium point though. Updated my post to reflect that.

Footnote: has anyone checked if this is a Blink issue or just Chromium? Because Opera, Vivaldi and other browsers use Blink but likely wouldn't have hotword. So that would be even more alternatives available.

Re: Chromium unconditionally downloads binary blob

#104

Post by laumars »

anon3_ wrote: post #100
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…

> That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with. Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code. It's highly suggestive. > If you're really that paranoid about closed source components within Google Chrome then the…

> Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code. It's highly suggestive.

Indeed. But that doesn't change my statement.

> Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up?

Because you'd still have the same browser choices if you did move :p

In all seriousness though, what are your options:

1. fork Chromium and remove the closed components

2. use another browser

3. moan on the internet

You've got 3 nailed but that doesn't seem to be helping the situation. So maybe you should start a fork instead? Or perhaps go with my suggestion of boycotting Chromium since it actually turns out to be the easiest practical solution despite your exaggerative remark.

Re: Chromium unconditionally downloads binary blob

#105

Post by vezzy-fnord »

strcat wrote: post #87
jug wrote: post #86

Earlier quoted context omitted.

It does, and I enjoy mp4 videos and I'm not bothered much by DRM on Netflix either, but should a component like NaCl implying a binary blob be part of an open source software.. by default? Feels weird to have it included with Chromium by default. Weren't Chrome and Chromium originally separated in order to make one compatible with open source distributions, so that this sort of thing would be avoided? A conflict with…

NaCl doesn't imply proprietary any more than a JavaScript engine does. The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. It's not substantially different from a freedom perspective than code compiled to asm.js or just minified JavaScript. Both are usually proprietary and require reverse engineering work to decipher.

As it's not the "preferred form of the work", I think it is proprietary - same way any object/intermediate or obfuscated code would be.

Re: Chromium unconditionally downloads binary blob

#106

Post by fao_ »

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

And as a last resort, one could always resort to telnet :)

Re: Chromium unconditionally downloads binary blob

#107

Post by luso_brazilian »

rockdoe wrote: post #79
luso_brazilian wrote: post #49

Earlier quoted context omitted.

The source code being downloaded, compiled and run or a script being download and run would be a as much a security incident as what happened. In this context (Chromium on Debian) having a closed source binary downloaded and executed is an additional problem to the security incident and that's the reason it is mentioned in the statement. There are two problems conflated in the same sentence: 1. A binary was downloade…

>a script being download and run would be a as much a security incident as what happened. Like opening a webpage?

Yes. If opening a webpage downloaded a script that permanently altered the browser adding or removing functionality without explicit user intervention or consent it would be a security incident. There is even a class of scripts that warrants a special name because of this exactly behaviour: malware.

Considering the more general case of scripts being downloaded and executed in the browser (javascript, for instance) the more apt analogy would be one being downloaded and executed in a system with NoScript installed.

Just like NoScript is a tool that gives its users the power to decide on a case by case basis which scripts are executed by the browser, Debian is a tool that gives its users the power to decide on a case by case basis which closed source binaries are executed by their system.

Preventing this choice in this context is a security incident.

Re: Chromium unconditionally downloads binary blob

#108

Post by sqeaky »

pbhjpbhj wrote: post #39
dtech wrote: post #18

Earlier quoted context omitted.

Even if malice instead of incompetence is involved, it goes pretty far to call Chromium a "rootkit-downloader" just because it downloads a binary blob. It could theoretically be a rootkit, but without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.

>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 code is run against you wishes and without your permission.

No one can prove it didn't run a privilege escalation attack. If you think your digital security is of paramount importance you must assume you have been compromised and take steps to remedy this potential issue.

It is not that google is guilty, it is that moments before this happened security was provable and now it is not.

Re: Chromium unconditionally downloads binary blob

#109

Post by anonbanker »

strcat wrote: post #88
mortehu wrote: post #61

Earlier quoted context omitted.

> the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement I've looked at the API, and can't agree with your statement. The API is similar to a typical game engine API. There are classes for handling input devices, audio, OpenGL, hardware video decoding, filesystem access, and basic networking. The PPAPI does not even touch the DOM, so it's not tied to being in a web browser…

PPAPI is just providing an alternate, lower-level interface to the same web techniques accessible via JavaScript APIs. There's a bit more power (OpenGL ES 2.0, not the crippled WebGL standard based upon it) but nothing very significant. It's not browser-specific but it's also not going beyond what browsers provide.

I laughed real hard at the "just" in your sentence. thank you for that.

Re: Chromium unconditionally downloads binary blob

#110

Post by jwise0 »

kekebo wrote: post #68

I opened a ticket in Chromium's Google Code repo, feel free to jump in: https://code.google.com/p/chromium/issues/detail?id=500922

Please read the original thread. This was already reported as: https://code.google.com/p/chromium/issues/detail?id=491435
Post reply on HN