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

Request for feedback: Presentation API Working Draft

From: Francois Daoust <fd@w3.org>
Date: Wed, 01 Jul 2015 16:34:15 +0200
Message-ID: <5593FA67.8020903@w3.org>
To: public-privacy@w3.org
CC: "public-secondscreen@w3.org" <public-secondscreen@w3.org>
Dear Privacy Interest Group,

The Second Screen Working Group has published an updated Working Draft 
of its Presentation API, which enables web content to access external 
presentation-type displays and use them for presenting web content:


While the spec should not be regarded as final yet, we would like to 
request feedback from this group on a few privacy-related issues that 
the group is trying to balance.

Please note that the group already asked the TAG for feedback on some of 
these issues, see thread, which includes more details on the current 
status, at:


The group will also get in touch with the Web Security IG.

1. Private mode browsing for the presenting context
While the controlling device will be a "private" device, the presenting 
device will often be a "shared" device, perhaps a TV set or HDMI dongle 
in a household, or a remote screen in a meeting room. To protect the 
controlling user's privacy, the group is considering requiring the 
presenting user agent to load the presentation URL in private mode.

See end of discussion in:

2. Fingerprinting and screen availability monitoring
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.

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.

See relevant discussion in:

3. Security and privacy considerations
The group tried to draft a security and privacy considerations section 
based on an evaluation of the spec. Do you have comments or suggestions 
regarding that section?

Also, see the evaluation in:

4. Rejecting the Promise when user cancels the screen selection
Following a call to "startSession", the user agent will prompt the user 
with a screen picker UI. If the user dismisses that prompt, the Promise 
returned by the call to "startSession" will be rejected with an 
"AbortError". This seems to follow the guidelines written in "Writing 
Promise-Using Specifications" [1].

The group also considered leaving that promise unresolved to protect the 
user's privacy. What is your take on this?

See related discussion in:


Received on Wednesday, 1 July 2015 14:34:24 UTC

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