How to filter available screens according to the content being presented

[markafoltz]

If we allow the page to filter the set of presentation screens based on capabilities, then more bits of more information would be revealed. This feature, if implemented, should take privacy into consideration.

It is an open issue whether to provide filter information as part of the request for notification of available screens. This could be useful when a particular application or capability is needed in order to display the contents of a presentation. One possible approach to this could be to provide the URL for the presentation and / or required options as part of the request for notification of available screens. If this was supported, only screens that satisfied the filter would trigger a notification.

[tidoust]

See relevant discussion at F2F:
http://www.w3.org/2015/05/20-webscreens-minutes.html#item02

PROPOSED RESOLUTION: For issue #9, include a URL parameter to "getAvailability" (subject to amendments to issue #81) and update security and privacy considerations section based on privacy investigation.

ACTION: Mark_Watson to look into privacy implications of filtering available screens according to the content being presented [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action03]

[mounirlamouri]

I believe this was taken care of. Closing.

[tidoust]

For reference, note the feedback from the TAG on this topic below, in particular the proposal to integrate the Permissions API and the request to have a "a user-controllable mechanism to purge/clear this data to avoid unwanted residual fingerprinting", which could warrant the creation of new issues on our side to address that feedback.

[[

There is no good fallback for the Presentation API in the case when there are no screens available. To ensure a good user experience, a web page must be able to tell whether a request to "startSession" is likely going to succeed before it offers the user the choice to present. That is the role of the "getAvailability" function.

The need to avoid or show in-page UI to the user depending on whether a feature may or may not be available to use, is the use-case of the Permissions API. It seems like integration of presentation API into permissions is prudent.

Without parameter, this function de facto reveals one bit of information on the user's context that could be used for fingerprinting, although this information will change depending on the user's context (on the go, with TV on/off, etc.).

The group notes that a generic true/false is not enough in many situations where the URL to present may require additional capabilities. That is the reason why the "getAvailability" function takes the URL to present as parameter, to allow the user agent to filter screens.

[Link to fingerprinting finding.] Indeed there may be more information that is necessary to reveal in order to negotiate a connection. We ask that any such information that may lead to fingerprinting be associated with a user-controllable mechanism to purge/clear this data to avoid unwanted residual fingerprinting.
]]
https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md