>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?
Probably so, yes. We could reduce but not eliminate the exposure by rate-limiting requests (perhaps even on a sliding scale, allowing a small number before delays are introduced). This is likely insufficient as a mitigation, however. >If autoplay is eventually blocked by default could we gate the response of >this API on user interaction with the media element? That might be possible, but if so it should be discussed in the spec and how to get "real" data after user interaction. (Perhaps giving fake data until user interaction, but then one needs to warn developers about this, and how to get real data when interaction occurs reliably.) -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
