- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Sep 2015 09:56:50 +0000
- To: public-secondscreen@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 See https://github.com/w3c/presentation-api/issues/9#issuecomment-140692394
Received on Wednesday, 16 September 2015 09:56:51 UTC