Tom Ritter:
On Wed, 6 Feb 2019 at 11:33, Tom Ritter tom@ritter.vg wrote:
I suppose step one is to make a fingerprinting test that identifies what codecs you can handle...
I started work on this; but got some tribal knowledge from jya and others: https://mozilla.logbot.info/media/20190206#c15931239-c15932085
Thanks for getting this started, really appreciated! What's the story on Android (given that we are not far away from shipping stable Tor Browser bundles to mobile users)?
Summarizing:
- Only AAC, h264, and vp9 may give different reports
I think it would still be good to verify that for other codecs and be it just to catch possible regressions.
AAC Mac - always there
AAC Windows - May not be present on Windows N or KN
AAC Linux - Missing if ffmpeg is missing
h264 Mac - always there. Almost always accelerated, except
"hackintosh with nvidia cards and the mac pro 2013 trashcan"
- h264 Windows - always there; but not hardware accelerated if your
GPU card is blocklisted
- h264 Linux - Missing if ffmpeg is missing or not compiled with h264
support. never hardware accelerated.
- vp9 Mac - Always present
- vp9 Windows - Always present, but may or may not be hardware
accelerated. If not hardware accelerated, you can roughly benchmark the machine using different video size inputs and the resulting output of the smooth value
- vp9 Linux - Always present
So by hardcoding a response for hardware acceleration and the smooth value; the only data we would leak would be information about your ffmpeg install (or lack thereof) on Linux; and on Windows whether you're missing the Media Framework (which is a good indicator of being a European user AIUI).
Yep. So, let's get started with that approach.
FWIW: I am not sure where we are with the Display Capabilities section of the spec but §4.2 seems to show the way forward with respect to the resist fingerprinting mode.
Georg