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

171–180 of 180 posts

Re: Chromium unconditionally downloads binary blob

#171

Post by CamperBob2 »

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…

Has anyone filed a US-CERT report with Homeland Security on this?

"Yeah, we know. It's ours. Don't worry about it. Go about your business. Pick up that can, while you're at it."

Re: Chromium unconditionally downloads binary blob

#172

Post by mgiuca »

cactusface wrote: post #170
mgiuca wrote: post #169

Earlier quoted context omitted.

Hi, I'm an engineer from Google responsible for the hotword module. I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not…

Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.

We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time.

The fact is that an end user should not care if software downloads a "binary blob" without running it. This is functionally equivalent to downloading anything from the Internet, a JPG file for example. Chromium downloads a bunch of things on startup, and nobody seems to mind. Just because hotword.nexe happens to be an executable blob doesn't really make a difference.

Re: Chromium unconditionally downloads binary blob

#173

Post by cactusface »

mgiuca wrote: post #172
cactusface wrote: post #170

Earlier quoted context omitted.

Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.

We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time. The fact is that an end user should not care if software downloads a "binary blob" without running it. This is funct…

So a picture isn't a picture until you look at it?

Whether or not people should care, some people do care. If Debian has to edit what you distribute to remove proprietary parts of it, you're probably not distributing something that is open source (which means 100% open source).

Re: Chromium unconditionally downloads binary blob

#174

Post by uptown »

mgiuca wrote: post #172
cactusface wrote: post #170

Earlier quoted context omitted.

Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.

We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time. The fact is that an end user should not care if software downloads a "binary blob" without running it. This is funct…

"The fact is that an end user should not care if software downloads a "binary blob" without running it."

Is that the official position of Google? Reminiscent of when Thomas Hesse from Sony stated: "Most people, I think, don't even know what a rootkit is, so why should they care about it?"

Re: Chromium unconditionally downloads binary blob

#175

Post by pknight »

castell wrote: post #59
longsleep wrote: post #10

Another reason to switch to Iridium Browser. It has Google search disabled by default and even if you switch search to Google, Voice search and hot-words stay off until you manually enable it. https://iridiumbrowser.de/

another one is "Iron browser"

Which is not to be trusted in the slightest

Re: Chromium unconditionally downloads binary blob

#176

Post by riddly »

mgiuca wrote: post #172
cactusface wrote: post #170

Earlier quoted context omitted.

Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.

We probably could delay it until the setting is enabled. I wasn't on the team when that decision was made, but I would imagine it's because a) latency (we want the feature to be enabled right away when you turn it on), and b) just the way it happened and nobody really thought much about it at the time. The fact is that an end user should not care if software downloads a "binary blob" without running it. This is funct…

Functionally equivalent to a .jpg how? You mean by the fact that the .jpg is an executable set of instructions telling the system to eavesdrop on me?

Great point. Sure, I get it. By that logic, sending me a mail bomb (and of course, not activating it, because I mean who would do such a thing after painstakingly creating it?) is the same as sending me flowers.

Re: Chromium unconditionally downloads binary blob

#177

Post by pix64 »

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.

http://andreasgal.com/2014/10/14/openh264-now-in-firefox/

Re: Chromium unconditionally downloads binary blob

#178

Post by Manishearth »

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

Hello is just a thin wrapper around WebRTC (an open protocol)

Pocket is just a button that does a couple of AJAX calls to the Pocket site.

Both do have closed source code online, but when you click them it's pretty obvious that they are talking to some online service which may or may not snoop. You even have this "danger" when using Sync in any browser. In all these cases it's very clear what's going on.

When you use Pocket you know that the URL of the page you were visiting was sent to some service. When you use Hello you know that some routing service might be able to snoop on your call (I believe there's some encryption here though, but I'm not sure). When you use Sync you know that you're sending data to the server.

When you enable "Ok Google" detection in an open source software one would expect that the "Ok Google" detection is done locally in open source, verifiable code, and only after this detection is triggered, will sound be sent to the server. If this blob was instead some open source code, one would be able to verify that sound is only sent to the server when it is expected. But now that it's a blob, you don't have this guarantee. It could theoretically send periodic sound snippets to the server without you noticing, since it's listening on the microphone all the time.

That's the difference. Firefox's proprietary integration has verifiable triggers. It won't talk to a proprietary service unless you ask it to, and when it does you can verify what data it is sending.

On the other hand, this blob has no verifiable triggers. Yes, it is disabled by default (verifiably, apparently), but when enabled the data it collects and sends is not verifiable.

(Firefox also does have some blobs -- one for H.264, but the code behind it is open source, the blob is distributed for licensing reasons, and one for EME, but the EME blob is downloaded only with a confirmation which informs the user what is going on)

Re: Chromium unconditionally downloads binary blob

#180

Post by sqeaky »

mehrdada wrote: post #146
sqeaky wrote: post #108

Earlier quoted context omitted.

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.

Its not about what I am thinking. I never said anything about my thoughts on it. Perhaps I think computer security can be improved with liberal applications of butter and jelly or something equally ridiculous.

The people in question think it is an issue. They do this because of their starting point.

Post reply on HN