Figure out what to do with OpenH264 (downloads) in Tor Browser

We should think about what we want to do with the OpenH264 video codec plugin which Firefox downloads since version 33 shortly after it gets started for the first time (see: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and https://wiki.mozilla.org/QA/WebRTC/OpenH264).

The good news is, the code is free: https://github.com/cisco/openh264. The bad news is it needs to get downloaded from Cisco as a binary blob due to patent issues. And there is currently now known way to build this binary blob deterministically: https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.

I think we should make sure that the plugin does not get downloaded as:

1. It is currently only used for WebRTC which we have disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make sure that this argument still holds for ESR 38 when we ship it if that matters)

2. The binary blob is not built reproducibly which poses security risks. Although there seems to be kind of a mechanism for Mozilla to verify things:

Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.

3. The download uses essentially Mozilla's "cert pinning". We might want to have something stronger in place.

...

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to disable the plugin download.

added component::applications/tor browser ff78-esr owner::tbb-team priority::medium severity::normal status::new type::task labels

Trac:
Description: We should think about what we want to do with the OpenH264 video codec plugin which Firefox downloads since version 33 shortly after it got started for the first time (see: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and https://wiki.mozilla.org/QA/WebRTC/OpenH264).

The good news is, the code is free: https://github.com/cisco/openh264. The bad news is it needs to get downloaded from Cisco as a binary blob due to patent issues. And there is currently now known way to build this binary blob deterministically: https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.

I think we should make sure that the plugin does not get downloaded as:

1. It is currently only used for WebRTC which we have disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make sure that this argument still holds for ESR 38 when we ship it if that matters)

2. The binary blob is not built reproducibly which poses security risks. Although there seems to be kind of a mechanism for Mozilla to verify things:

Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.

3. The download uses essentially Mozilla's "cert pinning". We might want to have something stronger in place.

...

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to disable the plugin download.

to

We should think about what we want to do with the OpenH264 video codec plugin which Firefox downloads since version 33 shortly after it gets started for the first time (see: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ and https://wiki.mozilla.org/QA/WebRTC/OpenH264).

The good news is, the code is free: https://github.com/cisco/openh264. The bad news is it needs to get downloaded from Cisco as a binary blob due to patent issues. And there is currently now known way to build this binary blob deterministically: https://bugzilla.mozilla.org/show_bug.cgi?id=1115874.

I think we should make sure that the plugin does not get downloaded as:

1. It is currently only used for WebRTC which we have disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=1150544#c8) (we should make sure that this argument still holds for ESR 38 when we ship it if that matters)

2. The binary blob is not built reproducibly which poses security risks. Although there seems to be kind of a mechanism for Mozilla to verify things:

Mozilla and Cisco have established a process by which the binary is verified as having been built from the publicly available source, thereby enhancing the transparency and trustworthiness of the system.

3. The download uses essentially Mozilla's "cert pinning". We might want to have something stronger in place.

...

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716 for a way to disable the plugin download.

Trac:
Summary: Figure out what to do with Open264H (downloads) to Figure out what to do with Open264H (downloads) in Tor Browser

Trac:
Summary: Figure out what to do with Open264H (downloads) in Tor Browser to Figure out what to do with OpenH264 (downloads) in Tor Browser

Trac:
Owner: tbb-team to gk
Keywords: N/A deleted, GeorgKoppen201506 added
Status: new to assigned

The download URL looks something like: http://ciscobinary.openh264.org/openh264-linux32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip

Yes, HTTP and no deterministic build. headdesk

Replying to gk:

The download URL looks something like: http://ciscobinary.openh264.org/openh264-linux32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip

Yes, HTTP and no deterministic build. headdesk

Aha, I've been too fast. It is basically the same infrastructure as the application updater: A server is contacted via HTTPS (aus4.mozilla.org in this case), an update.xml file is sent which contains the above mentioned URL and a SHA512 hash etc. (in case there is a version to be installed/updated)

https://bugzilla.mozilla.org/show_bug.cgi?id=1046644 indicates that flipping media.gmp-gmpopenh264.autoupdate might be enough to prevent the download of the plugin.

Tag the set of things we should aim to understand/fix for the fist FF38-based TBB (5.0a3, on June 30th).

Trac:
Keywords: N/A deleted, tbb-5.0a3-essential added

Ensure all tbb-5.0a items are on the June radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201506 added

bug_15910 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_15910) in my public tor-browser repo has a fix for this bug with some motivation for the implemented solution: we basically don't show GMPs at all on the Add-ons pane in order to not confuse users and make sure that update pings are not hitting the network.

