Presentations from within nested browsing contexts

[anssiko]

[Carved out into its own issue from https://github.com/w3c/presentation-api/issues/26#issuecomment-91708418]

@mfoltzgoogle says:

@avayvod In Chrome have been discussing how browser-initiated presentation interacts with multiple <iframe>s embedded in the controlling page. For now, we are only enabling browser-initiated presentation from the default presentation URL set in the top level document. However, there is a use case for allowing it from an embedded <iframe> for sites using a third party player to show a single piece of video (or other) content.

We have discussed possible solutions, including:

1. Having the <iframe> pass a URL to the parent document to set as the default presentation URL. The problem here is that the browser-initiated presentation session would go to the parent document, not the <iframe> that has the presentation control logic for the video player.
2. Picking an <iframe> DPU if none is set at in the parent. This may lead to surprising behavior for the user, since the user is expecting to present content related to the parent document, which cannot directly control the behavior of the <iframe>.
3. Allowing the user to choose from a list of default presentation URLs in the document. This complicates the UX for starting a presentation and it will be difficult for the user to make a meaningful choice (who provides the URL is an implementation detail of the webapp).

Instead we are considering adding a capability to the <iframe>'s sandbox attribute, "allow-default-presentation", that would allow the parent page to designate up to one iframe per document as the source of the default presentation URL for browser initiated presentation. This attribute would be respected only for <iframes> one level deep.

[anssiko]

The proposal by @mfoltzgoogle is aligned with the model employed by the Fullscreen API [1]. It is a good idea to reuse a model that is in use unless there are issues with it. Personally, I'm not aware of any, but I haven't deep dived into the Fullscreen API.

To summarize the proposal (assuming I got it right ;-)):

• Define a new allow-default-presentation content attribute for the HTML iframe element. In practice, something like this:

<iframe src="https://example.org/video/1234" allow-default-presentation></iframe>

• This content attribute must be set in order for the browser to be able to initiate a presentation from https://example.org/video/1234
• This prevents e.g. content from third parties to go fullscreen without explicit permission. A concern shared with the Fullscreen API [2].

Questions:

• Should we require the same for any startSession() invocation from within iframe? How about joinSession()?

Currently the spec notes in the 7.1 Starting a presentation session [3]:

Queue a task T to request user permission for the use of a presentation display and selection of one presentation display.

I think that for nested content we should in addition require that the top-level browsing context has explicitly opted in to allow iframes to initiate presentation sessions.

WDYT?

(From the spec organization perspective, this requires us to patch the HTML spec slightly, but we can cross that bridge when we get there.)

[1] https://fullscreen.spec.whatwg.org/#model [2] https://fullscreen.spec.whatwg.org/#security-and-privacy-considerations [3] http://w3c.github.io/presentation-api/#starting-a-presentation-session

[louaybassbouss]

What about using a single attribute allowpresentation not only for default URL:

<iframe src="https://example.org/video/1234" allowpresentation="none|any|default|{presentationURL}"></iframe>

• presentation is not allowed by default (default value for allowpresentation is none).
• allow any presentationURL if value of allowpresentation is any.
• allowpresentation="default" has the same effect as allow-default-presentation.
• a specific presentationURL can be used to specify the allowed presentation.

[markafoltz]

Reply to @anssiko:

To summarize the proposal (assuming I got it right ;-)):

Yes, that is exactly what I had in mind. The only detail is what to do when more than one <iframe> has the allow-default-presentation attribute and the UA initiates presentation. It could pick arbitrarily or allow the user to choose.

Should we require the same for any startSession() invocation from within iframe? How about joinSession()?

For joinSession() - no, the intent is that no new presentations can be started, only reconnection to existing presentations, so the risk seems low here.

For startSession() - my inclination is "no," although it would depend on how the user agent would be able to inform the user about which <iframe> was requesting presentation. For example, it would be not ideal to have an invisible <iframe> on a domain the user was not aware of be able to request presentation at any time.

To mitigate any confusion, we could require that the <iframe> meet the conditions of being able to show a popup [1] before it could invoke startSession().

I think that for nested content we should in addition require that the top-level browsing context has explicitly opted in to allow iframes to initiate presentation sessions.

Sounds good, after we decide on the attribute vs. allow popups conditions for allowing startSession() in <iframe>s.

[1] https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup

[markafoltz]

Reply to @louaybassbouss:

The concept of having the parent document restrict the presentation URL for an <iframe> could be useful. How would a presentation be initiated in this scenario? Would the script inside the iframe call startSession() with the same URL?

It seems like the any and default have the same effect, since the <iframe> could set its default presentation URL to any URL?

[anssiko]

ACTION: @hongkicha to update use cases to incorporate nested browser context issue [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action04]

