[tor-bugs] #22548 [Applications/Tor Browser]: Firefox downgrades VP9 videos to VP8 when measured performance is not enough

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jan 5 14:52:22 UTC 2018

#22548: Firefox downgrades VP9 videos to VP8 when measured performance is not
 Reporter:  cypherpunks                          |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-fingerprinting,                  |  Actual Points:
  TorBrowserTeam201801R                          |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:

Comment (by tom):

 A few notes. I reviewed mozilla-central and -esr52.

 0: I agree, this is a hardware fingerprinting vector (albeit a small one,
 1 bit of info). We should set the pref either very high (disabling VP9 for
 everyone) or to 0 (enabling it for everyone). Telemetry indicates more
 users fall below the 150 fps choice than above:

 1: The correct place to put prefs is browser/app/profile/000-tor-
 browser.js It's best to keep the prefs all in one place. (Also see #4)

 2: Setting the pref does not enable vp9 on Android. That's probably fine,
 since all Androids will be hardcoded to false (no fingerprinting) and the
 point of disabling vp9 there is because it's not fast enough for phones.
 (True for -central and esr)

 3: Setting the pref doesn't enable it on Macs. Same problem, except Macs
 are hardcoded false because it spins up the fan and annoys people. (Only
 true for central) Maybe this #ifdef should be backported to esr52 for TB?
 If it is I think it should be a separate commit/patch to make rebasing
 easier (on rebase we can just drop the individual patch entirely.)

 4: The benchmark is skipped correctly when the pref is set manually.
 However, setting the pref in all.js means the pref won't have a user
 value, and the benchmark will be run. That's bad, so that's two reasons it
 should be in 000-tor-browser.js

 5: I assume, but never verified, that prefs set in 000-tor-browser.js are
 considered to 'have a user value'.

 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1428351 for upstream.

 Thanks for this work, I think once 1 is fixed, we should apply it. gk - do
 you want to backport the Mac hardcode in 3?

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

More information about the tor-bugs mailing list