W3C home > Mailing lists > Public > public-web-security@w3.org > April 2011

Re: policy-uri is slow

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 15 Apr 2011 12:55:40 +1000
Cc: public-web-security@w3.org
Message-Id: <8748C495-340B-4C9F-8065-5D7769BEBE60@mnot.net>
To: Adam Barth <w3c@adambarth.com>

On 15/04/2011, at 10:47 AM, Adam Barth wrote:

> To confirm my understanding, if a document has a CSP policy consisting
> of a policy-uri, then the user agent is supposed to block processing
> of the document until it finishes fetching the policy-uri, right?
> That seems very bad for performance.

It can be, but so can putting verbose policy statements on every response you send. 

If the policy-uri is cacheable for a decent amount of time, the performance impact is only there when the cache is empty or expired.

The effects can be further mitigated by;
  - adjusting the client's cache eviction algorithm to be conservative about kicking out policy files
  - implementing connection pre-heating and HTTP pipelining (as Mozilla is currently) to decrease the impact of making that request
  - implementing stale-while-revalidate (RFC5861) in the client's cache so that when the cache is expired, the update happens in the background, in a controlled way.

If anything, I'd like to see this mechanism further optimised; i.e., instead of communicating the URI in each response (with the associated overhead in response size as well as the chance for introducing errors), have a well-known location (RFC5785) for policy files that the client can check proactively while it makes its initial request -- that way, it's much less likely to block anything. And even less bytes are in responses this way, of course. 

[snip]

> Should we drop support for policy-uri?

No.

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 15 April 2011 02:56:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 April 2011 02:56:09 GMT