Avoid adding a new directive to CSP

[letitz]

@mikewest tells me that he wished not to add a new directive to CSP in the form of treat-as-public-address. crbug.com/1000226 has been languishing in obscurity for Chromium.

Since this is a useful primitive for tests in particular, I'd like to keep it in some form. In fact, I believe we can solve two issues at once by spelling this as a sandbox flag.

If we define a new sandbox flag that grants access to the private network (provided PNA checks succeed), then we can also solve #26.

For iframes:

sandbox="allow-private-network"

For top-level documents, CSP would still be used to deliver the flag, but we would avoid adding a new directive.

[letitz]

It would be best to determine the compatibility impact of such a change. Do many sandboxed iframes need access to the private network? They would lose it as part of this change unless they added the new flag.

[mikewest]

This model seems pretty reasonable to me if it's borne out by usage numbers. Independent from tests, I think it's good to give pages a way to drop their network-positional privilege. I'd simply like to do so without further muddying the waters around what CSP does.

[annevk]

Well, CSP does do sandboxing. 😊

[mikewest]

Yup. And if sandboxing grows some new functionality, CSP should pass it through so we can tell a consistent story about top-level sandboxing! That said, I don't think we'd put sandbox into CSP if we were talking about it today, and I'd like to avoid expanding CSP's remit in itself. Adding a new sandbox flag with purely negative effect seems pretty in-line with the rest of sandbox, and allows us to explain the behavior in a way that feels fine to me.