Make sure EME is no tracking risk in Tor Browser

The EME architecture got uplifted to Firefox 37 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) and is included in ESR 38 as well. We should make sure there are no accompanying tracking/fingerprinting risks. The best plan is probably to disable EME as Mozilla is doing in its ESR 38 release. We may need a custom patch as Mozilla is basically enabling it

#if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr

While we may want to take a deeper look at it when we switch to ESR 45 we should make sure that everything related to EME is really disabled if the respective prefs are set to false.

added GeorgKoppen201705 in Legacy / Trac TorBrowserTeam201909 in Legacy / Trac component::applications/tor browser in Legacy / Trac ff78-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-linkability in Legacy / Trac tbb-no-uplift-60 in Legacy / Trac type::task in Legacy / Trac labels

Trac:
Description: The EME architecture got uplifted to Firefox 37 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) in is included in ESR 38 as well. We should make sure there are no accompanying tracking/fingerprinting risks. The best plan is probably to disable EME as Mozilla is doing in its ESR 38 release. We may need a custom patch as Mozilla is basically enabling it

#if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr

While we may want to take a deeper look at it when we switch to ESR 45 we should make sure that everything related to EME is really disabled if the respective prefs are set to false

to

The EME architecture got uplifted to Firefox 37 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) in is included in ESR 38 as well. We should make sure there are no accompanying tracking/fingerprinting risks. The best plan is probably to disable EME as Mozilla is doing in its ESR 38 release. We may need a custom patch as Mozilla is basically enabling it

#if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr

While we may want to take a deeper look at it when we switch to ESR 45 we should make sure that everything related to EME is really disabled if the respective prefs are set to false.

Another option would be trying to not compile it in at all in the first place which would allow us to get rid of the gmp-clearkey system which is used for testing purposes only anyway.

Trac:
Keywords: N/A deleted, GeorgKoppen201506 added

https://bugzilla.mozilla.org/show_bug.cgi?id=1144903#c4: ac_add_options --disable-eme ftw!

Replying to gk:

https://bugzilla.mozilla.org/show_bug.cgi?id=1144903#c4: ac_add_options --disable-eme ftw!

But hsivonen has a point (in https://bugzilla.mozilla.org/show_bug.cgi?id=1144903#c16):

If you want to persuade streaming providers not to use *DRM*, it's probably easier to persuade them to move to Clear Key, which is Free Software-implementable non-DRM encryption, which is technically equivalent to HLS with keys in the clear, which is already familiar to the providers and makes stream ripping with curl or wget take more effort, than to persuade them to drop media file-level encryption completely as the first step. In that sense, having the anti-DRM constituency use a browser that doesn't have Clear Key makes it harder to get streaming providers to make a shift off-DRM, which is presumably what the anti-DRM constituency wants!

https://support.mozilla.org/en-US/kb/enable-drm has some decent info. The bottom line is there is only EME on Windows Vista+ and as we don't build any sandbox on Windows and the sandbox is needed for EME we won't get it to run on Vista+ either. Thus, I'll go with the idea in comment:4 and audit the result. As mentioned in the description we want to revisit this during the preparation for ESR 45 when we have fixed legacy/trac#16010 (moved) and https://bugzilla.mozilla.org/show_bug.cgi?id=1136707 got solved by Mozilla.

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_16285 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_16285) in my tor-browser repo has the two commits needed to fix this bug. The backport of the Mozilla patch is required for fixing a build bustage on Windows if we use the --disabl-eme-switch.

The more general GMP related issues (like not contacting the GMP update server) will be handled in legacy/trac#15910 (moved).

We should leave that ticket open (and adapt its subject) to revisit developments happening up to and including ESR 45.

Trac:
Keywords: TorBrowserTeam201506 deleted, TorBrowserTeam201506R added
Status: new to needs_review

Looks good to me. r=mcs

I guess we probably don't need to set all those prefs to false (because we will compile with --disable-eme), but better to be safe (and I did not look at how the prefs are used in Mozilla's code).

Replying to mcs:

Looks good to me. r=mcs

