Re: 'child-src' and popups.

On Mon, Feb 10, 2014 at 3:09 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Feb 10, 2014 at 2:21 PM, Mike West <mkwst@google.com> wrote:
> > 1. Popping up an allowed resource allows trivial navigation to a
> disallowed
> > resource via the reference returned from 'window.open'. Do we want to
> block
> > navigations in the new window's context?
>
> See http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0007.html
> for why grouping popups and child-src does not really work for service
> workers. We want to know it's a top-level navigation, but we also want
> to know it's different from the main window.
>

1. One more reason to punt to 1.2.
2. Yes. I've got that email starred right now; we need to seriously think
about service workers. It's a really important topic, with a few open
questions that are equally important.


> > 2. If we wish to block redirections (allowed.com -> blocked.com), we'll
> > currently pop up the window to do the request. If the redirection fails a
> > CSP check, what do we do? Close the window? Leave the window open at
> > about:blank (as we end up doing (in Blink) for blocked frames)?
>
> We should do the same as what we do for network errors as that is what
> a failed CSP check should result in.
>

Network errors for frame loads (in Blink) land you on an error page, which
I think we push out to a unique origin. I'd have to check. The window does
_open_, however, which would enable navigation (and therefore potential
weirdness).

Not sure about unsafe-eval.
>

It's an open question.

Filing https://www.w3.org/2011/webappsec/track/issues/57 to make sure we
address all these one way or the other for 1.2.

-mike