Re: Request for feedback: Presentation API Working Draft

On 2015-07-02 15:49, Christine Runnegar wrote:
> 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?

Sure!

>
> 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.

I am out of office these weeks, of course ;) but I am confident that 
someone from the group will be able to attend. Could you ping us once 
the date is settled?


>
> What is your timeframe for collecting feedback?

That is a good question. This is not a Last Call (or a Last Call 
equivalent) so we did not set a deadline as such.

We wanted to raise these issues as soon as possible because they could 
potentially have large impacts on the specification, and we would rather 
deal with these potential impacts now.

The implicit deadline that we have in mind for closing as many issues as 
possible is TPAC, which means that collecting feedback by mid-September 
would give us time to prepare proposals before TPAC.

Thanks,
Francois.


>
> 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 16:32:27 UTC