I guess we probably don't need to set all those prefs to false (because we will compile with --disable-eme), but better to be safe (and I did not look at how the prefs are used in Mozilla's code).

Yeah, I mentioned the purpose of disabling the prefs in my commit message. Might not have been obvious enough. bug_16285_v3 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_16285_v3) has the reasoning now in the prefs file (as well).

Replying to gk:

Yeah, I mentioned the purpose of disabling the prefs in my commit message. Might not have been obvious enough. bug_16285_v3 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_16285_v3) has the reasoning now in the prefs file (as well).

I think I must have skimmed over the commit message earlier because it did not really register in my brain. Sorry about that. In any case, your new comment in the prefs file makes things 100% clear.

I have merged this patch to https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH%2B1

gk, can you check that I've handled the conflict correctly?

Replying to arthuredelstein:

I have merged this patch to https://github.com/arthuredelstein/tor-browser/commits/tb_GECKO380esr_2015050513_RELBRANCH%2B1

gk, can you check that I've handled the conflict correctly?

Looks good.

Trac:
Keywords: ff38-esr, TorBrowserTeam201506R deleted, ff45-esr, TorBrowserTeam201506 added
Summary: Make sure EME is no tracking risk in Tor Browser based on ESR 38 to Make sure EME is no tracking risk in Tor Browser
Status: needs_review to assigned

Cleaning the tags off this if we're going to keep it open until ff45-esr.

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

Dragging into May to have it on our 6.0 radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201605 added

Trac:
Keywords: N/A deleted, tbb-6.0-must added

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Keywords: GeorgKoppen201506 deleted, GeorgKoppen201605 added
Description: The EME architecture got uplifted to Firefox 37 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) in is included in ESR 38 as well. We should make sure there are no accompanying tracking/fingerprinting risks. The best plan is probably to disable EME as Mozilla is doing in its ESR 38 release. We may need a custom patch as Mozilla is basically enabling it

#if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr

While we may want to take a deeper look at it when we switch to ESR 45 we should make sure that everything related to EME is really disabled if the respective prefs are set to false.

to

The EME architecture got uplifted to Firefox 37 (https://bugzilla.mozilla.org/show_bug.cgi?id=1137045) and is included in ESR 38 as well. We should make sure there are no accompanying tracking/fingerprinting risks. The best plan is probably to disable EME as Mozilla is doing in its ESR 38 release. We may need a custom patch as Mozilla is basically enabling it

#if !defined(MOZ_UPDATE_CHANNEL) || MOZ_UPDATE_CHANNEL != esr

While we may want to take a deeper look at it when we switch to ESR 45 we should make sure that everything related to EME is really disabled if the respective prefs are set to false.

Replying to gk:

https://support.mozilla.org/en-US/kb/enable-drm has some decent info. The bottom line is there is only EME on Windows Vista+ and as we don't build any sandbox on Windows and the sandbox is needed for EME we won't get it to run on Vista+ either. Thus, I'll go with the idea in comment:4 and audit the result. As mentioned in the description we want to revisit this during the preparation for ESR 45 when we have fixed legacy/trac#16010 (moved) and https://bugzilla.mozilla.org/show_bug.cgi?id=1136707 got solved by Mozilla.

Neither legacy/trac#16010 (moved) nor the Mozilla bug are fixed yet. Thus, I postpone revisiting our current decision. So far, for ESR45, we are still good with the things we currently have in place.

Trac:
Keywords: ff45-esr, tbb-6.0-must deleted, ff52-esr added

Trac:
Keywords: TorBrowserTeam201605 deleted, TorBrowserTeam201606 added

There have been quite some changes in EME-land since esr45. macOS and Linux have now DRM support as well and it seems EME is treated differently build-wise: now it is only disabled by pref: https://bugzilla.mozilla.org/show_bug.cgi?id=1300654. That might be related to clearkey getting built now even if we specify --disable-eme` in the .mozconfig file (adding exposure to security vulnerabilities: https://www.mozilla.org/en-US/security/advisories/mfsa2016-77/). And there is a different download path available in case AUS is down: https://bugzilla.mozilla.org/show_bug.cgi?id=1267495.

That's just mentioning the "top highlights". We need to have a close look at EME for esr52.

More tickets for 7.0.

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Moving tickets onto our alpha radar.

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

Trac:
Keywords: TorBrowserTeam201606, GeorgKoppen201605 deleted, GeorgKoppen201705, TorBrowserTeam201705 added

We are beyond the alpha testing. Moving tickets for tbb-7.0-must.

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

bug_16285_v4 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_16285_v4) has three patches that adapt our code to the EME changes done between esr45 and esr52. The major change is that we don't have a switch for not compiling the code in in the first place anymore. Instead everything is bound to preferences now (even though --disable-eme is still available and should set the proper defaults).

Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201705R added

