Re: Request for feedback: Presentation API Working Draft

Thanks for reaching out Francois,

Might you or others from the Second Screen Working Group be available to join a Privacy Interest Group (PING) teleconference (usually held once a month on a Thursday at UTC 14) to introduce the specification and some of the issues you have already identified? 

We haven’t fixed a date yet for the next teleconference as there will be an informal f-2-f meeting of PING and friends alongside IETF 93 in Prague on 23 July 2015, but it is likely to be on 6 or 13 August 2015.

What is your timeframe for collecting feedback?

Christine and Tara

> On 1 Jul 2015, at 4:34 pm, Francois Daoust <fd@w3.org> wrote:
> 
> 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:
> 
> http://www.w3.org/TR/presentation-api/

> 
> 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:
> 
> https://lists.w3.org/Archives/Public/www-tag/2015Jul/0001.html

> 
> 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:
> https://github.com/w3c/presentation-api/issues/45

> 
> 
> 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:
> https://github.com/w3c/presentation-api/issues/9

> 
> 
> 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:
> https://github.com/w3c/presentation-api/issues/45

> 
> 
> 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:
> https://github.com/w3c/presentation-api/issues/20

> 
> Thanks,
> Francois.
> 
> [1] http://www.w3.org/2001/tag/doc/promises-guide#rejections-should-be-exceptional

>

Received on Thursday, 2 July 2015 13:49:54 UTC