Intent to Ship: `allow-unsandboxed-auxiliary` and `allow-modals` iframe@sandbox keywords.

[Mike West]

# Contact emails

mk...@chromium.org

# Spec

Just mailing list conversation at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0035.html. I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28817 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28818 to more formally request addition to HTML.

This seems a bit too small to poke the TAG about, but I'm happy to do so if there's interest.

# Summary

Folks from Google's anti-malvertising team would like to start experimenting with rendering ads in sandboxed iframes in order to mitigate some of the risks to both publishers and users. They've flagged two things blocking the current implementation:

1. Modal dialogs cannot be suppressed (and are often used to confuse users).

2. Sandboxed frames persist their sandboxedness to newly spawned windows, which forces the same restrictive flags upon a landing page.

The latter is critical to their use-case, the former is simply super nice-to-have.

# Link to "Intent to Implement"

`allow-unsandboxed-auxiliary`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/ZOhUntjhc94/EEXYKs9k1bgJ

`allow-modals`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/mXX0AO6Lioo/ual1B_3IqTYJ

# Demo link

https://mikewest.github.io/sandbox-demo/

# Debuggabillity

Browsers that support sandboxing but don't support this feature will be a bit of a problem, as there's no clear way to feature-detect sandboxing characteristics of a browser. Until such a thing exists, web developers would almost certainly need to resort to UA sniffing, which is fairly ugly.

This is an existing problem with `sandbox`, however; I think we could probably expose some sort of "active" set of sandbox flags either on the iframe element, or on a Document, but I would suggest that we can layer something along those lines on later.

# Compatibility risk

With the caveat that these numbers are dev-channel only: Over the past week, ~0.003% of documents viewed were sandboxed. ~0.0004% of _those_ generated a modal dialog. I suspect that those numbers will be higher in stable, but they should remain low given the low number of sandboxed documents in general. I'd would also posit that this is a behavior we'd like to make opt-in regardless of usage.