r=brade, r=mcs This looks good to us.

Thanks. Applied to tor-browser-52.1.1esr-7.0-1 (commit 100fea03, e948ae5d, and ba7cbd18) and tor-browser-52.1.0esr-7.0-2 (commit 62546181, 46d6d3a5, and 726b6d69). Moving this ticket off our esr52 radar to the one for esr59.

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

Seem I forgot to remove the library stripping we do in the Linux descriptor. This is fixed with commit e8d869e142439436104b8b1f8b807406fd68e104 on master.

Replying to gk:

Seem I forgot to remove the library stripping we do in the Linux descriptor. This is fixed with commit e8d869e142439436104b8b1f8b807406fd68e104 on master.

Which needed a fixup, sigh: commit c18c6f80c49d7da97d006d3fd5201b11f1312bbc.

Firefox 60 is the new ESR.

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

Trac:
Keywords: N/A deleted, tbb-no-uplift-60 added

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

For 68esr, it looks like we are still good here. We don't need the adobe prefs anymore (since Bug 1329543).

From legacy/trac#31880 (moved), we found --disable-eme still prevents enabling EME on desktop builds. When EME is enabled (using --enable-eme), the content decryption module (CDM) must be specified. Mozilla only support --enable-eme=widevine in 68esr.

By default, the following prefs are not defined: media.gmp-widevinecdm.visible and media.gmp-widevinecdm.enabled

and browser.eme.ui.enabled is false by default.

When configured with --enable-eme=widevine, then media.gmp-widevinecdm.visible, media.gmp-widevinecdm.enabled, and browser.eme.ui.enabled are set true.

We set --disable-eme on desktops and these prefs are overwritten as false.

If, in addition to these prefs, media.eme.enabled is false and the CDM is not ClearKey, then the code path aborts early and it doesn't download the file from a remote server.

If the CDM is ClearKey and these prefs are false, then on desktop, MediaKeySystemAccess::GetKeySystemStatus returns MediaKeySystemStatus::Cdm_not_supported, and MediaKeySystemAccessManager::Request returns without resolving the Promise.

On Android, it's more interesting. legacy/trac#31880 (moved) didn't yield any interesting results because nothing is changed at compile-time. Fennec and GeckoView use the Android system DRM support when it is available. This is controlled separately by media.mediadrm-widevinecdm.visible.

I'll write a fixup patch that removes the old Adobe CDM prefs and adds the Android pref.

I pushed bug16285_68esr_00 for review.

Trac:
Status: assigned to needs_review
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201910R added

Thanks, looks good to me. Merged to tor-browser-68.1.0esr-9.0-2 (commit b34d1fab).

Trac:
Keywords: TorBrowserTeam201910R, ff68-esr deleted, ff76-esr, TorBrowserTeam201910 added
Status: needs_review to new

Trac:
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201909 added

ff78-esr

Trac:
Keywords: ff76-esr deleted, ff78-esr added

mentioned in issue legacy/trac#19048 (moved)

mentioned in issue legacy/trac#26144 (moved)

moved from legacy/trac#16285 (moved)

added Task label and removed 1 deleted label

added Linkability label and removed 1 deleted label

added 1 deleted label

removed milestone %Tor Browser: 10.0

mentioned in issue fenix#40141 (closed)

added 1 deleted label and removed 1 deleted label