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

Re: policy-uri is slow

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 16 Apr 2011 09:51:19 +1000
Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org
Message-Id: <F3581BE6-5EC0-44AF-BA64-76584F674949@mnot.net>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>

On 16/04/2011, at 8:19 AM, Aryeh Gregor wrote:

> On Thu, Apr 14, 2011 at 10:55 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 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.
> Web servers are configured by default to not serve caching headers, so
> we can expect that on typical sites, the browser will have to
> re-request it on every page view.  (Unless CSP proves to be so hard to
> use that it's only used on extremely large sites that do regular
> performance testing, which I hope we aren't aiming for.)

You seem to be saying that a site that's going through the effort of setting CSP headers for all of its resources will shy away from setting caching headers as well. Why?

>> The effects can be further mitigated by;
>>  - adjusting the client's cache eviction algorithm to be conservative about kicking out policy files
> If revalidation is required, that only gets you a 304 instead of a 200
> -- which is probably no difference, if a typical CSP file can fit in
> one packet.

What does revalidation have to do with cache eviction?

>>  - implementing connection pre-heating and HTTP pipelining (as Mozilla is currently) to decrease the impact of making that request
> You don't know what policy-uri to fetch until you've started to
> receive the HTML response.  At that point, you can't fetch any
> external resources until you've processed the policy, because you're
> not even allowed to request banned resources (as I read the spec).  So
> that's still an extra round-trip added to processing of every page if
> the policy-uri isn't cacheable.

Please re-read the thread; the idea is to use a well-known URI, which is indeed known ahead of time.

>>  - 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.
> Doesn't help with default caching headers.

Wasn't purported to.

> Any web spec has to account for the fact that most authors are not
> going to optimize.  A feature that silently adds an extra round-trip
> delay to every request is going to slow down a lot of sites (if it
> becomes widely used), because the overwhelming majority of site
> authors do not have the expertise to do even basic performance
> analysis.  Web standards shouldn't have sharp edges -- they need to be
> hard to misuse.
> As far as performance goes, a very large percentage of hits tend to
> have clean cache on most sites, so inlining the policy is typically
> going to be a better idea than linking to it.  If you link to it,
> there's no way to avoid a delay of one round-trip, unless you store it
> at a well-known location and always request it as with favicon.ico
> (which just makes no sense for CSP).  This blog post by Steve Souders
> has an interesting explanation of how Google and Bing are trying to
> avoid first-hit latency without resending too many bytes on a warm
> cache:
> http://www.stevesouders.com/blog/2011/03/28/storager-case-study-bing-google/
> But that sort of thing only makes sense if the resource is quite
> large, several kilobytes at least.  If we expect the large majority of
> CSP policies to be only a handful of bytes long, I really think
> linking to a policy will hurt performance in nearly all cases, not
> help it.

... and I think will help.

If this is *really * a concern (and I don't think it is), one could specify that the policy file has a default cacheability of the browser session (for example). HTTP allows heuristics to be used to cache responses, and this is just one example of how we could do this for CSP.


Mark Nottingham   http://www.mnot.net/
Received on Friday, 15 April 2011 23:51:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:26 UTC