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

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 ?​

​...Mark​



>
> [1] http://wiki.whatwg.org/wiki/MetaExtensions
>
> m.
>
>
>
>
>
> On Wed, Sep 10, 2014 at 11:03 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>> All,
>>
>> This issue is all about ensuring that the user is not presented with a
>> "present" icon which, when clicked, does nothing because there are in fact
>> no available screens supporting the content.
>>
>> The issue suggests one approach, whereby the UA can be instructed to
>> filter the available screens to those supporting specific provided URLs.
>>
>> Another approach would be to provide a new method:
>>
>> Promise<bool> canRequestSession( DOMString url );
>>
>> This would take exactly the same parameters as requestSession, but rather
>> than prompting the user it would return a prediction of whether there would
>> be any screens to prompt the user with. The application could avoid showing
>> the "present" icon if there are in fact no suitable screens.
>>
>> ...Mark
>>
>
>