Re: [presentation-api] Allow page to turn itself into a presentation session

> Regarding the private browsing context - does it mean that the page 
loaded in a normal context would suddenly lose it because the user and
 UA decided to turn it into the presentation?

I take it that there is no easy way to "lose" the normal context 
status without reloading the page in a private browsing context, or is
 there?

I had devices such as a shared TV or a Chromecast dongle in mind for 
this feature, not necessarily *regular* user agents, and was thinking 
that them running on shared devices would mean that they would always 
load pages in a private browsing context. Is that the case in 
practice?

> How discovery would work - UA would advertise all user's pages as 
presentable?

So, that was the main purpose of my question on Chromecast. If I 
understand your reply correctly, devices that would want to join a 
presentation session running on a Chromecast device will not use 
discovery to learn about the presentation session, but some other 
means, typically what the spec refers to as the mechanism that would 
allow a page to become authorized to control a presentation session.

> Would listening to the  sessionavailable  event indicate that the 
page is presentation friendly?

That's a good point. Surely user agents would not want to advertise a 
page as presentable unless you know that it will accept messages from 
others.

I realize that I'm going to go beyond the scope of this issue and to 
touch upon mechanisms that are out of scope for the spec but I'm still
 unclear as to how connection to a running presentation session from 
another device will work in practice. I assumed the following steps in
 the general case with 3 user agents A, B, and C:

1. a page on A calls `startSession`, resulting in the creation of 
presentation session on C
2. B learns about the details of the presentation session running on C
 (URL and ID)
3. a page on B calls `startSession` with the same URL. B prompts the 
user, offering him the choice between creating a new session on C and 
connecting to the running session on C.

Now B can learn about the presentation details from A, or an online 
server that A interacts with, for instance through the user context if
 he is running Chrome and logged in on both devices. I'm not sure how 
B can learn anything from A if A and B are from different browser 
vendors (say, Chrome and Mozilla), as implicit in the [poker use 
case](https://github.com/w3c/presentation-api/blob/gh-pages/uc-req.md#uc03-multiplayer-gaming---poker).

Or B can learn from C directly through "discovery". That said, I would
 not want C to advertise the URL that it is presenting in plaintext on
 the local network either, at least not without my explicit consent, 
and even with it, that does not seem like a good idea. I understand 
that it is not the case in existing devices (DIAL devices, whatever on
 existing devices (DIAL devices, Chromecast, etc.), which seems a good
 thing.

C could perhaps advertise an encrypted version of the URL, using the 
presentation ID as secret to do the encryption. I think I already 
mentioned somewhere a proposal along these lines, see [Introduction to
 Secure DNS based Service 
Discovery](https://github.com/namedwebsockets/networkwebsockets/wiki/Introduction-to-Secure-DNS-based-Service-Discovery-(DNS-SSD)).
 However, for such a mechanism to work, the page running on B would 
need to be pass the presentation ID in the call to `startSession`. We 
resolved to drop the parameter during the F2F for lack of use cases 
but we can reintroduce it later on if needed as an indication that the
 user agent should "join a presentation with that ID if it exists".

Or perhaps B could learn through private exchanges with C if they have
 been previously "paired". But here as well, I would not want C to 
tell all paired devices that it has loaded a particular URL (for 
instance, C could be a video projector in a meeting room connected to 
the local network of a company and you may only want people in the 
room to know about the URL of the session being presented). In other 
words, I would prefer that all paired devices can prove that they know
 the presentation ID first.

Am I over-thinking the n:1 scenario or trying to restrict things that 
do not need to be?

Back to this specific issue, I would wait until the n:1 mechanism is 
clear and revisit that issue afterward, depending on the result and on
 people's interest to enable this.


-- 
GitHub Notif of comment by tidoust
See 
https://github.com/w3c/presentation-api/issues/32#issuecomment-108825599

Received on Thursday, 4 June 2015 10:14:49 UTC