'child-src' and popups.

After talking with some folks who know way more about popups than I do, I'm
dropping the auxiliary browsing context bits from the current draft's
definition of 'child-src'. It turns out that they're more complicated than
I expected (and, really, outside the scope of the feature-set that we
closed in October, 2013):
https://github.com/w3c/webappsec/commit/9b7a618aca1f9fcbc99f9887df60ccd98d9c7654

Some open questions:

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?

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)?

3. Should 'unsafe-eval' (or something similar) gate the ability to pop up a
window and then 'document.write' its contents?

None of these are blockers, per se, but given the state of 1.1, and the
relative value of this feature, dropping it for now seems like a good idea.
Let's save this bit for 1.2.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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.)