W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Feedback on Access Control

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 24 Jan 2008 10:37:47 +1100
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-Id: <0AA88569-B515-4590-B4C4-6061FA864BA4@yahoo-inc.com>
To: Anne van Kesteren <annevk@opera.com>

On 24/01/2008, at 10:30 AM, Anne van Kesteren wrote:

> On Wed, 23 Jan 2008 22:17:36 +0100, Mark Nottingham <mnot@yahoo-inc.com 
> > wrote:
>> BTW, I understand the motivation for this now that OPTIONS is used,  
>> but you still have a clock sync problem.
> Race conditions are already covered by the specification. Authors  
> are advised to check to the Referer-Root header to prevent such  
> issues from occuring.

I didn't say it was a race condition, Anne. Consider a naive  
implementation that use a local clock to determine when the policy  
expires; e.g., if it expires at 1pm, and the local clock is  
incorrectly indicating that it's 12:30pm, the implementation will see  
an expired policy and be unable to fetch a valid one. This can be  
avoided by using an offset from the Date header, but you need to  
specify that.

Another (probably better, based upon experience with caching) approach  
would be to use a delta rather than a http-date.

BTW, regarding race conditions -- you're effectively requiring authors  
to check referer-root to be really secure. Why is it unacceptable to  
use this as the primary mechanism again?

>> Also, HTTP caches won't be able to exploit this. I'm thinking  
>> especially of HTTP accelerators (e.g., Akamai); OPTIONS traffic is  
>> going to create a lot of undesirable back-end communication for  
>> them, until they come up with a workaround. My main concern is that  
>> different intermediaries are going to come up with different  
>> strategies for caching OPTIONS results.
> OPTIONS is part of the traffic that is non-static. I'm not sure how  
> much you can optimize that by using HTTP accelerators. Again though,  
> the idea is that the request reaches the server and that the server  
> specifies an HTTP-date indicating how long the policy is valid.

You're making the assumption that per-request OPTIONS has to be part  
of the solution. Using a well-known location and using the Referrer- 
root alone both interact well with caches.

Mark Nottingham       mnot@yahoo-inc.com
Received on Wednesday, 23 January 2008 23:38:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC