> > On 14 May 2018, at 6:47 pm, Tom Ritter <t...@mozilla.com> wrote: > > > > It seems like this will reveal a lot of information about the user's > > hardware. Does the Resist Fingerprinting preference disable the API or > > report standardized results? If not, can we get that bug on file (and > > if it's easy, point out exactly where we would want to add the 'if() > > return false'?) > > > > -tom > > This is a concern that has been raised previously, and one that you can > ultimately get with existing APIs, but those are typically after the fact, > and by then it’s already too late to allow the user to have a decent media > playback experience > > Existing canPlayType can tell you if we support a particular codec or not. > During playback, we already expose various metrics (starting from bug > https://bugzilla.mozilla.org/show_bug.cgi?id=580531) this became an > official spec, to determine if the content plays well : number of frames > dropped, number of frames decoded, how many were painted etc... > > As such MediaCapabilities doesn’t expose much more than what someone can > already gather over time with what’s already existing. >
Not a domain expert, so I'd like to make sure I understand the difference between what was possible with `canPlayType` + Media Statistics and what is possible with Media Capabilities. Please correct me if I have it wrong! Previously, a script wanting to fingerprint the user would have had to (1) probe content type/codec support with `canPlayType`, (2) play videos using each of these configurations, (3) measure and compute metrics for each configuration using the media statistics API. With Media Capabilities, a script still needs to probe each content type/codec pair (i.e., they can't retrieve a list of all supported codecs?), and will receive a classification of whether the device supports it, is expected to play the video smoothly, and is expected to play the video in a power efficient way. If my understanding is correct, Media Capabilities does expose quite a larger fingerprinting surface in practice. While it may have been theoretically possible for all trackers to gather statistics on video playback for each configuration, the only scripts that could practically carry out those attacks without degrading user experience would have been video providers. This will be especially true if browsers start blocking autoplay by default (https://bugzilla.mozilla.org/show_bug.cgi?id=1376321), since users will never interact with media elements from fingerprinting scripts. With the Media Capabilities API, it seems that a script like fingerprintjs2 (https://github.com/Valve/fingerprintjs2) could run through a big list of types/codecs and retrieve device information regarding smoothness and energy efficiency with relatively little overhead? If autoplay is eventually blocked by default could we gate the response of this API on user interaction with the media element? > To get around fingerprinting, at the user’s choice, the obvious work > around would be to report that everything is always supported, will always > do so smoothly with great battery savings. This is something we already do > for the existing apps. The user will end up with a poor video experience > however. As it will typically be served content not always adapted to his > machine capabilities. > It would be great to have the "fingerprint-proof" mode described in more detail in the spec. That will go a long way to making sure the protection implemented in RFP / Tor Browser doesn't break sites and provides the best possible performance given the restrictions. > Providing a way to ensure the user will get a good video experience is > paramount IMHO. Watching video on their web browser is what people do the > most… > > JY > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
