The receiving browsing context sets the sandboxed auxiliary navigation browsing context flag to prevent it from using e.g. window.open() to spawn new browsing contexts.

However we should also prevent top-level navigation (to protect integrity of the screen selection prompt) by setting the sandboxed top-level navigation browsing context flag. This also blocks window.close(), thus developers will have to call .terminate() for a presentation to close itself.

We can also set the sandboxed modals flag to prevent modal dialogs, which is suggested in a non-normative note, but not enforced. I don't feel as strongly about this however.

Setting sandboxed top-level navigation browsing context flag is indeed required to ensure integrity. The presentation is effectively a single-page application that must not be able to navigate. This should have been caught up in the security review, but better late than never. Good catch!

Looking at the sandboxed modals flag, it prevents content from using the following:

• window.alert()
• window.confirm()
• window.print()
• window.prompt()

Also the following, but IIUC, not relevant here:

• window.showModalDialog() - This is already disallowed by the sandboxed auxiliary navigation browsing context flag we set, and also not anymore in the sandboxed modals flag list in HTML LS, so probably a spec bug in 5.1).

• the beforeunload event - In terminate a presentation in a receiving browsing context we unload a document, thus this event is never fired when a presentation is terminated (the beforeunload event is only fired when a user agent is to prompt to unload a document).

@mfoltzgoogle @schien How do your implementations handle alert(), confirm, print(), or prompt()? How about we specify the implemented behaviour if it is consistent among known implementations.

In Chrome, all Javascript dialogs are suppressed from offscreen tab (1-UA) presentations.

In Firefox, open/alert/confirm/print/prompt will fail in receiver page, however, window.close will close the connection but not terminate the receiver page.

Thanks @schien and @mfoltzgoogle. Do your implementations also prevent top-level navigation in the receiving browsing context already?

If so, it seems setting both the sandboxed top-level navigation browsing context flag (was renamed to sandboxed top-level navigation without user activation browsing context flag in whatwg/html@8abd73e) and sandboxed modals flag would match the known implementations the closest.

IIUC, the only change needed to implementations to comply with the proposed spec changes would be to prevent content from closing their top-level browsing context, i.e. ignore calls to window.close() on the receiver page. To close, would need to explicitly invoke terminate(). (And if navigation is allowed, disallow it.)

I'm probably missing something but I find it strange to set the sandboxed top-level navigation browsing context flag on the receiving browsing context, given that it is a top level browsing context. As far as I can tell, HTML never does this, it only sets that flag on nested contexts.

Said differently, my understanding is that a browsing context can always navigate itself in practice, meaning it can for instance always call window.location.reload() to reload itself. This would be a no-op if the flag is set.

That may be what you want to achieve, but being able to navigate itself also seems needed to use the History interface. More precisely, the page may call pushState for in-app routing (as done in Backbone.js and other JS frameworks). In itself, this does not trigger any navigation. Now "user agents may discard the Document objects of entries other than the current entry" at any time, so calling go or back to traverse that history could potentially trigger a navigation. Setting the flag as suggested would make the application crash.

Re: #414 (comment)

Looking at our implementation, I don't believe we handle top-level navigations currently. Will file a bug to address that, and hopefully add a platform test to enforce it.

@tidoust Do these in-app routing frameworks expect new Document objects in the history when using the History API? Or are they just using it as a convenient way to store application state within the same Document?

The sandoxing navigation flag may indeed be the wrong one, but we need to spec navigation behavior somehow.

Re: #414 (comment)

In addition, does a modal dialog for HTTP authentication need to be disallowed in a receiving browsing context? IIUC, sandboxed modals flag does not care about it.

@mfoltzgoogle said:

Do these in-app routing frameworks expect new Document objects in the history when using the History API? Or are they just using it as a convenient way to store application state within the same Document?

That's the part I missed :) In my mental model, using pushState would create new Document objects in the history. That is not the case! In other words, navigating the history that the receiver app may create should always work with the flag set, and my previous comment is essentially moot.

If you can confirm setting the flag works implementation-wise, then all is good. If that's not known yet, we could check with Web Platform Working Group or WHATWG folks whether setting that flag in a top-level context is ok.

Also, looking at the spec, I would complete the note at the end of the "Creating a receiving browsing context" algorithm to refer to the sandboxed modals flag, e.g.:

"Given the operating context of the presentation display, some APIs will not work by design (for example, by requiring user input) or will be obsolete (for example, by attempting window management); the receiving user agent should be aware of this. Furthermore, any modal user interface will need to be handled carefully. The sandboxed modals flag is set on the receiving browsing context to prevent most of these operations."

It could also be worth referring to the sandboxed top-level navigation browsing context flag from the User interface guidelines sub-section of the Security and Privacy section.

@tomoyukilabs said:

In addition, does a modal dialog for HTTP authentication need to be disallowed in a receiving browsing context? IIUC, sandboxed modals flag does not care about it.

For me, the difference is that HTTP authentication is not something that the page itself can trigger. It sits at the protocol level which seems out of scope for the API (for instance, the HTML spec does not talk about HTTP authentication per se). The receiving user agent could ask the user for credentials if user interaction is possible. Or it may have obtained credentials through other means. Or it could simply fail to load the page.

Re HTTP authentication, I think @tidoust is right. For example, web views used to embed web content in native apps suppress HTTP authentication prompts per my experience, and simply fail (or display an empty page without any user visible error) if such a page is navigated to.

@tidoust and @anssiko Thanks for kind response!

Fixed in #415.

Following up on a couple of items to close out loose threads:

• Checking our implementation briefly, I believe that we can apply the sandboxed top-level navigation browsing context flag on a top-level receiving browsing context. This is in part because CSP Level 3 allows resources fetched with CSP to be sandboxed as well, including top-level resources [1]. We'll know for sure when we actually implement this [2].

• I will send a PR to add the non-normative text suggested by @tidoust in #414 (comment).

• I will see if there are any reported incompatibilities with using the History API in a sandboxed <iframe>, or, failing that, can whip up a demo.

• Regarding HTTP Auth, I believe Chrome will block that as part of other modal dialogs (and presumably fail the authentication request). Will check as part of fixing the implementation here.

[1] https://www.w3.org/TR/CSP/#directive-sandbox
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=697526