ACTION: @mfoltzgoogle to flesh out behaviour of allow presentation attribute [recorded in http://www.w3.org/2015/05/20-webscreens-minutes.html#action05]

[anssiko]

[Edit: PROPOSED RESOLUTION reverted, for details, see the follow up discussion.]

PROPOSED RESOLUTION: define a new allowpresentation content attribute for the HTML iframe element that controls whether default-presentation, startSession(), joinSesssion() are functional; define failure path in the relevant algorithms when this attribute does not exist, clarify how multiple levels of nesting behaves

See relevant discussion during Berlin F2F: http://www.w3.org/2015/05/20-webscreens-minutes.html#item04

[markafoltz]

Unfortunately I have to object to this resolution as stated after further internal discussions within Google. Whitelisting the Presentation API to <iframe> elements with a new attribute will effectively make the API inaccessible to a large portion of presentable content embedded within existing Web content. In many cases the existing markup won't be upgraded by the author, because the embedding is done on her behalf by authoring tools, or they have lost access, or don't want to bother.

As a concrete example, consider the millions of YouTube videos embedded in blog posts. They use markup like the following:

<iframe title="YouTube video player" class="youtube-player" type="text/html" width="700"
    height="427" src="//www.youtube.com/embed/LzTM-iGs71U?..."
    frameborder="0" allowfullscreen=""></iframe>

(I've shortened the src for readability). These can be remoted today using Cast, and would not be able to remoted via Presentation API unless the blog template is modified, or the author manually edits the markup to add allowpresentation alongside allowfullscreen.

I checked two other popular video sharing sites - dailymotion.com and vimeo.com - and they will have the same issue as they provide <iframe> embedding code that is copy-pasted by the Web author.

I propose keeping this open and soliciting further proposals that allow existing embedded content to be presented, but perhaps limit access to some functionality, like receiving browser initiated presentation events.

[anssiko]

Given the new information from real world usage (thanks @mfoltzgoogle), I suggest we keep this issue open and explore alternative techniques that would maintain backwards compatibility with existing web content without compromising the user's security and privacy.

I'll start with a couple of proposals (not necessarily good ones) to restart the discussion:

• Expand (or patch) the semantics of the allowfullscreen attribute to allow also the Presentation API usage in addition to the Fullscreen API, if set to true. Technically, the content to be presented on a second screen is often fullscreen. By doing this, we'd lose the ability to say the nested content can be made fullscreen on the primary screen but not shown on any of the secondary screens, and vice versa.
• Leave it up to the implementation to ask for user's consent and make it explicit that nested content would like to present itself on a secondary screen. Would mean all the web pages with nested content out there could make use of the Presentation API. However, this behaviour would not be a testable assertion in the spec and to that end conformant but otherwise bad quality implementations might compromise users' security and privacy. Also, it may be hard to implement this in a way that a normal user does not get confused.

[markafoltz]

This seems like an appropriate topic for the F2F meeting in October.

[tidoust]

See feedback from the TAG on reusing the allowfullscreen attribute: [[ As currently specified, the presentation API is sufficiently different than the Fullscreen API that it would be unwise to piggy-back on the existing "allowFullscreen" attribute. ]]

Also: [[ 2.The act of presenting to a second screen seems very similar in principle to the ability for a particular element to requestFullscreen . The same security and privacy concerns related to the Fullscreen API likely apply to the Presentation API (such as restricting iframe content from starting a new presentation session unless granted explicit permission). While element-level presentation may not be desireable, the ability to "cast" content to a second screen does seem congruent with the Presentation API use cases. ]]

https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

[tidoust]

See relevant discussion at TPAC F2F: http://www.w3.org/2015/10/28-webscreens-minutes.html#item06

RESOLUTION: For #79, for security aspects idea is to improve on existing mitigation mechanism without new iframe attribute and get back to TAG and WebAppSec, for defaultRequest the idea is to postpone resolution while implementers experiment with different scenarios

[markafoltz]

Update:

After discussion within Chrome and also with a discussion with @sicking, we're proposing the following solution:

• There aren't any persistent permissions or threats posed by use of the API in embedded content. At best it will annoy the user by getting them to present content they don't want. The user remains in control to cancel the presentation when this happens.
• We should encourage best practices for identifying what content is requesting presentation in the browser UX.
• There should be a way for embedders that don't want presentation from content they embed to prevent that from happening. An allow-presentation tag in the sandbox attribute for <iframe> [1] would be an appropriate way to do that.

Should we bring this proposal back to TAG/WebAppSec and/or make the attribute proposal as a "patch" to HTML5 in the Presentation API spec?

[1] https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox

[sicking]

One thing we can do is to encourage UAs to specify the origin of the page calling .start() in the picker UI. Especially in case that origin doesn't match the top-level origin of the tab.

Seems like sticking something to that effect in the security section could be helpful.

[sicking]

...which is exactly what you said in the previous comment :)

[anssiko]

Hearing no concerns, @mfoltzgoogle please proceed as suggested and update the spec, considering also @sicking's feedback re the security section. In this first iteration we should be fine monkey-patching HTML spec in the Presentation API. However, should add an inline issue/note that we should upstream the patch to HTML if no concerns from TAG/WebAppSec to be looped in after the changes have landed.