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

91–100 of 180 posts

Re: Chromium unconditionally downloads binary blob

#91

Post by strcat »

rockdoe wrote: post #82
mavhc wrote: post #71

Earlier quoted context omitted.

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.

The sandbox binary uses setuid root if user namespaces aren't available, but that's a necessity for making the empty chroot and process/network namespaces used to sandbox tabs. The layer-2 sandboxing code (seccomp-bpf) doesn't require anything like that, but they're meant to be complementary (although both are strict enough that they could act as a meaningful sandbox alone).

Re: Chromium unconditionally downloads binary blob

#93

Post by ceejayoz »

ackalker wrote: post #78
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 don't have google's keys Assumptions, assumptions.

Yeah. Spies have regularly provided data, for free or minimal compensation, to nation-state actors. Sometimes, this is information they know will result in the deaths of others. Often, the very act of doing it may result in the death of the perpetrator if caught.

Appeal to patriotism, a few million bucks, and immunity from prosecution? Surely someone highly placed at AppGoogAzonSoft is susceptible to that.

Re: Chromium unconditionally downloads binary blob

#94

Post by strcat »

codazoda wrote: post #53
zoner wrote: post #50

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

There's a comment there indicating that FF has done the same in the past with an H.264 blob. The conspiracist in me wonders why both these major browsers have downloaded and maybe executed binary blobs. Is it purely a convenience feature in the browser? Is it a secret order? That last question would have been silly a decade ago but we all know it's entirely possible now.

Firefox has similar code to download the proprietary EME plugin but it prompts the user about it first, which Chromium could be doing here.

Re: Chromium unconditionally downloads binary blob

#95

Post by strcat »

fla wrote: post #77

Any idea what is the executable doing ?

It's an extension running in the usual extension sandbox with permission to access the microphone. It's the "Ok, Google" implementation. It's a proprietary blob so you'd need to reverse engineer it to figure out exactly what it's doing.

Re: Chromium unconditionally downloads binary blob

#96

Post by ChrisClark »

belorn wrote: post #37
simoncion wrote: post #30

Earlier quoted context omitted.

Isn't the blob downloaded from Google's servers over a HSTS and cert-pinned TLS connection?[0] If someone has MitM'd Google, it's gonna be a bad day for a lot of people. From my POV, the thing that's actually bothersome about this issue is that a closed-source blob is automatically inserted into a project that I -and others- had understood to be completely open-source. The fact that the Chromium Google Hotword code w…

Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection. Secret downloads has the problem to display certification errors and similar things to the users, so they would likely have to reimplemented quite a few code paths to make that work properly. https and tls is also not mentioned in either bug threads, which is a worrying sign. If it uses TLS, then the bug is less…

But this isn't a 'secret' download. Google isn't trying to hide it at all, it's just a feature for the browser. So there is no reason to try to avoid problems associated with certificate errors.

Re: Chromium unconditionally downloads binary blob

#97

Post by laumars »

jimrandomh wrote: post #85

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…

> 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 statement and that the statement originates from someone on Google's payroll to begin with.

If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.

edit: s/Google Chrome/Chromium/g

> 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

Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.

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

Did you do a write up of this study? I'd be interested to read it :)

Re: Chromium unconditionally downloads binary blob

#98

Post by qwe123 »

laumars wrote: post #97
jimrandomh wrote: post #85

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…

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

Re: Chromium unconditionally downloads binary blob

#99

Post by pessimizer »

magicalist wrote: post #76
fluidcruft wrote: post #55

Earlier quoted context omitted.

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…

> No, he means Chromium (like Android) in practice are read-only, hostile projects that respond only to Google's needs. Huh? You've obviously never involved yourself in Chromium development. It's easy to get started and to stay up to date. As with all massive projects it takes work to do so, but no more so than any of the other open source browsers.

Have you had a lot of experience in keeping your Chromium fork up to date?

Re: Chromium unconditionally downloads binary blob

#100

Post by anon3_ »

laumars wrote: post #97
jimrandomh wrote: post #85

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…

> 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 only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.

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?

Post reply on HN