Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Thu, Jul 9, 2015 at 5:28 PM, Daniel Veditz  wrote:

> On Mon, Jul 6, 2015 at 2:47 AM, Mike West  wrote:
>
>> I've dropped the opener/openee-disowning behavior from my proposal,
>> and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
>>
>> https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955
>
>
> ​It appears that this new keyword as described would still require the use
> of allow-popups in addition to allow-popups-to-escape-sandbox. Since it
> doesn't make any sense on its own can you change it so that either keyword
> allows popups to happen? That it, propose changing
>
> [Set] The sandboxed auxiliary navigation browsing context flag
> ,
> unless tokens
> contains the allow-popups keyword.
>
> to
>
>[Set] The sandboxed auxiliary navigation browsing context flag
> ,
> unless tokens
>contains the allow-popups or *allow-popups-to-escape-sandbox* keyword.
>
> ​(might then require changing -to-escape- to -that-escape-)​
>

My only concern with this is that folks might disallow certain sanboxing
flags that they know are dangerous, which might mean that their CMS would
block `allow-plugins`, but might allow new flags (which would then allow
someone to `allow-plugins-to-escape-sandbox`. This kind of blacklisting is
probably a bit far fetched, so I could live with the behavior if you feel
strongly about it, but I'd prefer to keep the changes as small and additive
as possible.

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Daniel Veditz]

On Mon, Jul 6, 2015 at 2:47 AM, Mike West  wrote:

> I've dropped the opener/openee-disowning behavior from my proposal,
> and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
>
> https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955


​It appears that this new keyword as described would still require the use
of allow-popups in addition to allow-popups-to-escape-sandbox. Since it
doesn't make any sense on its own can you change it so that either keyword
allows popups to happen? That it, propose changing

[Set] The sandboxed auxiliary navigation browsing context flag
,
unless tokens
contains the allow-popups keyword.

to

   [Set] The sandboxed auxiliary navigation browsing context flag
,
unless tokens
   contains the allow-popups or *allow-popups-to-escape-sandbox* keyword.

​(might then require changing -to-escape- to -that-escape-)​

​You question to bz was "can you live with it", and I can live with it. I
wish it could be shorter, but my attempts (allow-popups-unsandboxed or
allow-unsandboxed-popups) weren't much shorter. Keeping "allow popups" in
there is good, especially if it can be used in place of regular
allow-popups. using the word "sandbox" is better than anything about
"auxiliary contexts".​

-
​Dan Veditz

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky  wrote:

> On 7/6/15 5:47 AM, Mike West wrote:
>
>> Boris, I think this is consistent with your suggestions in
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
>> and
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ
>> .
>> Can you live with this naming/behavior?
>>
>
> I personally can probably can... I can't promise anything about how people
> will respond to an intent to implement for such a thing.


I'll take it. :)

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Boris Zbarsky]

On 7/6/15 5:47 AM, Mike West wrote:

Boris, I think this is consistent with your suggestions in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
and
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ.
Can you live with this naming/behavior?


I personally can probably can... I can't promise anything about how 
people will respond to an intent to implement for such a thing.


-Boris

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, Jun 23, 2015 at 11:14 AM, Mike West  wrote:

> After some conversation with bz (CC'd), I've slightly formalized the
> description of the feature at
> https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.
>
> This is something that I'd like to ship in Chrome in the somewhat near
> future. See the "Intent to Ship" at
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ.
> Feedback, positive or negative, would be appreciated (either here or
> there). :)
>

It seems like there's either substantial agreement (or apathy) regarding
the `allow-modals` proposal.

The auxiliary proposal is the more interesting of the two, and I've revised
it again following some more feedback from ads folks. In short, they're
more interested in maintaining a communication channel between the
sandboxed frame and the auxiliary window than I thought they were. Given
that, I've dropped the opener/openee-disowning behavior from my proposal,
and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955
.

