Re: New Proposal now up for Discussion on the Wiki

Hi Dominik,

but in the attack you described the UA won't do anything other than showing
the user a string so the website won't gain much from the user selecting
its screen. The user will see a dialog, select a spoof device and then the
video won't play where the user expects while the website could already be
playing anything on the custom device it controls without any UA
intervention at all.

The extra work for the website to add custom screens seems much smaller to
me than implementing the whole screen selection UI and the use case also
seems pretty rare. It probably concerns a few big sites like
YouTube/Netflix who have the resources to support its own
discovery/messaging infrastructure while the majority of the use cases
would be to present on something that's available.

This way the UA exposes less information to the site at a time. User will
have to present to each of her screens to provide the full enumeration. It
also combines the permission dialog with the selection: user permits to
discover and use the device by selecting it.

In your scenario, the user will have to go through the permission dialog
first and then through the site's custom selection dialog, do I understand
it right? And if I want to watch a YouTube video on a TV in my living room,
I will most probably just allow discovering and accessing only the living
room TV and then select the TV. Now I went to the kitchen and want to watch
another YouTube video on the kitchen TV, how do I trigger the permission
dialog again to select the kitchen TV?

Anton.

P.S. I think my email client is fine, it seems it's actually the Dominik's
reply that killed the > characters: compare
http://lists.w3.org/Archives/Public/public-webscreens/2014Feb/0002.html and
http://lists.w3.org/Archives/Public/public-webscreens/2014Feb/0003.html.
The last replies from Dominik look fine though.


On Thu, Feb 6, 2014 at 4:21 PM, Rottsches, Dominik <
dominik.rottsches@intel.com> wrote:

> Hi Anton,
>
> > On 06 Feb 2014, at 17:53, Kostiainen, Anssi <anssi.kostiainen@intel.com>
> wrote:
> >
> >> On 06 Feb 2014, at 17:23, Anton Vayvod <avayvod@google.com> wrote:
> >>
> >>> Hi Anssi,
> >>>
> >>> yes, I meant the selection dialog that the UA shows to the user.
> >>
> >> This would be problematic as it would enable spoofing attacks.
> >
> > Could you describe the attack you have in mind, please?
>
> What I think he means here is that the page could inject device names that
> would be or trying to match the the ones you physically have at home and
> potentially try to trick the user into redirecting the stream elsewhere.
>
> Generally, allowing data originating from JS or the content into the
> Browser chrome is risky, since there are different concepts of the user's
> trust in what happens on the page level and what happens on the Browser UI
> level.
>
> On 06 Feb 2014, at 17:23, Anton Vayvod <avayvod@google.com> wrote:
>
> > var extraPresentationScreens = [ 'Extra Screen 1', 'Extra Screen 2' ];
> // the site was paired with these devices in some proprietary way so it
> manages the list and the way to connect to the devices separately from the
> presentation API
> >
> > // the site subscribes to the discovery event, toggling the 'Button'
> button on/off depending on when the device is available;
> > // with the extra devices being available, the button will always be
> toggled on
> > var discovery = navigator.presentation.discoverScreens("
> http://example.com/player.html");
> > discovery.ondiscovered(screensAreAvailable) {
> >   if (screensAreAvailable)
> >     // show the UI to start presenting, like enable or add a button
> >   else
> >     // hide the UI to start presenting, like hide or disable the button
> > }
> >
> > // when the user clicks/taps the present button
> > var presentationPromise = present.requestShow('
> http://example.com/player.html', extraPresentationScreens); //
> extraPresentationScreens is an optional parameter
> > presentationPromise.then(
> >         function (session) {
> >              if (session.isExtraDevice)  // or lookup session.screenName
> in extraPresentationScreens
>
> Thanks for the code example and clarifications. Much clearer now.
>
> In my opinion such an approach would not be a clean solution from an API
> design point of view. Piping the additional screens through the discovery
> process is problematic in terms of API semantics: We're not technically
> discovering those additional screens, in fact we know they exist already.
> And later checking whether they were actually passed in, does not seem very
> clean to me.
>
> Wouldn’t you perhaps agree that the enumeration and a page-side selection
> would be the cleaner, more straight-forward approach?
>
> Are there concerns from your side allowing discovery and enumeration by
> name with regards to privacy or permissions handling?
>
> If we would define the permission that the UA requests from the user as a
> dialog requesting:
> “The page is requesting access to the following screens: [  ] Living Room
> [   ] Kitchen … “
>
> Then we could return an enumeration including names without privacy
> concerns and avoiding bothering the user with a two-stage permission
> dialog: One for discovery, one for access.
>
> Regards,
>
> Dominik
>
>
>