Re: policy-uri is slow

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.)

> 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.

>  - 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.

>  - 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.

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.  I haven't reviewed CSP more than superficially, but it seems
to me that a typical policy would be quite short.  What are some
plausible mock CSP policies that are long enough that they'd actually
be a problem to serve in every response?

If we don't expect normal CSP policies to be more than a few dozen
bytes long, I think policy-uri is just going to give authors the
ability to very easily shoot themselves in the foot for little to no
realistic gain.

Received on Friday, 15 April 2011 22:20:02 UTC