[tbb-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
enough
-------------------------------------------------+-------------------------
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:
https://telemetry.mozilla.org/new-
pipeline/dist.html#!cumulative=0&end_date=2017-12-26&keys=__none__!__none__!__none__&max_channel_version=release%252F57&measure=VIDEO_VP9_BENCHMARK_FPS&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0
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 tbb-bugs
mailing list