A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Iframe sandbox improvments
Overview
This document proposes two behavioral changes for sandboxed <iframe>
elements, each governed by a new sandboxing keyword.
Use Case
Folks who embed third-party widgets via <iframe>
elements are often interested in reducing the privilege of those embedded documents in various ways in order to protect themselves and their users from those with malicious intent. The sandbox
attribute is a natural fit here, as it prevents embedded-but-untrusted content from acting in a number of ways counter to the embedder's intent.
Auxiliary Windows
Advertisers, in particular, deal with large amounts of untrusted code, and would be interested in sandboxing third-party content in order to prevent things like top-level navigation from an <iframe>
and access to document.cookie
and similar storage APIs. sandbox
gives them this capability, but ties it to other restrictions that they can't accept.
The most critical of these restrictions is the fact that sandboxing flags "inherit" out to new windows created from within the sandboxed frame. This is, of course, an important part of the sandbox: if new windows could easily escape the sandbox's restrictions, they'd be fairly trivially bypassed. It makes sandboxing unusable for ads, however, because the advertised landing page can't (and shouldn't) be sandboxed in the same way as the embedded advertisement. While it might be reasonable to prevent the advertisement from accessing storage mechanisms, it would be fairly devastating to impose the same restrictions on the page being advertised.
Modal Dialogs
Dialog windows popped up in response to JavaScript methods like alert()
and prompt()
are sometimes difficult for a user to contextualize. Malicious third-parties intentionally use these kinds of mechanisms in order to create confusion, and convince users to take actions against their best interests.
sandbox
doesn't currently allow an embedder to protect themselves from this kind of abuse. Again, folks combating malicious advertisement would benefit from a mechanism which provided this functionality.
Proposal
Auxiliary Windows
This proposal adds a sandbox propagates to auxiliary browsing contexts flag to the sandboxing flag set defined in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.
This flag is set when parsing a sandboxing directive, unless the allow-unsandboxed-auxiliary
keyword is present.
If the flag is present when opening a new auxiliary browsing context (for example, via window.open
or target="_blank"
, then:
- The new browsing context's sandboxing flag set will not be populated from the opening document's active sandboxing flag set.
- The newly created browsing context will disown its opener.
Further, if window.open
is used to open the new browsing context:
- The
name
argument towindow.open
is always interpreted as_blank
. window.open
will continue to returnnull
in the case in which the new window's creation is blocked (via a popup blocker, for instance)window.open
will returntrue
if a window is successfully opened.
Modal Dialogs
This proposal adds a sandboxed modals flag to the sandboxing flag set defined in https://html.spec.whatwg.org/multipage/browsers.html#sandboxing-flag-set.
This flag is set when parsing a sandboxing directive, unless the allow-modals
keyword is present.
If the flag is set, alert()
, confirm()
, prompt()
, and print()
will be neutered inside of a sandboxed IFrame in the following ways:
alert()
would be equivalent to callingfunction () { return undefined; }
.confirm()
would be equivalent to callingfunction () { return false; }
.prompt()
would be equivalent to callingfunction () { return null; }
.print()
would be equivalent to callingfunction () { return undefined; }
.
Further, if the flag is set, beforeunload
event handlers for the framed Document are neutered in the following way:
- Step 8 of the "prompt to unload a document" algorithm will not prompt the the user to confirm that they wish to unload the framed document, but will instead act as though the user confirmed the page navigation.
In none of the above cases would a dialog be presented to the user.