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.

the open h.264 blob thing is annoying, but it's supposed to be a reproducible build of open source software.

The reason why there's a blob is because for that binary, Cisco pays the patent licenses.

So you can verify the source for any issues, verify whether it matches the binary, and work around MPEG-LA licensing at the same time (there are caps, and Cisco seems to have calculated that even when running into them, they're still better off with having webrtc support h.264 everywhere).

Firefox's blob is open source, though (OpenH264 is on Github and is BSD-licensed).

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

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.

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.

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)