Boris, I think this is consistent with your suggestions in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
and
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ.
Can you live with this naming/behavior?

-mike

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

After some conversation with bz (CC'd), I've slightly formalized the
description of the feature at
https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.

This is something that I'd like to ship in Chrome in the somewhat near
future. See the "Intent to Ship" at
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/YtsqkySmTWcJ.
Feedback, positive or negative, would be appreciated (either here or
there). :)

-mike

--
Mike West , @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.)

On Sun, May 17, 2015 at 8:59 PM, Mike West  wrote:

> On Mon, May 11, 2015 at 6:11 AM, Mike West  wrote:
>>
>> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>>
>
> This flag is in the latest Chrome Canary,
> behind chrome://flags/#enable-experimental-web-platform-features, if anyone
> is interested in playing with the feature.
>
> Given the generally positive response on this thread, WDYT about adding it
> to HTML, hixie@?
>
> I'd like to circle back to the `allow-modals` proposal once
> https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits
> stable and starts bringing in reliable data (~12 weeks). I'll ping the
> thread again then. :)
>
> -mike
>
> --
> Mike West , @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.)
>

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 6:11 AM, Mike West  wrote:
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.
>

This flag is in the latest Chrome Canary,
behind chrome://flags/#enable-experimental-web-platform-features, if anyone
is interested in playing with the feature.

Given the generally positive response on this thread, WDYT about adding it
to HTML, hixie@?

I'd like to circle back to the `allow-modals` proposal once
https://www.chromestatus.com/metrics/feature/timeline/popularity/767 hits
stable and starts bringing in reliable data (~12 weeks). I'll ping the
thread again then. :)

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Thu, May 14, 2015 at 3:59 PM, Devdatta Akhawe 
wrote:
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>>
>>
> Why isn't a child iframe of the sandboxed iframe an auxiliary browsing
> context?
>

Because it's a nested browsing context. Auxiliary browsing contexts are
related to a context, but not through nesting:
https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-contexts.
It's just a definitional thing.

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, May 12, 2015 at 6:45 PM, Ian Melven  wrote:

> This is what I expected. showModalDialog is a bit of an edge case perhaps.
> Sounds like this needs a new sandbox attribute value to re-opt back in to
> it like 'allow-modals' or whatever you suggested :) This is a behavior
> change as you said, but I defer to your stats on the (lack of) usage of
> iframe sandbox :(
>

Since Chrome has dropped support for `showModalDialog` entirely, I'm not
terribly worked up about it. :)

If folks want an opt-in, then `allow-modals` is probably a fine way to do
it. Again, it's not clear to me that there's a _good_ use case for modal
dialogs popping up from a frame (even an unsandboxed frame!).

Yeah, my main point was this should be tied to allow-popups somehow. If we
> proceeded this way ('allow-popups' + 'allow-unsandboxed-popups') to me that
> would mean that sandboxed iframe could only ever open unsandboxed aux
> browsing contexts. I think that's probably OK because we can't trust the
> sandboxed iframe to tell us itself whether an aux context it's opening
> should be sandboxed or not - so making this essentially a one time setting
> for the iframe it can't change seems to be correct.
>

That's the way the prototype I'm playing with works (
https://codereview.chromium.org/1139933002). I don't think there's a good
way to specify that some auxiliary browsing contexts are sandboxed and some
aren't. Especially given the general use case of fourth-, fifth-, and
sixth-party sources, nested somewhere inside the deepest darkest corners of
the iframe displaying the content the user actually sees.

Making it a binary toggle for the frame seems reasonable, given that it's
opt-in in the first place.

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Tue, May 12, 2015 at 6:05 AM, Brad Hill  wrote:

> Chrome did to that once upon a time (blocking 401 prompts on all
> subresource loads) but it opened up a brute-force hole where the lack of UI
> allowed extremely rapid testing of HTTP Basic requiring resources, so it
> got backed out.  I'm not sure where it eventually ended up, but I know it
> was an issue.  I'd think that for a sandboxed iframe you could be a bit
> more draconian and not just short-circuit the prompt but totally forbid
> connecting to resources which require an Authentication header, blocking
> the avenue of exploit as well as the phishing risk.  It seems there should
> be very few if any use cases for sandboxed content calling
> HTTP-authenticated resources.
>

Yes. That was how I interpreted the suggestion as well; we'd suppress the
dialog by cancelling the request. :)

