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?
Also, what are your thoughts on #25 and #30?
-Thanks, Art Barstow
On Oct 9, 2008, at 8:56 PM, ext Jonas Sicking wrote:
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
