Should we remove VideoDisplayConfiguration?

[gregwhitworth]

Note: I'm only moving this to issues so that we can track the resolution for ease of searching in the future

Another issue presented in PR #124 was provided by @chcunningham regarding this IDL definition of a VideoDisplayConfiguration:

dictionary VideoDisplayConfiguration {
  required unsigned long width;
  required unsigned long height;
  required boolean hasHdrCapabilities;
};

I think we actually don't need a config/info style here anymore - you could just make width/height/hdrSupported attributes of window.screen.video. IIRC the method comes from earlier thinking when we thought we were going to be querying for more granular features like colorGamut, for which an attribute doesn't work as well. With those gone it seems silly to have a method.

@gregwhitworth responded:

It's best to keep this as a query due to the fingerprinting analysis that we did earlier which will allow mitigations if necessary.

@chcunningham responded:

can you give more details? what mitigations can we provide via method that would not be possible for the attributes?

Taking a fresh look at the fingerprinting sections now...

Because these features require directly calling asynchronous Web APIs, they are very detectable by the UA, and does not represent risk of passive fingerprinting.

UA is no less aware of calls on attributes. Maybe the thinking was that attributes in JS are just simple read-only attributes all the way down. But, at least for WebKit based UAs, this is never the case; C++ doesn't have this style of attribute. For example: take

If an implementation wishes to implement a fingerprint-proof version of this specification, it would be recommended to fake a given set of capabilities (ie. decode up to 1080p VP9, etc.) instead of returning always yes or always no as the latter approach could considerably degrade the user’s experience. Another mitigation could be to limit these Web APIs to top-level browsing contexts. Yet another is to use a privacy budget that throttles and/or blocks calls to the API above a threshold.

I don't think any of these mitigations require a method?

[jernoble]

What is the use case for the device pixels width and height? When I heard a similar use case it was for content providers who want to deliver contents whose resolutions exactly match the raw display pixel resolution. And frankly, that is a question for CSS, as they’re the group that handles these kinds of questions, and the implications are broader than just video elements; image providers may have the same use case!

So, is there some other use case where a device might be able to decode media at a specific resolution and yet be unable to display it?

EDIT: I see that Greg opened up issue #133 to talk about this very thing. Moving this discussion there.

[vi-dot-cpp]

@chcunningham Based on comments in the past, I believe that asynchronous query-based APIs limits passive fingerprinting, which is among best practices recommended by the PIG. Please correct me if I misunderstand.

[gregwhitworth]

This was discussed in today's telecon: https://www.w3.org/2019/10/02-mediawg-minutes.html

Here is the resolution:

Convert hdrSupported to static accessor

This also implies that we will get rid of VideoDisplayConfiguration completely for now.

[chcunningham]

All, please see related issue #135 (just filed).

[vi-dot-cpp]

PR #124 was updated to convert hdrSupported to an attribute. Thanks for pointing out the subtleties about fingerprinting with regards to asynchronosity.

[chcunningham]

See resolution above