-mike

--
Mike West , @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.)

>

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 11:59 PM, Justin Dolske  wrote:

> On Mon, May 11, 2015 at 7:13 AM, Mike West  wrote:
>
>> > The worst offender: linking to things that are .htpasswd protected and
>> it
>> > pops up that authentication modal.
>> >
>>
>> I wouldn't be terribly averse to dropping support for that inside a
>> sandbox. Especially a sandbox without `allow-same-origin`.
>>
>>
> Firefox sorta does this by default, as of
> https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears
> to for cross-origin iframes, which I would expect to be the normal case for
> ads?
>

Interesting! Thanks for the pointer to the bug. If Firefox is already going
this route, I don't see any reason Chrome shouldn't follow. It makes sense
to me, in any event.


> Also, along with blocking alert() et al from sandboxed iframes, it would
> be good to include the onbeforeunload dialog. It's a pretty common target
> for abuse. We've got a bug to disable it entirely in iframes (1131187), but
> no one is actively working on it.
>

Ah, yes. I forgot about `onbeforeunload`. I'd happily kill that inside a
sandbox as well. :)

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 7:24 PM, Ian Melven  wrote:

> 1) At one point i think showModalDialog was specified to be blocked unless
> allow-popups was set. (I can't find this in the current editor's draft of
> the spec).
> It seems to me that it would make sense to follow #1 in your proposal
> (blocking alert and friends) UNLESS allow-popups is specified perhaps ?
> Unless the advertising use case is such that they would want to specify
> allow-popups in most common cases, which negates any benefit of this
> restriction in practice
>

My understanding of the use case is that they want `allow-popups` in order
to allow navigation to a landing page via `target="_blank"`, et al. They
don't want modal dialogs from that same window. Tying both behaviors to
`allow-popups` wouldn't solve their problem.


> 2) this also sounds like allow-popups would be needed (since you shouldn't
> be allowed to open new auxiliary browsing context without it)
>

Correct. Both `allow-popups` and the new flag would need to be specified.


> and maybe is more consistent using 'allow-popups-unsandboxed' ?
>

Or `allow-unsandboxed-popups`. I don't really care how we spell it. :)

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Justin Dolske]

On Mon, May 11, 2015 at 7:13 AM, Mike West  wrote:

> > The worst offender: linking to things that are .htpasswd protected and it
> > pops up that authentication modal.
> >
>
> I wouldn't be terribly averse to dropping support for that inside a
> sandbox. Especially a sandbox without `allow-same-origin`.
>
>
Firefox sorta does this by default, as of
https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears to
for cross-origin iframes, which I would expect to be the normal case for
ads?

Also, along with blocking alert() et al from sandboxed iframes, it would be
good to include the onbeforeunload dialog. It's a pretty common target for
abuse. We've got a bug to disable it entirely in iframes (1131187), but no
one is actively working on it.

Justin

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 4:12 PM, James M. Greene 
wrote:

> 1. Block modal dialogs from inside sandboxed frames. That is:
>> * `alert(...)` would return without popping up a dialog.
>> * `confirm(...)` would return `false` without popping up a dialog.
>> * `prompt(...)` would return `null` without popping up a dialog.
>> * `print(...)` would return without popping up a dialog.
>
>
> I'm OK with that.  As a general rule, though, I would prefer that pretty
> much whatever gets blocked by default can be reenabled via additional new
> keywords (e.g. "allow-modals").
>

