Re: Meta tag verification

Well, we don't have a formal use-case document for this, but my
recollection is that the two primary ones for the feature were:

1) Non-HTTP transports (e.g. loading from file:///)
2) Hosting environments where resource authors can't set headers

I also don't think that guaranteeing the integrity of the tag resolves the
very concern you mention, about its appropriate placement.  Or is the user
agent, upon seeing a meta-integrity header, supposed to wait on execution
until it can make an initial no-op parse to locate the policy, verify it,
and enforce it from the start of a re-parse?  Sounds bad for perf.

-Brad


On Fri, Feb 28, 2014 at 5:06 PM, Joel Weinberger <jww@chromium.org> wrote:

> For a while now, I've had rather mixed feelings about CSP in the meta tag.
> Namely, it seems a little too easy to shoot oneself in the foot by doing
> something as simple as putting a title tag with user content above it.
>
> That having been said, I've also been recently convinced that it's
> probably necessary. Header bloat is getting out of control, plus it's much
> easier to manage.
>
> So why not get the best of both? I propose a meta-integrity CSP directive
> (that's HTTP header only) that holds a hash of the CSP policy in the meta
> tag. This would guarantee that the meta tag CSP is the one the server
> intended. This would eliminate all of the concerns I've heard of about the
> meta tag, while still providing its flexibility.
>
> Personally, I'd go one step further and mandate that a meta-integrity be
> present in the HTTP header if the developer wants to use a meta tag CSP,
> but I suspect developers might find that overbearing.
>
> Any thoughts on all of this?
> -Joel
>