Allow page to turn itself into a presentation session

[tidoust]

Proposal

Enable a Web application to turn itself into a Presentation session so that it can be discovered by others. A possible technical solution would be to use a meta element.

For instance, to turn a Web application into a public Presentation Session:
<meta name="presentation" />

To turn a Web application into a private (or invitation-only) Presentation Session:
<meta name="presentation" content="[[presentationId]]" />

Use case

A user starts a Web application on her Smart TV from the usual TV remote that displays family pictures and videos in the background. While the application runs, her child opens the same application on his tablet, joins the running presentation application on the Smart TV and adds pictures and comments to the slideshow.

What is not possible right now

The Web application started on the Smart TV cannot advertise itself as a presentation session since it got started as a "regular" application.

Note it becomes possible as soon as the Web application on the Smart TV is started from another device using the Presentation API, but the goal is to avoid that step.

Could this be implemented at the UA level?

Not likely in the generic case.

The UA could propose a "start this application as a presentation session" menu item, but this is unlikely to serve any useful purpose in most of the cases as applications that will be able to be started as such will be exceptions-to-the-rule (at least for some time to come!).

The UA could perhaps detect whether the JavaScript of the application makes use of Presentation API interfaces before proposing that choice, but it's easy to use obfuscate code in JavaScript and hide the code to Presentation API interfaces.

In a packaged app environment, the application could also perhaps request to be run as a Presentation session in a manifest file.

Requirement

The receiving UA must provide a means for a Web application to turn itself into a presentation session that may discovered by others.

A few open questions

• The UA only becomes a "receiving" UA once a Presentation session is started. Question is whether any browser implementing the Presentation API should also support becoming a receiving end (linked to the definition of "conformance classes" in the spec). Probably not.
• Should the page also have a programmatic way of requesting to be turned into a presentation session (to prevent connection attempts as long as they are not wanted) or should that be left to the app itself?
• The feature has security implications. The user may not want to advertise an app as discoverable on a public network for instance.

References

See initial email on Second Screen Presentation WG mailing-list:
http://lists.w3.org/Archives/Public/public-webscreens/2014Nov/0011.html

[mfoltzgoogle]

Re-reading the public-webscreens@ thread - there seem to be two possible behaviors that need to be clarified:

1. Do we need a mechanism for a presentation to tell the user agent that its session is "discoverable/joinable" or not.
2. One possible way to implement Multi-display support #1 is for the presentation to (re)-assign a random presentation id to its active PresentationSession, which would prevent additional connections from being made. (The running presentation would be responsible for sharing this new id with existing connected sessions if it wants them to be able to reconnect.)

[tidoust]

Summary of casual discussion during F2F wrap-up session: there may not be a need for a page to explicitly turn itself into a presentation session. The user agent could do that on its own (or asking for user permission first). The only part that may need to be adjusted to enable that use case is how the presenting page gets a pointer to the first session if it can be created after the page is loaded.

ACTION: @tidoust to investigate possible adjustments to the spec to allow a presenting page to detect when the first session is created in that case.

• Closed with https://lists.w3.org/Archives/Public/public-secondscreen/2015May/0146.html

[tidoust]

Also note that the page needs to run in private browsing mode for the user agent to be able to turn it into a presentation session.

[tidoust]

I took an action to investigate possible spec adjustments that would be needed for that issue, if any. In the end, I do not think that there needs to be any normative adjustment to the spec to enable the use case if we drop the presentationId from startSession as agreed as part of the discussion on issue #39 (Resumption of multiple sessions).

When a user loads a Web page on a user agent that can act as a presenting user agent, the user agent may automatically allow external devices to connect to that Web page using the Presentation API. The Web page may ignore all incoming messages if it does not want to become a presenting page, otherwise it can listen to the sessionavailable event on navigator.presentation to be notified when an external user agent connects to it, as agreed to resolve issue #19 (Specify behavior when multiple controlling pages are connected to the session).

As noted in a previous comment, for the user agent to be able to turn a Web page into a presentation session, the Web page would already need to run in the right private browsing mode.

In summary, to resolve the issue, I would propose to:

1. add a statement along the lines of "A presenting user agent MAY expose any Web page it loads in a private browsing context as a presenting browsing context" to make it clear that this is an acceptable behavior; and
2. complete the spec with informative guidelines on the implications of what "exposing" may entail when we have a clearer picture.

I'm using "private browsing context" here to mean the restricted context that the spec is likely going to mandate on presenting user agents.

There is one privacy question that remains but it also applies to the multiple controlling pages case: how can an external user agent know that there is a presentation session running on the presenting user agent for that URL? Will the presenting user agent advertise the URL on the local network for instance?

The charter notes that the mechanism by which other user agents become authorized is out of scope. As with security considerations, we may still need to write implementation guidelines once we have practical experience on the topic to ensure that implementers understand possible implications.

@mfoltzgoogle, @avayvod: Who can tell which URL is currently loaded in Chromecast? Everyone on the local network? Only paired devices?

