[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

#16285: Make sure EME is no tracking risk in Tor Browser
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-linkability, GeorgKoppen201705,  |  Actual Points:
  TorBrowserTeam201705, ff68-esr, tbb-no-        |
  uplift-60                                      |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by sysrqb):

 For 68esr, it looks like we are still good here. We don't need the adobe
 prefs anymore (since Bug
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1329543 1329543]).

 From #31880, 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 [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/firefox.js?h=tor-
 browser-68.1.0esr-9.0-2#n194 not defined]:
 `media.gmp-widevinecdm.visible` and `media.gmp-widevinecdm.enabled`


 and `browser.eme.ui.enabled` is `false` [https://gitweb.torproject.org
 /tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-
 browser-68.1.0esr-9.0-2#n194 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
 [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-
 browser-68.1.0esr-9.0-2#n215 overwritten]as `false`.

 If, in addition to these prefs, `media.eme.enabled` is false and the CDM
 is not ClearKey, then the code path [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccessManager.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n102 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,
 [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccess.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n115 MediaKeySystemAccess::GetKeySystemStatus]
 returns `MediaKeySystemStatus::Cdm_not_supported`, and
 [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccessManager.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n117 MediaKeySystemAccessManager::Request] returns
 without resolving the Promise.

 On Android, it's more interesting. #31880 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16285#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs