Re: New Proposal now up for Discussion on the Wiki

One more comment on why we believe this is a better model than granting
permissions to devices; the list of devices is dynamic.  If you grant
persistent permission to the devices you have at the time (say Alice's Big
TV), and the site now uses this *without* showing the UA's device picker
every time, then when Alice buys a new Small TV and puts it in her bedroom,
the domain that was authorized to use Big TV will now never see Small TV.
 It would thus be necessary to have a "refresh permissions" type button
within the site UI to force a re-prompt (by the UA) so that Alice can grant
access to new devices.

This is particularly problematic depending on assumptions about persistent
identifiers for devices.  Factory resets, naming, even software updates
might change the identity of a device.  It is sometimes even preferable not
to allow devices to have truly persistent identifiers at a protocol level,
because this allows for correlation (specifically, the native Awesome Video
Player app for my mobile phone can now determine that my spouse and I see
same the uniquely identified device).  Regardless, the more dynamic the
device list is, the less it is appropriate to use a one-time selection of
permissions for a site.

Mark.



On Thu, Feb 6, 2014 at 11:20 AM, Mark Scott <markdavidscott@google.com>wrote:

> Allowing enumeration of devices, and for sites to draw their own device
> selection UI, was something that was supported in the preview SDK (which is
> what the current YouTube integration is based on).  It is not supported in
> the Cast SDK that's now been released, because we feel that this would
> require intrusive prompts to the user for any site that even has the
> possibility of supporting multi-screen operation.
>
> As Anton identifies above, the intent with Cast is to support the use of
> custom devices supplied by the site if it has additional out-of-band
> methods for supporting presentation that do not utilize the Presentation
> API.  We see minimal risk with this since as Anton notes, since the UA will
> never do anything other than returning the selection.
>
> Indeed, the only compelling reason for handling custom (site-specified)
> devices is to enable better UI where there is a single button used for
> multi-screen interaction vs. having one button for two-screen presentation
> supported by the UA and a separate button for two-screen interaction
> handled separately.
>
> Mark.
>
>
> On Thu, Feb 6, 2014 at 10:49 AM, Rottsches, Dominik <
> dominik.rottsches@intel.com> wrote:
>
>> Hi Anton,
>>
>> On 06 Feb 2014, at 12:38, Anton Vayvod <avayvod@google.com<mailto:
>> avayvod@google.com>> wrote:
>>
>>
>> If you connect a “controller" page to a YouTube page in TV mode [1], the
>> paired targets show up in a UI selection, along with the name of the
>> available Chromecast, as shown here:
>> http://roettsch.es/player_target_list.png
>>
>> This server requires a login when I click on the link. However, I think I
>> understand what you mean and thanks for reminding of this important use
>> case.
>>
>> I tested the Cast Chrome extension and YouTube in Chrome with multiple
>> Chromecasts, and they show up as entires with names in the page-embedded
>> YouTube selection dialog (even though the web-based Cast SDK does not allow
>> enumerating them).
>>
>> So, not only proprietary paired devices as in our Youtube.com/tv<
>> http://Youtube.com/tv> example, but also Chromecasts do show up in the
>> YouTube’s page selection UI.
>>
>> If your goal is to cover most Chromecast usage scenarios under
>> Presentation API, it seems to me that name-based enumeration would be
>> required.
>>
>> Dominik
>>
>>
>>
>>
>