[avayvod]

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? How discovery would work - UA would advertise all user's pages as presentable? Would listening to the sessionavailable event indicate that the page is presentation friendly?

Re: Chromecast, I believe one can get an idea what is presented from the MediaRouter.RouteInfo description but can't really get any specific information (e.g. that a particular page is running there) nor request the discovery to filter the devices by the page they are running already.

[tidoust]

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.

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. 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.

[avayvod]

I think the issue can be resolved with a Promise returning method on the NavigatorPresentation instead of the session property (as agreed in the solution for #19 ). If the page calls the method (e.g. getSession()) it means it now switched to the presentation mode and is willing to accept connections and environment restrictions. The UA could also present user with a permission prompt if it's an interactive UI and the page wasn't running in an incognito context / started as a response to some page trying to present to the screen.

To join the presentation started from A, B only needs to know the URL, not id. Id is needed for resuming/joining a session (vs. presentation) started from the same UA. We agreed to remove id from startSession(). Selecting the right screen is on the user - if my friends and me decided to play a game together, one starts the game on the TV, others select the same device and the game presentation should be able to accept connection from game clients.

A shared TV could have a browser or an interactive webapp (e.g. Spotify) that can be used without presenting (via remote control / TV's touch screen). Now I may want to allow my guests to connect to the screen to add their music to the queue using Presentation API but don't want any info saved - so while the page has connections from other clients, it shouldn't be able to save or remember anything. Perhaps we should have a method similar to opening a window for the page to become a presentation... So the interactive page calls this method and its presentation version is loaded in the incognito context and is ready to be connected to. We may want the initial page to be able to message the presentation one turning it into a special case of the Presentation API :)

[tidoust]

@avayvod said:

To join the presentation started from A, B only needs to know the URL, not id.

I think I'm starting to get what I misunderstood ;) I had assumed that we wanted the following user prompt to be possible on B:

Hello user, this page is willing to present [[url]] on a second screen.
What do you want to do?
 1. start a new session on C
 2. connect to the session already running on C

... that is, to let the user on B decide whether to start a new presentation or to connect to the running session on C. For that to be possible, on top of knowing the URL, B would also need to know that C is actually running a presentation session for that URL. In the generic case, that would mean C advertising the URL on the network.

But that is not what will happen. Instead:

• on B, the user prompt will just contain "connect to C"
• it is up to C to connect the incoming request to the running session or to create a new one (or possibly to prompt the user if such an interaction is possible)

There is no need for C to advertise anything. Is that correct?

If need arises, we may always add an optional boolean parameter to startSession later on that says "start a new session", so that the user prompt on B could propose:

 1. connect to C (and start a new session)
 2. connect to C (and join running session if there's one)

A shared TV could have a browser or an interactive webapp (e.g. Spotify) that can be used without presenting (via remote control / TV's touch screen). Now I may want to allow my guests to connect to the screen to add their music to the queue using Presentation API but don't want any info saved - so while the page has connections from other clients, it shouldn't be able to save or remember anything. Perhaps we should have a method similar to opening a window for the page to become a presentation... So the interactive page calls this method and its presentation version is loaded in the incognito context and is ready to be connected to. We may want the initial page to be able to message the presentation one turning it into a special case of the Presentation API :)

And so couldn't this be done with window.open already (at least from a technical perspective, UX might be another issue)? The interactive Webapp could open a page that turns itself into a presentation session that others connect to.

[tidoust]

Now that I come to think about it, why would we need to force the incognito mode if the page that wants to turn itself into a presentation is already loaded on the shared device?

I think this mode was meant to protect a user starting a presentation from another device, but if a user already agreed to load a URL on a shared device, cannot the page stick to whatever browsing context it was loaded on when it turns itself into a presentation? What does this prevent?

[anssiko]

I marked the @tidoust's associated action as closed (thanks!).

It appears to me we should should keep this issue open and see where the discussion leads us.

[tidoust]

For reference, see related discussion at TPAC

[mfoltzgoogle]

Going to re-review this for possible followup at TPAC.

[mfoltzgoogle]

From https://www.w3.org/2017/11/06-webscreens-minutes.html#x18:

ACTION: @anssiko to add v2 feature in #32 provisionally to the Charter 2018

[anssiko]

Since the draft Charter 2018 links to examples of features that may be integrated [into Presentation API Level 2] -- including this issue -- we agreed at the closing Revisit Charter 2018 F2F session that we do not need to explicitly enumerate v2 features in the charter.

[mfoltzgoogle]

@igarashi50 - this looks like the most relevant issue to the comment you made at the Berlin F2F:

Last TPAC, I asked whether the API would support connection to existing devices. Web application is already running on the TV, and user connects to the page running on the TV.

Since this is tagged as a V2 feature, it will have to be incubated outside the WG until the Open Screen Protocol reaches a greater level of maturity. However, I can open an issue on Open Screen Protocol to ensure the control protocol is compatible with this use case.