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 TorBrowserTeam201909 component::applications/tor browser ff78-esr owner::tbb-team priority::medium severity::normal status::new tbb-linkability tbb-no-uplift-60 type::task 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 #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 #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 #16010 (moved) and https://bugzilla.mozilla.org/show_bug.cgi?id=1136707 got solved by Mozilla.

Neither #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