I'd like to keep this bug open in order to revisit this decision for ESR 45.

Trac:
Status: assigned to needs_review

Replying to gk:

bug_15910 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_15910) in my public tor-browser repo has a fix for this bug with some motivation for the implemented solution: we basically don't show GMPs at all on the Add-ons pane in order to not confuse users and make sure that update pings are not hitting the network.

r=mcs I like the data URL solution.

Merged into ​https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH%2B1

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Let's keep this open for ff45-esr.

Trac:
Status: closed to reopened
Keywords: ff38-esr deleted, ff45-esr added
Resolution: fixed to N/A

Trac:
Keywords: GeorgKoppen201506, tbb-5.0a3-essential, TorBrowserTeam201506 deleted, N/A added

12:27:16.047 1458304036000	Toolkit.GMP	ERROR	GMPInstallManager.onLoadXML could not load xml: [Exception... "SSL is required and URI scheme is not https."  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: re[/gre/modules/CertUtils.jsm](/gre/modules/CertUtils.jsm) :: checkCert :: line 142"  data: no]1 Log.jsm:749:0	
12:27:16.050 1458304036000		Toolkit.GMP	ERROR	GMPInstallManager.simpleCheckAndInstall Could not check for addons: {"target":{},"status":200,"message":"[Exception... \"SSL is required and URI scheme is not https.\"  nsresult: \"0x8000ffff (NS_ERROR_UNEXPECTED)\"  location: \"JS frame :: re[/gre/modules/CertUtils.jsm](/gre/modules/CertUtils.jsm) :: checkCert :: line 142\"  data: no]"}1 Log.jsm:749:0

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/A

Dragging into May to have it on our 6.0 radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201605 added

This is still WebRTC only (see https://bugzilla.mozilla.org/show_bug.cgi?id=1057646). Moving this to ff52-esr to keep an eye on it.

Trac:
Keywords: ff45-esr deleted, ff52-esr added

Trac:
Username: tokotoko
Cc: N/A to fdsfgs@krutt.org

Replying to gk:

The download URL looks something like: http://ciscobinary.openh264.org/openh264-linux32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip

Yes, HTTP and no deterministic build. headdesk There are no MinGW URLs. They offer to build it yourself https://github.com/cisco/openh264#for-windows-builds.

As long as there are ports of the source code and automatic build scripts contributed as part of the open source, we do not see difficulties in adding additional platforms. http://www.openh264.org/faq.html

So only The Tor Project can teach Cisco to make deterministic binaries for all required platforms.

In Tor Browser 7.0a3-build4 the OpenH264 plugin is downloaded automatically in the background if automatic addon updates are enabled or if one checks for addon updates manually. In Firefox this happens because of a change in Firefox 50, citing the release notes (https://www.mozilla.org/en-US/firefox/50.0/releasenotes):

"The link to check for plugin security updates has been removed from the addon manager as Firefox automatically checks for plugin updates"

The plugin is saved under /Browser/TorBrowser/Data/Browser/profile.default/gmp-gmpopenh264. Note that the plugin is downloaded although I have

"media.gmp-manager.url.override" set to "data:text/plain," (default) "media.gmp-provider.enabled" set to "false" (default)

The plugin is not listed in about:addons or about:plugins because of the second option, so it is not used either, and I think WebRTC is deactivated anyway. But I wonder why it is downloaded. I don't know any other option to prevent the download, any of the two above work in Firefox as far as I know.

Trac:
Username: viktorj
Cc: fdsfgs@krutt.org to fdsfgs@krutt.org, viktor_jaegerskuepper@freenet.de

Replying to viktorj:

In Tor Browser 7.0a3-build4 the OpenH264 plugin is downloaded automatically in the background if automatic addon updates are enabled or if one checks for addon updates manually.

I have to correct this: It is downloaded even if automatic add-on updates are disabled, but it is NOT downloaded if one checks for add-on updates manually. The automatic download happens during the first minute in which Tor Browser is running. To see this, I disabled automatic add-on updates and automatic updates of Tor Browser after the start as fast as I could to confirm that these settings have nothing to do with it.

So it seems that there is something different going on to what I can observe in Firefox.

Trac:
Username: viktorj

Trac:
Keywords: TorBrowserTeam201605 deleted, tbb-7.0-must-alpha, TorBrowserTeam201704 added

override pref is still active in the codebase, and nothing is downloaded on Windows.

@viktorj: you can set extensions.logging.enabled to true and see in the Browser Console of a new clean installation what is happening during GMP update check.

Okay, the issue is that there is no a local fallback to contact the GMP download/update service. This is implemented with https://hg.mozilla.org/mozilla-central/rev/7c1929f35c5d. Thus, the browser thinks the download server is down (as we block this download) and is falling back to the new method. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1267495 for a more detailed discussion. I pushed this to tor-browser-52.1.0esr-7.0-2 to get the final build started (https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.1.0esr-7.0-2&id=72667935298e11ca5a0e2e5202a5d9e33981eedf).

mcs/brade: Could have a quick look at the patch (even if it is post factum)?

And this is no issue on Windows as we are not compiling with MSVC.

Trac:
Status: reopened to needs_review
Keywords: TorBrowserTeam201704 deleted, TorBrowserTeam201704R added
Cc: fdsfgs@krutt.org, viktor_jaegerskuepper@freenet.de to mcs, brade, fdsfgs@krutt.org, viktor_jaegerskuepper@freenet.de

Replying to gk:

Thus, the browser thinks the download server is down Does the proper server response spoofing (data:,<updates></updates>) solve your problem? And this is no issue on Windows as we are not compiling with MSVC. As they are not compiling for MinGW (for now ;).

Replying to gk:

mcs/brade: Could have a quick look at the patch (even if it is post factum)?

r=brade, r=mcs This looks like the correct fix.

Thanks. It seems we won't get it anytime soon for support (https://bugzilla.mozilla.org/show_bug.cgi?id=1057646#c18). Thus, only the WebRTC usecase remains. We are still disabling that one, though. Moving this on our ESR59 radar then.

Trac:
Owner: gk to tbb-team
Keywords: tbb-7.0-must-alpha, TorBrowserTeam201704R, ff52-esr deleted, ff59-esr added
Status: needs_review to assigned

Firefox 60 is the new ESR.

Trac:
Keywords: ff59-esr deleted, ff60-esr added

Replying to cypherpunks:

Replying to gk:

The download URL looks something like: http://ciscobinary.openh264.org/openh264-linux32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip

Yes, HTTP and no deterministic build. headdesk There are no MinGW URLs. They offer to build it yourself https://github.com/cisco/openh264#for-windows-builds.

comment:20 :

Q: If I use the source code in my product, and then distribute that product on my
own, will Cisco cover the MPEG LA licensing fees which I'd otherwise have to pay?

A: No. Cisco is only covering the licensing fees for its own binary module, and
products or projects that utilize it must download it at the time the product or
project is installed on the user's computer or device. Cisco will not be liable for
any licensing fees incurred by other parties. 

And? What's the problem to upstream deterministic builds to them?

Replying to cypherpunks:

And? What's the problem to upstream deterministic builds to them?

Yeah, I've been thinking about this a lot but then I did not want to support the MPEG LA licensing bullshit, so I dropped spending time on this one. But, generally, I guess if someone manages to build exactly the same binary that could be an option.

We should keep an eye on this one. While we are good for ESR 68, someone added a patch to https://bugzilla.mozilla.org/show_bug.cgi?id=1057646 which might turn into a proper support at some point.

Trac:
Status: assigned to new
Keywords: ff60-esr deleted, ff78-esr added

But, generally, I guess if someone manages to build exactly the same binary that could be an option. Somebody from Moz://a's Tier-2 MinGW support ;)

FWIW, the Android situation for Google Play store apps is described in https://bugzilla.mozilla.org/show_bug.cgi?id=1548679: Firefox is not downloading OpenH264 anymore because Google prohibits that as they want to be able to scan the whole app for malware (OpenH263 being automatically downloaded and installed being essentially a part of it).

mentioned in issue #16285 (moved)

moved to tpo/applications/tor-browser#15910