Sure. It's not clear to me that there's a _good_ use of any of these
methods in an iframe, so I'd prefer to just remove the capability entirely,
but if there's a desire to retain the functionality, I'd certainly
implement something like `allow-modals` in Chrome.


> Although I understand the rational for blocking native plugins by default
> due to their inherent unmanaged nature, I still wish that they could be
> reenabled via a keyword as there are still realistic scenarios where you
> may want (e.g.) Flash enabled but still disallow/disable other features
> like popups, navigation, etc.
>

An issue with Flash (and other plugins) is that they generally bypass the
rest of the sandboxing flags. That is, enabling flash while disabling
`window.open` is somewhat ineffectual, as Flash can just pop a new window
with it's native code.

This is somewhat improved in Chrome, as PPAPI allows us a bit more access
to the ways in which Flash can poke at the system, but it doesn't improve
the (terrible) process model, etc. I think it would still be a bit too
dangerous to introduce an `allow-plugins` flag given the sandboxing state
in other browsers, but it's probably a conversation worth having.


> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
>> `sandbox` attribute, which, when present, would allow auxiliary browsing
>> contexts created by `window.open` and `target="_blank"` links to create
>> clean browsing contexts, unaffected by the sandbox which spawned them.
>
>
> I'm OK with that, too.  I'm assuming that cascades, though, right?  In
> other words, if the top window does NOT use the
> "allow-unsandboxed-auxiliary" keyword on its child iframe, I'm assuming the
> child iframe cannot successfully use "allow-unsandboxed-auxiliary" on a
> child iframe of its own.
>

Yes, this is also how I imagined it working. I should have made that clear
in the proposal, but I think (hope!) this naturally falls out of the way
sandbox flags are propagated from frame to frame/window to window.

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 4:02 PM, Chris Coyier  wrote:

> I'd think popups would be killed by default and allow-popups would allow
> them. Or if you need a new value, allow-obnoxious-things could work ;)
>

I would prefer to simply remove the functionality. :)

If we do decide that we need `alert()` and friends, I would suggest that
`allow-popups` is the wrong flag to use. The advertising use case I noted
at the top pretty much requires `window.open`/`target="_blank"` to work
correctly. If those only work when `alert()` is enabled, then we wouldn't
solve the issue.


> Like navigator.geolocation (so we regex and strip it).
>

I think permissions for iframes in general are a separate question, but an
important one to deal with.


> The worst offender: linking to things that are .htpasswd protected and it
> pops up that authentication modal.
>

I wouldn't be terribly averse to dropping support for that inside a
sandbox. Especially a sandbox without `allow-same-origin`.

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[James M. Greene]

>
> 1. Block modal dialogs from inside sandboxed frames. That is:
> * `alert(...)` would return without popping up a dialog.
> * `confirm(...)` would return `false` without popping up a dialog.
> * `prompt(...)` would return `null` without popping up a dialog.
> * `print(...)` would return without popping up a dialog.


I'm OK with that.  As a general rule, though, I would prefer that pretty
much whatever gets blocked by default can be reenabled via additional new
keywords (e.g. "allow-modals").  Although I understand the rational for
blocking native plugins by default due to their inherent unmanaged nature,
I still wish that they could be reenabled via a keyword as there are still
realistic scenarios where you may want (e.g.) Flash enabled but still
disallow/disable other features like popups, navigation, etc.


2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.


I'm OK with that, too.  I'm assuming that cascades, though, right?  In
other words, if the top window does NOT use the
"allow-unsandboxed-auxiliary" keyword on its child iframe, I'm assuming the
child iframe cannot successfully use "allow-unsandboxed-auxiliary" on a
child iframe of its own.

Sincerely,
James Greene


On Sun, May 10, 2015 at 11:11 PM, Mike West  wrote:

