W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2014

Re: 'child-src' and popups.

From: Mike West <mkwst@google.com>
Date: Mon, 10 Feb 2014 15:45:31 +0100
Message-ID: <CAKXHy=cU8gYXod14wyH34BzT4Qc6TX8N_ywFkHHWCyb1D+N7DA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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

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.

Received on Monday, 10 February 2014 14:46:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC