W3C home > Mailing lists > Public > public-secondscreen@w3.org > September 2015

Re: [presentation-api] How to filter available screens according to the content being presented

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Wed, 16 Sep 2015 09:56:50 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-140692394-1442397409-sysbot+gh@w3.org>
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.

GitHub Notif of comment by tidoust
Received on Wednesday, 16 September 2015 09:56:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:18:58 UTC