> (BCC: public-webapp...@w3.org)
>
> Hello, wonderful whatwg@ folks!
>
> I've talked with a few folks from Google's advertising teams who are
> interested in using sandboxed iframes to mitigate the risks associated with
> ads. They've flagged two things that they'd like to see happen in the
> future:
>
> 1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and
> `print()` (and `showModalDialog()` for browsers that support it)).
>
> 2. Allow sandboxed frames to spawn new windows without forcing the sandbox
> upon them. This would allow the advertisement itself to be sandboxed,
> without forcing the same restrictive flags upon a landing page.
>
> # Proposal
>
> 1. Block modal dialogs from inside sandboxed frames. That is:
>
> * `alert(...)` would return without popping up a dialog.
> * `confirm(...)` would return `false` without popping up a dialog.
> * `prompt(...)` would return `null` without popping up a dialog.
> * `print(...)` would return without popping up a dialog.
>
> This was discussed briefly at
>
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html
> ,
> but I didn't find any follow-up (CCing folks from that thread). I've added
> metrics to Chrome in https://codereview.chromium.org/1121053002, but it
> will take a few weeks to get good data. Given the low usage of sandboxes in
> general (~0.5% of page views, according to
> https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I
> suspect we could fairly easily make this change.
>
> 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
> `sandbox` attribute, which, when present, would allow auxiliary browsing
> contexts created by `window.open` and `target="_blank"` links to create
> clean browsing contexts, unaffected by the sandbox which spawned them.
>
> WDYT?
>
> --
> Mike West , @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.)
>

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 9:19 AM, Jim Manico  wrote:

> The whole purpose of a sandbox is to limit what content inside of it can
> do. I want to limit where that sandbox can open windows with full
> cookie/script/etc access.
>

And you can do so by _not_ specifying the new flag I'm proposing. :)

Again ``'s behavior would not change. The proposal would
add new behavior only for something like ``.


> So essentially I want to say, "You can show your ad, you cant run a script
> or access my main window.  Also, you can only open full-access windows back
> to the same domain that your ad came from."
>

If the ad comes from `advertising-is-awesome.net`, but is pointing users to
the excellent products at `products-are-nice.com`, how would your proposal
allow a click on the ad to navigate a user to the excellent products in an
unsandboxed window (e.g. one that has an origin)? I'd suggest that that's
an essential component. It's certainly essential to advertisers.


> Is that to extreme of an ask? I just dont like the idea that a sandboxed
> resource has full access to open any new window. It seems excessive and can
> exploit CSRF vulns in a way a full sandboxed iFrame as I'm describing could
> not.
>

I still don't understand the threat model you're proposing. That is, I
don't see sandboxing as a CSRF defense at all. Sandboxed frames can
navigate themselves to any origin right now, and load any origin in a
frame. If the `allow-popups` flag is set, it can open auxiliary windows. If
the `allow-forms` flag is set, it can POST to arbitrary origins.

-mike

--
Mike West , @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.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

[Mike West]

On Mon, May 11, 2015 at 7:27 AM, Jim Manico  wrote:

> > 2. Allow sandboxed frames to spawn new windows without forcing the
> sandbox upon them.
>
> I think this needs to be restricted so sandboxed iFrames cannot spawn new
> windows back to the same domain - or better yet may only spawn windows to
> limited domain/domains driven by the initial ad request.
>

What risk do you see that mitigating? How would you expect it to behave
with regard to redirects or navigations? I guess I don't see the value in
adding these kinds of restrictions, and (especially given the target
audience, and their predilection for tons and tons of cross-origin
redirects) it seems like making it easier to sandbox the inlined frame
outweighs the desire to lock down the out-of-line auxiliary browsing
context.

Also, note that the proposal already makes the behavior opt-in via the
`allow-unsandboxed-auxiliary` keyword (it wouldn't change the behavior of
any existing sandboxed frame), and browsers generally throttle the creation
of popups in various ways (Chrome allows only one popup per user gesture,
for instance).

--
Mike West , @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.)