- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 14 Apr 2011 20:26:10 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: public-web-security@w3.org
On Thu, Apr 14, 2011 at 7:55 PM, Mark Nottingham <mnot@mnot.net> wrote: > 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. You're suggesting that we request the well-known policy file before we know whether the site is using CSP at all? That seems like a lot of spam requests, plus added latency for ever page on the web... Adam >> Should we drop support for policy-uri? > > No. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > >
Received on Friday, 15 April 2011 03:27:08 UTC