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

81–90 of 180 posts

Re: Chromium unconditionally downloads binary blob

#81

Post by mynameisvlad »

sneak wrote: post #73
Flenser wrote: post #63

Earlier quoted context omitted.

They spied on unencrypted data as it was transferred between data-centers. They can't decrypt or MITM anything because they don't have google's keys, and chrome using HSTS cert-pinning means that the cert is fixed and can't be faked with one for google from another top-level CA.

> They can't decrypt or MITM anything because they don't have google's keys Hard to prove a negative.

Then show an example that proves the NSA has Google's keys. If you want to do proofs, how about you put your money where your mouth is?

Re: Chromium unconditionally downloads binary blob

#82

Post by rockdoe »

mavhc wrote: post #71
morganvachon wrote: post #38

Earlier quoted context omitted.

> without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer. That's a pretty flawed analogy. If you're going to examine it from a criminal act point of view, let's really look at it that way. If installing a rootkit is equivalent to premeditated murder, then the murderer must have motive, means, and opportunity. Let's take Sony as a good example o…

Seems like the OS should be doing a lot more sandboxing of hardware features. And is Chromium ever run as root? How could it install a rootkit if not?

The problem is that a browser does really want access to a whole lot of stuff as it's almost an OS.

But no, Chromium doesn't run as root afaik, the rootkit stuff is complete bullshit.

Re: Chromium unconditionally downloads binary blob

#83

Post by qwe123 »

Tobani wrote: post #62
rmc wrote: post #52

Earlier quoted context omitted.

> If someone has MitM'd Google, it's gonna be a bad day for a lot of people. Didn't foreign government agencies already do that? (e.g. NSA?)

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.

Re: Chromium unconditionally downloads binary blob

#84

Post by rockdoe »

scbrg wrote: post #48
rockdoe wrote: post #3

I advise not reading that bug, some of the later comments will give you brain cancer. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51 Downvotes? So you agree with this? "I seriously consider the good faith of an such upstream which does these kinds of things" "But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or…

> Downvotes? So you agree with this? Whether we agree or not is not really relevant. Advising people to not read a bug report because one of the comments in the discussion associated with the report doesn't appeal to you is... strange, to say the least. How do you manage any kind of discussion format if opinions (however wrong they may be) you don't like make you leave the discussion entirely?

On the contrary, sometimes ignoring the discussion is the only way to stay sane and make progress because there are an infinite number of people with "opinions".

In this case the original report is informative, what comes after (up to 2 posts now) probably isn't going to be.

Re: Chromium unconditionally downloads binary blob

#85

Post by jimrandomh »

The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a.

This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it might instead accept instructions to transmit audio from particular parties that Google wants to spy on.

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.

This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android, twice: once with the "Play Service Framework", which is a collection of APIs added to Android but theoretically independent of it, and again with Google Glass, which ran an entirely closed-source fork. In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.

Re: Chromium unconditionally downloads binary blob

#86

Post by jug »

mortehu wrote: post #64
jug wrote: post #12

Earlier quoted context omitted.

Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.

While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.

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 Debian sounds like a pretty big one.

Re: Chromium unconditionally downloads binary blob

#87

Post by strcat »

jug wrote: post #86
mortehu wrote: post #64

Earlier quoted context omitted.

While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.

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.

Re: Chromium unconditionally downloads binary blob

#88

Post by strcat »

mortehu wrote: post #61
pilif wrote: post #45

Earlier quoted context omitted.

the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need. Check https://developer.chrome.com/native-client/c-api for a list of currently supported features. For other browsers to support PPAPI, they'…

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

Re: Chromium unconditionally downloads binary blob

#89

Post by strcat »

fluidcruft wrote: post #55
marrs wrote: post #46

Earlier quoted context omitted.

You mean, you couldn't compile it from source, modify the source code and distribute your modifications freely to others?

No, he means Chromium (like Android) in practice are read-only, hostile projects that respond only to Google's needs. Yes, you are free to create a fork. In reality, it's nearly impossible to keep up with Google's development pace and their behavior of dumping huge changesets and lack of documentation and communication wears everyone out. If you have some exposure to biology/ecology you'll recognize the behavior as v…

Unlike Android, Chromium is mostly developed in the open. As someone who has contributed to both projects, I wouldn't say Chromium is any less welcoming to contributors than Firefox. Mozilla is a lot better at presenting themselves in a positive light. Firefox even has similar automated downloaded of binary blobs like the EME plugin.

Re: Chromium unconditionally downloads binary blob

#90

Post by pcwalton »

mortehu wrote: post #61
pilif wrote: post #45

Earlier quoted context omitted.

the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need. Check https://developer.chrome.com/native-client/c-api for a list of currently supported features. For other browsers to support PPAPI, they'…

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

It's also not spec'd; there are many edge cases in the implementation that are undocumented and would have to be specified precisely in order to be implementable by others. Nobody has done that work so far.

Here's a random example bz pointed out from a few years ago: https://news.ycombinator.com/item?id=5452098

Post reply on HN