W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 09 Oct 2008 17:56:28 -0700
Message-ID: <48EEA83C.4060606@sicking.cc>
To: Arthur Barstow <art.barstow@nokia.com>
CC: public-webapps <public-webapps@w3.org>

Arthur Barstow wrote:
> 
> The following issues were created during the July 1-2 f2f meeting 
> (minutes at [1], [2], respectively).
> 
> Would someone that attended that meeting please elaborate these issues?
> 
> In particular, has the Issue been addressed and thus can be proposed to 
> be Closed?
> 
> -Regards, Art Barstow
> 
> [1] <http://www.w3.org/2008/07/01-wam-minutes.html>
> [2] <http://www.w3.org/2008/07/02-wam-minutes.html>
> 
> 
> * ISSUE-25 - Revocation of cached access grants
> http://www.w3.org/2008/webapps/track/issues/25

The issue was the ability for a server to revoke a cached preflight 
result. Or ensuring that if you are MITMed in a cafe or some such that 
the cached result doesn't linger too long.

I *think* this one is resolved since the cache is cleared if access is 
ever denied (haven't implemented this part of spec yet so not 100% sure).

We decided that implementations should be allowed to clear the cache at 
any point if they so desire, which means that implementations are 
allowed to limit the cache time to 24 hours or some such (something that 
firefox will do).

Hmm.. though looking at the spec I can't find where it says that 
clearing items out of the cache at any point.

> * ISSUE-26 Wildcarding is currently possible together with cookies which 
> could result in exploitable servers.
> http://www.w3.org/2008/webapps/track/issues/26

This is about not allowing the '*' syntax when fetching private data.

This has been address as this is no longer allowed per spec.

> * ISSUE-29 Should Access-control allow DNS binding defense?
> http://www.w3.org/2008/webapps/track/issues/29

This should again be addressed by the spec allowing the implementation 
the clear the cache at any point.

> * ISSUE-30 Should spec have wording to recognise that User Agents may 
> implement further security beyond the spec?
> http://www.w3.org/2008/webapps/track/issues/30

I guess this is the part that needs to be addressed by adding wording to 
the spec to say that the cache can be cleared/ignored at any point.

I wrote up a list at some point and I think sent it to the public list 
about security measures that Firefox was going to take beyond the spec.

> * ISSUE-31 Allow POST without a preflight with headers in a whitelist
> http://www.w3.org/2008/webapps/track/issues/31

This is addressed in the spec. POST is now allowed when the content-type 
is text/plain.

> * ISSUE-32 Each redirect step needs to opt in to AC in order to avoid 
> data leaking
> http://www.w3.org/2008/webapps/track/issues/32

I think this is addressed in the spec.


So all in all it seems like once ISSUE-30 is fixed all of the above can 
be closed.

/ Jonas
Received on Friday, 10 October 2008 00:59:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT