Re: policy-uri is slow

On 15/04/2011, at 1:26 PM, Adam Barth wrote:

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


Possibly; it depends on how likely it is for CSP to be widely-deployed. After all, browsers already make requests for favicon.ico (and p3p.xml, although that isn't as widely used). 

If CSP isn't going to be common, doing this might not make sense, unless the mechanism is piggybacked upon for other sorts of policy that makes it more common.

A modification might be to have a flag -- rather than a full uri -- in the response, so that the browser knows to check the well-known URI. Anything to get rid of those response bytes.

WRT latency -- not really. If browsers are already pre-heating connections, why not use them? Additional latency should be minimal, unless the policy file is dynamically generated or extremely large (both unlikely, I'd hope), or the connection extremely unreliable (in which case, there are bigger problems than this).

Anyway, my high-level feedback is that having some sort of ability to NOT have policy in every response is a good thing; if it hurts performance in some cases, those sites may shy away from it, but removing the mechanism doesn't help them (they can still put policy in-response) and it doesn't serve the needs of folks who don't want to be blatting those policies in every response.

Cheers,




--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 15 April 2011 03:36:49 UTC