With regard to other vendors, the response here on blink-dev has been positive (with the only complaints being that the suggestions don't go far enough in blocking other types of modal dialogs). The response on the WHATWG list was also positive, but hasn't progressed since the initial proposal.

I'm CCing some Mozilla folks explicitly in the hopes of soliciting opinions.

# OWP Tracking Bug

`allow-unsandboxed-auxiliary`: https://crbug.com/487157 

`allow-modals`: https://crbug.com/483624

# Entry on the feature dashboard

`allow-unsandboxed-auxiliary`: https://www.chromestatus.com/features/5708368589094912

`allow-modals`: https://www.chromestatus.com/features/4747009953103872

[Jochen Eisinger]

lgtm

[Boris Zbarsky]

On 6/16/15 4:22 AM, Mike West wrote:
> 2. Sandboxed frames persist their sandboxedness to newly spawned
> windows, which forces the same restrictive flags upon a landing page.

So the reason this behavior is in place is to prevent the sandboxed page
from just doing window.open(location.href) and getting itself
unsandboxed, right?

Why is that not a problem in the particular case where you envision the
"allow-unsandboxed-auxiliary" flag being used?

> Browsers that support sandboxing but don't support this feature will be
> a bit of a problem

Where "this feature" is "allow-unsandboxed-auxiliary", I assume, since
"allow-modals" is already the default behavior in UAs?

-Boris

[Mike West]

Thanks, Boris!

On Jun 16, 2015 18:16, "Boris Zbarsky" <bzba...@mit.edu> wrote:
>
> On 6/16/15 4:22 AM, Mike West wrote:
>>
>> 2. Sandboxed frames persist their sandboxedness to newly spawned
>> windows, which forces the same restrictive flags upon a landing page.
>
>
> So the reason this behavior is in place is to prevent the sandboxed page from just doing window.open(location.href) and getting itself unsandboxed, right?
>
> Why is that not a problem in the particular case where you envision the "allow-unsandboxed-auxiliary" flag being used?

It would be a problem if we were changing the default behavior. I think it's less of a problem if the embedder is explicitly opting-into the new behavior, based on its knowledge of what it's embedding.

In particular, with this feature, it seems likely that third-party widget providers and advertisers could allow themselves to be sandboxed in various ways (certainly without 'allow-top-navigation', possibly without 'allow-same-origin'), which I think is a use case worth supporting. It trades off a bit of the sandbox's protection for a bit of flexibility, and that flexibility seems essential to certain categories of content that I'd like to see sandboxed.

>> Browsers that support sandboxing but don't support this feature will be
>> a bit of a problem
>
>
> Where "this feature" is "allow-unsandboxed-auxiliary", I assume, since "allow-modals" is already the default behavior in UAs?

Correct. I expect Google's malvertising team to sandbox based on sniffing, for instance, as browsers that don't support the auxiliary behavior won't be usable. I've had spelling out a feature detection mechanism on my list for a little while, and I'd certainly appreciate suggestions.

-mike

[Boris Zbarsky]

On 6/16/15 12:37 PM, Mike West wrote:
> It would be a problem if we were changing the default behavior. I think
> it's less of a problem if the embedder is explicitly opting-into the new
> behavior, based on its knowledge of what it's embedding.

I guess what I'm not clear on is what the threat model is here.

That is, you're trying to sandbox the ads. Presumably you don't trust
them in some ways. What are those ways? Why is it that you trust them
not to window.open themselves and circumvent the sandboxing but don't
trust them to not navigate the toplevel page?

-Boris

[Mike West]

One difference is that assigning to window.top.location doesn't require a user gesture. In Chrome (and, I believe, in Firefox? I have no idea how your pop-up blocker works, unfortunately...) it does. I'm much less concerned about the ad navigating the user somewhere interesting after an interaction than I am about the ad maliciously moving the user without any context.

-mike

[Boris Zbarsky]

On 6/16/15 12:48 PM, Mike West wrote:
> One difference is that assigning to window.top.location doesn't require
> a user gesture.

Ah, good point.

OK, this seems like something that should be very explicitly spelled out
in the spec. I almost wonder whether we should just call the flag
"allow-sandbox-escape-on-user-interaction" instead of
"allow-unsandboxed-auxiliary". After all, those are equivalent: if you
could just escape the sandbox on user gesture you could open an
unsandboxed auxiliary and if you can open unsandboxed auxiliarys you can
escape the sandbox on user gesture. And this makes it much clearer
what's _really_ being allowed...

-Boris

[Mike West]

I don't have a terribly strong opinion about the name, but I'd claim that "unsandboxed-auxiliary" is clearer than "sandbox-escape" with regard to the fact that we're limiting the escape mechanism to whatever can be rendered in a new window. That is, we're not allowing the frame itself to escape the sandbox; the active document in that nested browsing context keeps all of its sandboxing flags (it doesn't regain its origin, it doesn't gain top-level navigation ability, etc), while the new document in the new window is loaded outside the sandbox.

Saying that, it occurs to me that it might be a good idea for the newly unsandboxed window to be forced to disown its opener (in order to prevent something like `window.opener.top.location = "https://evil.com"`. WDYT?

-mike

[Boris Zbarsky]

On 6/17/15 3:25 AM, Mike West wrote:
> I don't have a terribly strong opinion about the name, but I'd claim
> that "unsandboxed-auxiliary" is clearer than "sandbox-escape" with
> regard to the fact that we're limiting the escape mechanism to whatever
> can be rendered in a new window.

While true, this does not properly represent the security impact, which
really is identical to just escaping the sandbox.

> Saying that, it occurs to me that it might be a good idea for the newly
> unsandboxed window to be forced to disown its opener (in order to
> prevent something like `window.opener.top.location =
> "https://evil.com"`. WDYT?

This works if the sandboxed thing is also not allow-same-origin, I
think. If it is, it can just hand the window to the newly opened thing.

How feasible would it be to both disown the opener _and_ have the
window.open call return null?

-Boris

[Mike West]

On Jun 17, 2015 15:59, "Boris Zbarsky" <bzba...@mit.edu> wrote:
>
> On 6/17/15 3:25 AM, Mike West wrote:
>>
>> I don't have a terribly strong opinion about the name, but I'd claim
>> that "unsandboxed-auxiliary" is clearer than "sandbox-escape" with
>> regard to the fact that we're limiting the escape mechanism to whatever
>> can be rendered in a new window.
>
>
> While true, this does not properly represent the security impact, which really is identical to just escaping the sandbox.

"unsandboxed" sounds to me like it communicates the risk.

If it's not clear enough, would just "allow-sandbox-escape" be enough, or is the gesture bit important enough to stuff into the keyword? I guess tacking "-via-gesture" wouldn't be terrible. *shrug*

I guess one worry I have is that if we make the keyword too broad, we won't have good arguments against keeping the mechanisms limited. Scoping the escape to a new window (which is both visible to users and requires a gesture) seems like a less risky proposition than allowing a gesture to navigate the window, for example. In theory, users see new windows. :)

> This works if the sandboxed thing is also not allow-same-origin, I think.  If it is, it can just hand the window to the newly opened thing.
>
> How feasible would it be to both disown the opener _and_ have the window.open call return null?

Totally feasible, and, I think, sensible.

-mike

[Boris Zbarsky]

On 6/17/15 10:25 AM, Mike West wrote:
> If it's not clear enough, would just "allow-sandbox-escape" be enough,

I would be fine with that, personally, but then people might get
confused about when that would ever be safe to use. Which might be ok...

> I guess one worry I have is that if we make the keyword too broad, we
> won't have good arguments against keeping the mechanisms limited.
> Scoping the escape to a new window (which is both visible to users and
> requires a gesture) seems like a less risky proposition than allowing a
> gesture to navigate the window, for example.

Sure. If we restrict things such that the newly opened window can't
just do all the same things as the old one but without sandboxing (e.g.
via the opener and return value restrictions we are discussing), then
making the flag more explicitly reference the new-window nature of
things makes sense.

> In theory, users see new windows. :)

In theory. In practice, nothing requires that and there are user
settings in at least some UAs that would put the new window in a
background tab, iirc.

> Totally feasible, and, I think, sensible.

I think we should make window.open return null, disown the owner, and
made the new window not targetable by name from the sandboxed thing (at
least in the cases when not allow-same-origin, if not always). Given
that, having a name that explicitly talks about unsandboxed auxiliarys
seems ok to me.

-Boris

[Anne van Kesteren]

On Wed, Jun 17, 2015 at 4:33 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I think we should make window.open return null, disown the owner, and made
> the new window not targetable by name from the sandboxed thing (at least in
> the cases when not allow-same-origin, if not always). Given that, having a
> name that explicitly talks about unsandboxed auxiliarys seems ok to me.

How would you avoid BroadcastChannel or storage events?


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 6/17/15 11:02 AM, Anne van Kesteren wrote:
> How would you avoid BroadcastChannel or storage events?

Do we need to? The goal, I thought, is to not be able to pass around
window references to the original page the sandboxed iframe is in.
Those can't be passed via BroadcastChannel or storage events, right?

-Boris

[Anne van Kesteren]

On Wed, Jun 17, 2015 at 5:13 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Do we need to? The goal, I thought, is to not be able to pass around window
> references to the original page the sandboxed iframe is in. Those can't be
> passed via BroadcastChannel or storage events, right?

Ah okay, I guess it's all good then. (They can't.)


--
https://annevankesteren.nl/

[Mike West]

On Wed, Jun 17, 2015 at 4:33 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

I think we should make window.open return null, disown the owner, and made the new window not targetable by name from the sandboxed thing (at least in the cases when not allow-same-origin, if not always).  Given that, having a name that explicitly talks about unsandboxed auxiliarys seems ok to me.

For clarity, I'd suggest keeping "allow-unsandboxed-auxiliary" as a keyword with the following effects:

* Auxiliary browsing contexts opened from the sandboxed context don't inherit the sandboxing flags, and disown their openers.

* Calls to `window.open` always returns `null`.

* The name passed into `window.open` will always be interpreted as "_blank" (which seems simpler than defining a mechanism of blocking named references).

Does that mesh with your suggestions?

-mike

[Boris Zbarsky]

On 6/17/15 11:56 AM, Mike West wrote:
> * The name passed into `window.open` will always be interpreted as
> "_blank" (which seems simpler than defining a mechanism of blocking
> named references).

Hmm. Maybe that's enough. The thing being opened can still set
window.name on itself, but you can't use that to target it, I guess, if
you force the name arg of window.open to _blank and do likewise with the
@target of <a> elements.

Seems reasonable to me.

-Boris

[Chris Harrelson]

Hi Mike,

Did all the discussion in this thread get moved to and recorded in the standards bodies? The feature sounds great to me, just waiting for confirmation that the dust has settled.

Also, is it possible to get this written into a draft spec now?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

On Tue, Jun 23, 2015 at 5:49 AM, Chris Harrelson <chri...@chromium.org> wrote:

Also, is it possible to get this written into a draft spec now?

I've put together a marginally more formalized discussion of the feature at https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments, and I'll ping the whatwg@ thread with that link shortly. It's not entirely clear to me what I can do beyond that with regard to getting this into HTML, either at WHATWG or W3C. :)

 

On Wed, Jun 17, 2015 at 9:02 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

On 6/17/15 11:56 AM, Mike West wrote:

* The name passed into `window.open` will always be interpreted as
"_blank" (which seems simpler than defining a mechanism of blocking
named references).

Hmm.  Maybe that's enough.  The thing being opened can still set window.name on itself, but you can't use that to target it, I guess, if you force the name arg of window.open to _blank and do likewise with the @target of <a> elements.

Seems reasonable to me.

Talking again with the ads folks, this proposal would remove their ability to determine whether or not a window was indeed opened (as opposed to being blocked by the popup blocker, etc). How would you feel about returning `true` for a window that was opened successfully, but whose handle has been neutered?

That would allow code like `if (win) { /* report success! */ }` to operate correctly, while maintaining the invariants we've discussed here. I've specced it out like this on the wiki, as it seems like a reasonable compromise.

Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.

-mike

[PhistucK]

Sometimes returning a boolean and sometimes returning a Window sounds pretty bad and hacky to me.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

On Tue, Jun 23, 2015 at 12:12 PM, 'Mike West' via blink-dev <blin...@chromium.org> wrote:

Talking again with the ads folks, this proposal would remove their ability to determine whether or not a window was indeed opened (as opposed to being blocked by the popup blocker, etc). How would you feel about returning `true` for a window that was opened successfully, but whose handle has been neutered?

That would allow code like `if (win) { /* report success! */ }` to operate correctly, while maintaining the invariants we've discussed here. I've specced it out like this on the wiki, as it seems like a reasonable compromise.

 

On Tue, Jun 23, 2015 at 1:25 PM, PhistucK <phis...@gmail.com> wrote:

Sometimes returning a boolean and sometimes returning a Window sounds pretty bad and hacky to me.

I welcome suggestions. :)

