Re: policy-uri proposal (ACTION 97)

That looks like a good start.  Perhaps we should add it to the draft
and iterate?

As an example, we probably need to say something about how the user
agent must not start rendering the response until it gets the policy.
Editorially, I'd probably also separate the server requirements from
the user agent requirements given that they're for different sets of
implementors.

These are all details and are things we can address by revising the
text after adding it to the draft.

Adam


On Tue, Jun 18, 2013 at 9:01 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> Here is a policy-uri proposal. Unlike the original Mozilla
> implementation that requires policy-uri to be the only directive in a
> CSP header that contains it, this one treats the fetched policy as an
> additional header of the same type (following the intersecting
> multi-header policy already in the spec). Not sure if that's actually
> useful but made more sense than the punitive action of applying a
> draconian default-src 'none' policy or unsafely ignoring the policy
> altogether.
>
> I debated adding a "Usage" section listing some of the pros and cons of
> using policy-uri. Does anyone think we need it? Basically comes down to
>
> Con: adds latency to loading the page.
>
> Pro: if you have a large complex policy that is used on multiple pages
> this reduces the size of every page load (after the first). If you have
> a ridiculously detailed policy--which could happen if we add the
> script-hash proposal--this could help avoid running into the header-size
> limitations.
>
> This could also be used to make the policy easier to understand and
> maintain since newlines count as whitespace so the policy can be
> arranged in a readable way.
>
> -Dan Veditz
>

Received on Sunday, 23 June 2013 04:39:55 UTC