- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 09 Oct 2008 17:56:28 -0700
- 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 UTC