Opened 4 years ago

Last modified 16 months ago

#15910 assigned task

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

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr
Cc: mcs, brade, fdsfgs@…, viktor_jaegerskuepper@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by gk)

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.

Child Tickets

Change History (29)

comment:1 Changed 4 years ago by gk

Description: modified (diff)

comment:2 Changed 4 years ago by gk

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

comment:3 Changed 4 years ago by gk

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

comment:4 Changed 4 years ago by gk

Keywords: GeorgKoppen201506 added
Owner: changed from tbb-team to gk
Status: newassigned

comment:5 Changed 4 years ago by gk

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

Yes, HTTP and no deterministic build. *headdesk*

comment:6 in reply to:  5 Changed 4 years ago by gk

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)

comment:7 Changed 4 years ago by gk

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.

comment:8 Changed 4 years ago by mikeperry

Keywords: tbb-5.0a3-essential added

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

comment:9 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201506 added

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

comment:10 Changed 4 years ago by gk

Status: assignedneeds_review

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.

Last edited 4 years ago by gk (previous) (diff)

comment:11 in reply to:  10 Changed 4 years ago by mcs

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.

comment:12 Changed 4 years ago by arthuredelstein

Resolution: fixed
Status: needs_reviewclosed

comment:13 Changed 4 years ago by gk

Keywords: ff45-esr added; ff38-esr removed
Resolution: fixed
Status: closedreopened

Let's keep this open for ff45-esr.

comment:14 Changed 4 years ago by mikeperry

Keywords: GeorgKoppen201506 tbb-5.0a3-essential TorBrowserTeam201506 removed

comment:15 Changed 3 years ago by bugzilla

Severity: Normal
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 :: resource://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 :: resource://gre/modules/CertUtils.jsm :: checkCert :: line 142\"  data: no]"}1 Log.jsm:749:0

comment:16 Changed 3 years ago by gk

Keywords: TorBrowserTeam201605 added

Dragging into May to have it on our 6.0 radar.

comment:17 Changed 3 years ago by gk

Keywords: ff52-esr added; ff45-esr removed

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.

comment:18 Changed 2 years ago by tokotoko

Cc: fdsfgs@… added

comment:19 in reply to:  5 Changed 2 years ago by 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 Changed 2 years ago by cypherpunks

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.

comment:21 Changed 2 years ago by viktorj

Cc: viktor_jaegerskuepper@… added

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.

Last edited 2 years ago by viktorj (previous) (diff)

comment:22 in reply to:  21 Changed 2 years ago by viktorj

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.

comment:23 Changed 2 years ago by gk

Keywords: tbb-7.0-must-alpha TorBrowserTeam201704 added; TorBrowserTeam201605 removed

comment:24 Changed 2 years ago by cypherpunks

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.

comment:25 Changed 2 years ago by gk

Cc: mcs brade added
Keywords: TorBrowserTeam201704R added; TorBrowserTeam201704 removed
Status: reopenedneeds_review

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.

comment:26 in reply to:  25 Changed 2 years ago by cypherpunks

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

comment:27 in reply to:  25 Changed 2 years ago by mcs

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.

comment:28 Changed 2 years ago by gk

Keywords: ff59-esr added; ff52-esr tbb-7.0-must-alpha TorBrowserTeam201704R removed
Owner: changed from gk to tbb-team
Status: needs_reviewassigned

Thanks. It seems we won't get it anytime soon for <video> 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.

comment:29 Changed 16 months ago by gk

Keywords: ff60-esr added; ff59-esr removed

Firefox 60 is the new ESR.

Note: See TracTickets for help on using tickets.