Re: How to filter available screens according to the content being presented (issue #9)

On Thu, Sep 11, 2014 at 11:16 AM, Mark Watson <watsonm@netflix.com> wrote:

> Hi Mark,
>
> Please see comments below ...
>
>
> On Thu, Sep 11, 2014 at 11:06 AM, mark a. foltz <mfoltz@google.com> wrote:
>
>> Hi Mark,
>>
>> I have been thinking about this problem since our last conversation.  I
>> understand the use case, but have some concerns about the specific approach
>> proposed, which I hope can be addressed by a carefully designed API.  My
>> concerns:
>>
>> (1) Screens may become available or unavailable over the lifetime of the
>> page.  To show or hide the presentation icon, the site would have to invoke
>> canRequestSession in a loop, if I understand correctly.  It seems like a
>> more natural API to use an event handler for this purpose.  The event
>> handler will still have the issue about whether (and when) to fire the
>> initial event, but avoids the use of polling loops to keep the web app user
>> interface in sync.
>>
>
> ​Yep. An event would be better.​
>
>
>>
>> (2) I worry that a site may use this API to gather information about
>> users, even fingerprint them, especially if there is known content that can
>> only be rendered by specific type(s) of devices.  This could be mitigated
>> by the following changes:
>>
>> (2a) Require user consent.  I don't like this.  This puts an obstacle in
>> front of the user that will potentially be confusing and irritating; when
>> actually presenting, the user will be prompted again by the browser to
>> select a screen.  The user may decline, which puts the site in a difficult
>> position of not knowing true availability.  Or the user may accept and make
>> it sticky, which then gives the site permission to query it at-will,
>> defeating the purpose of consent.
>>
>> (2b) Only allow queries for a restricted set of URLs, limited by
>> same-origin or some other policy.  I prefer this approach but makes the API
>> less powerful.
>>
>
> ​Seems reasonable, though there may be some gotchas with DIAL integration,
> especially for older devices. ​
>
>
>>
>> (3) On mobile devices, the UA may want additional control over when
>> discovery happens.  Adding a query API means the UA will need to either
>> discover continuously, or delay answering a query until the discovery
>> process starts and stabilizes.  It seems to add a layer of complexity to
>> implementation.
>>
>> (4) More of a question: Is there a use case for querying for more than
>> one URL per page?
>>
>
> ​Not that I can think of. I suppose you could imagine some kind of
> mash-ups that want to talk to several kinds of apps on multiple remote
> displays. But it seems reasonable to exclude such speculative use-cases for
> now.​
>
>
>>
>> ===========
>>
>> My proposal:
>>
>> - Propose an HTML5 meta-tag [1] that names a default presentation URL for
>> the document, say "presentation.defaultPresentationUrl"
>>
>> - If set, the UA will use that to determine when to fire
>> |onavailablechange| on NavigatorPresentation.  |onavailablechange| would
>> only be fired if a screen was able to present
>> |presentation.defaultPresentationUrl|.   If unset, default behavior for
>> |onavailablechange| applies.
>>
>> - |presentation.defaultPresentationUrl| must be same-origin with the
>> document.  This limits the ability for pages to script this API to gather
>> device capabilities or fingerprint users.
>>
>> This is a small change to the existing API and I believe it addresses the
>> concerns I outline above.  Would this meet the requirements you have in
>> mind?
>>
>
> ​It seems reasonable, modulo the DIAL integration issues with the
> same-origin thing. Do you mean CORS-same-origin, so that CORS headers on a
> response from the device would indicate which sites were allowed to
> interact with it ?​
>

It could.  If you are concerned specifically about DIAL integration, I
think a concrete proposal for what that would look like would help shape
this policy.  Specifically: How Presentation URLs would be mapped onto DIAL
application names, and how CORS would support cross origin interaction, if
necessary.

m.