-mike

[PhistucK]

You can return a Window with cross origin conventions (meaning, as if you opened a window from a different origin).

It can be null if it were not successfully open and you can even still postMessage to it, but not access anything else (and not have it access anything from your window as well. Well, other than changing location.href? :|).

☆PhistucK

[Mike West]

On Tue, Jun 23, 2015 at 1:42 PM, PhistucK <phis...@gmail.com> wrote:

You can return a Window with cross origin conventions (meaning, as if you opened a window from a different origin).

It can be null if it were not successfully open and you can even still postMessage to it, but not access anything else (and not have it access anything from your window as well. Well, other than changing location.href? :|).

`postMessage` is one of the things we'd like to prevent.

Basically, Boris pointed out that allowing cross-window communication to the newly-popped-open window is equivalent to a sandbox escape. Given that, I think we have two options:

1. Accept that this is a sandbox escape, allow `window.open` to return a handle to the window, allow the new window to keep it's opener, and name the sandbox keyword accordingly (Boris suggested `allow-sandbox-escape`).

2. Prevent the escape by tightly scoping the mechanism, as in the proposal.

I prefer #2. There are reasonable arguments for #1, but I'd prefer something more tightly scoped than `allow-sandbox-escape` would imply.

-mike

[PhistucK]

Since you wrote -

> Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.

I thought that postMessage would actually be a good addition.

Anyway, if you prefer 2, this is fine, but not by messing with the return value type of the ageless window.open. I do not recall any recent API that behave this way, only legacy ones (document.all["non-unique-name-or-id"] versus document.all["unique-name-or-id"]I do not have an alternative, but this one sounds horrible.

☆PhistucK

[Mike West]

On Tue, Jun 23, 2015 at 3:08 PM, PhistucK <phis...@gmail.com> wrote:

Since you wrote -

> Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.

I thought that postMessage would actually be a good addition.

The ads folks I'm talking to agree with you, though they don't have any direct use for the channel right now. Until such time as they're actually using the channel for something, I don't think there's any particular reason to offer it, given the concerns Boris raised earlier. Not providing it allows us to narrow the scope of the escape significantly, which is valuable.

Anyway, if you prefer 2, this is fine, but not by messing with the return value type of the ageless window.open. I do not recall any recent API that behave this way, only legacy ones (document.all["non-unique-name-or-id"] versus document.all["unique-name-or-id"]I do not have an alternative, but this one sounds horrible.

Again, I welcome alternative suggestions.

I'm less concerned about the ugliness, given that this _only_ effects `window.open` inside the context of a sandboxed iframe using the newly proposed `allow-sandboxed-auxiliary` keyword. It has zero impact on legacy content.

The only alternative I can think of would be to extend `Window` in some way to allow us to construct a neutered Window object that simply swallowed any and all method invocations. It's not clear to me that that's any better than just returning "true".

In any event, I'm not the right guy to make decisions about the stuff we jam into the platform, however, which is why I'm glad folks like you push back on ugliness. :)

-mike

[chris...@gmail.com]

I'd be pretty excited to see the modal window that is triggered when a protected resource is linked to get stopped in addition the alert/confirm/etc modals. 

[bi...@google.com]

On Tuesday, June 23, 2015 at 9:21:36 AM UTC-4, Mike West wrote:

On Tue, Jun 23, 2015 at 3:08 PM, PhistucK <phis...@gmail.com> wrote:

Since you wrote -

> Note that they were a bit bummed that they wouldn't have a messaging channel between the frame and the window, which makes it more difficult to do some interesting things in the future with regard to monitoring, but it sounds like they'd be willing to drop that requirement and come back to it in the future when they have clear use cases. It wouldn't break anything today.

I thought that postMessage would actually be a good addition.

The ads folks I'm talking to agree with you, though they don't have any direct use for the channel right now. Until such time as they're actually using the channel for something, I don't think there's any particular reason to offer it, given the concerns Boris raised earlier. Not providing it allows us to narrow the scope of the escape significantly, which is valuable.

Anyway, if you prefer 2, this is fine, but not by messing with the return value type of the ageless window.open. I do not recall any recent API that behave this way, only legacy ones (document.all["non-unique-name-or-id"] versus document.all["unique-name-or-id"]I do not have an alternative, but this one sounds horrible.

Again, I welcome alternative suggestions.

I'm less concerned about the ugliness, given that this _only_ effects `window.open` inside the context of a sandboxed iframe using the newly proposed `allow-sandboxed-auxiliary` keyword. It has zero impact on legacy content.

Since the communication channel between the new window and the frame could be useful in future, how about we add both "allow-unsandboxed-auxiliary" and "allow-sandbox-escape" to allow different behaviors?

If the user (say ads networks) wants the communication channel, the "allow-sandbox-escape" flag could be used (which allows the frame to keep the handle to the new window).

Otherwise, "allow-unsandboxed-auxiliary" would be fine by disowning the opener and returning null handle.

In this way, we are providing more flexibility for envisioned usages and don't need the ugliness of changing the return value to "true".

[PhistucK]

The feature detection story bothers me.

Currently, I believe you can feature detect the HTMLIFrameElement.prototype.sandbox feature -

"sandbox" in HTMLIFrameElement.prototype // true when I tested in Chrome and Internet Explorer 11

While you cannot feature detect the tokens, I think only allow-pointer-lock is not supported in Internet Explorer 10 and 11, but this is easy to feature detect (it does not support pointer lock anyway).

Adding two more features to this without a feature detection story is very bad. Perhaps you can come up with one.

For example, sandbox is a DOMSettableTokenList - why should it return tokens it cannot handle? Perhaps it should only return the valid tokens (this would be inconsistent with other usage of space separated token based properties, I believe, so this is not recommended).

Alternatively, since authors may already rely on this (though the usage is low enough that it can be changed without any worry), add HTMLIFrameElement.prototype.sandboxRelaxations that returns an (immutable?) array of the relaxation tokens that were handled.

Another idea, to make it easier to feature detect without even creating an iFrame, is adding HTMLIFrameElement.supportedSandboxTokens as an (immutable?) array of supported tokens.

I do not think any feature that cannot be (easily and reliably) feature detected should be allowed into the platform nowadays, really. We suffered enough user agent sniffing in the last decade and a half for getting there again.

Just because Google user-agent-sniffs as a policy and feature detection is not that important for its use, it does not mean that it is not so bad not to have a feature detection story (sorry for the multiple negation here ;)).

☆PhistucK

On Tue, Jun 16, 2015 at 11:22 AM, Mike West <mk...@chromium.org> wrote:

# Contact emails

mk...@chromium.org

# Spec

Just mailing list conversation at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0035.html. I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28817 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=28818 to more formally request addition to HTML.

This seems a bit too small to poke the TAG about, but I'm happy to do so if there's interest.

# Summary

Folks from Google's anti-malvertising team would like to start experimenting with rendering ads in sandboxed iframes in order to mitigate some of the risks to both publishers and users. They've flagged two things blocking the current implementation:

1. Modal dialogs cannot be suppressed (and are often used to confuse users).

2. Sandboxed frames persist their sandboxedness to newly spawned windows, which forces the same restrictive flags upon a landing page.

The latter is critical to their use-case, the former is simply super nice-to-have.

# Link to "Intent to Implement"

`allow-unsandboxed-auxiliary`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/ZOhUntjhc94/EEXYKs9k1bgJ

`allow-modals`: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/sandbox/blink-dev/mXX0AO6Lioo/ual1B_3IqTYJ

# Demo link

https://mikewest.github.io/sandbox-demo/

# Debuggabillity

Browsers that support sandboxing but don't support this feature will be a bit of a problem, as there's no clear way to feature-detect sandboxing characteristics of a browser. Until such a thing exists, web developers would almost certainly need to resort to UA sniffing, which is fairly ugly.

This is an existing problem with `sandbox`, however; I think we could probably expose some sort of "active" set of sandbox flags either on the iframe element, or on a Document, but I would suggest that we can layer something along those lines on later.

# Compatibility risk

With the caveat that these numbers are dev-channel only: Over the past week, ~0.003% of documents viewed were sandboxed. ~0.0004% of _those_ generated a modal dialog. I suspect that those numbers will be higher in stable, but they should remain low given the low number of sandboxed documents in general. I'd would also posit that this is a behavior we'd like to make opt-in regardless of usage.

With regard to other vendors, the response here on blink-dev has been positive (with the only complaints being that the suggestions don't go far enough in blocking other types of modal dialogs). The response on the WHATWG list was also positive, but hasn't progressed since the initial proposal.

I'm CCing some Mozilla folks explicitly in the hopes of soliciting opinions.

# OWP Tracking Bug

`allow-unsandboxed-auxiliary`: https://crbug.com/487157 

`allow-modals`: https://crbug.com/483624

# Entry on the feature dashboard

`allow-unsandboxed-auxiliary`: https://www.chromestatus.com/features/5708368589094912

`allow-modals`: https://www.chromestatus.com/features/4747009953103872

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

Bumping this for visibility:

1. `allow-modals` seems to have substantial agreement on the core proposal at https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments#Modal_Dialogs_2. I'd like to ship it.

2. As discussed at https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0006.html, I've simplified the proposal along the lines of Boris' sandbox escape proposal: https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments#Auxiliary_Windows_2 now defines an `allow-popups-to-escape-sandbox` keyword, which allows an unsandboxed window to be opened, and does not neuter the communication channel. Boris can live with it (https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0011.html), which I'll pretend is a glowing endorsement. :)

Shipping both of these will allow Google's anti-malware folks to more tightly sandbox more kinds of ads than they can currently, which seems like a substantial win.

---

The feature detection story PhistuK calls out is indeed a problem. I'd suggest that that shouldn't block this feature (as the folks who want to use it right now are, as he notes, already sniffing), but I do think it's important to address, and I'll send out a proposal to whatwg@ this afternoon.

-mike

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Alex Russell]

I'd like to see all of this shipped ASAP.

[Philip Jägenstedt]

LGTM

It's been a long thread, so to summarize my understanding, this means
flipping SandboxBlocksModals the UnsandboxedAuxiliary flags to
status=stable, thus enabling the "allow-popups-to-escape-sandbox" and
"allow-modals" tokens.

[Jochen Eisinger]

(my lgtm still stands)