Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32
On Thu, 16 Oct 2008 16:13:50 +0200, Arthur Barstow [EMAIL PROTECTED] wrote: Thanks for the information Jonas. Anne - Jonas indicates #26, #29, #31 and #32 have been addressed in the latest Editor's Draft. Thus an implication they can be closed. Do you agree they have been addressed and thus can be proposed to Close? Yeah, that'd be cool. (Same for the issues you e-mailed about separately, 10, 11, 12, and 14.) Also, what are your thoughts on #25 and #30? Yeah, we decided to fix those today. That hasn't happened yet though. As for ISSUE-24, I think that can be closed for now although the list is sort of open for modification. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32
Jonas Sicking wrote: * 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. The list is here: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html / Jonas
Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32
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
