1461454 - Support Resist Fingerprinting in canPlayType and Media Capabilities APIs

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, enhancement, P2)

Description

[Tom Ritter [:tjr] (OOTO until mid-August)]

The canPlayType and the Media Capabilities API can be used to learn information about a user's machine (such as whether certain codecs are hardware accelerated)

When Resist Fingerprinting Mode is active, we should standardize upon certain answers for queries to the Media Capabilities API (https://wicg.github.io/media-capabilities/), and through the canPlayType method (https://html.spec.whatwg.org/multipage/media.html#dom-navigator-canplaytype)

For more discussion, see https://groups.google.com/forum/#!topic/mozilla.dev.platform/jKWIKsOpUwc

Comment 1

[Steven Englehardt [:englehardt]]

A test page for `canPlayType`: (http://www.leanbackplayer.com/test/h5mt.html)

Comment 2

[Phabricator Automation]

Attachment: Bug 1461454 - Report that all supported content can play nice and smoothly when resisting fingerprinting is on.

That way we don't report anything unique to the machine. The media capabilities of the machine mostly depends on how firefox was configured and built for that machine, and as such not unique.
Also, reporting a media as not supported would make that machine stand out as telemetry has shown that the vast majority of users have the required external frameworks installed on windows and linux (on mac, it comes out of the box)

As such, we report if it can play a given content accurately. But we don't report on how well it can play.
This is likely to cause subpar playback experience with sites like YouTube that would send higher resolution that could be handled.

While we could immediately return the result as we know the final result ahead of time when resisting fingerprinting is turned on, we don't and follow the same code path such as timing is identical to a generic box.

Comment 3

[Ethan Tseng [:ethan]]

Tom, do we have update on this bug?

Comment 4

[Tom Ritter [:tjr] (OOTO until mid-August)]

Last email on subject was to Arthur:

> it sounds like there's no way to hide if a video/audio doesn't play and errors out.  So we should go with the very first plan and report (accurately) whether or not a user can play something; but if it can, always report that it can play it well ignoring user hardware. Do you agree?

Comment 5

[Arthur Edelstein [:arthur]]

Sorry for dropping the thread. Do we have data on what the user population is like for support of the various media types? It would be useful to know how bad the entropy is for users who don't support a specific media type. And I might consider the option of not supporting a particular media type if it is rarely used, in order to make users more uniform.

Comment 6

[Tom Ritter [:tjr] (OOTO until mid-August)]

So we finally determined a path forward for this; and the consensus is to report accurately whether or not something can be played but always report it plays smoothly and power efficiently.

I'm not quite sure how to implement it given the complexity of MediaCapabilities::MediaCapabilities and the goal of 'report accurately if it can be played.'

Comment 7

[sanketh]

Attachment: Bug 1461454 - In RFP Mode, Spoof Smooth=True and PowerEfficient=False for Supported Media in MediaCapabilities r?tjr

Uplifts Tor Browser patch for Tor Bug 13543 and adds a test.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/afea4945d5ae
In RFP Mode, Spoof Smooth=True and PowerEfficient=False for Supported Media in MediaCapabilities r=jya

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/afea4945d5ae