(Re-expressing what I have said before multiple times) The extra complexity with opting in to cookies is worth it. I realize that (as has been pointed out) servers really need to implement CSRF protection regardless of Access Control, but AC has the potential of greatly increasing community awareness and adoption of enabling cross-site requests, which not only means more novice developers (who don't know about CSRF) adding AC support to their Web site, but also more hackers who will scour the Web looking for sites that are vulnerable to CSRF attacks. It is much better to not transmit cookies by default and require that the server developer do a little extra work (presumably one additional header or slightly different markup within an existing header) to trigger the transmission of cookies. Also, don't forget to put STRONG WARNINGS in the spec in the section that explains how to activate transmission of cookies (or opt-in to other headers).
Jon
Web Application
Formats Working
Group Issue To
Tracker <sysbot [email protected]
[EMAIL PROTECTED]> cc
Sent by:
public-appformats Subject
[EMAIL PROTECTED] ISSUE-26: Opting into cookies
[Access Control]
06/06/08 05:23 AM
Please respond to
Web Application
Formats Working
Group WG
<public-appformat
[EMAIL PROTECTED]>
ISSUE-26: Opting into cookies [Access Control]
http://www.w3.org/2005/06/tracker/waf/issues/
Raised by: Anne van Kesteren
On product: Access Control
It has been suggested that because Access-Control also allows read access
and not just making the request explicit optin into cookies specifically is
desired.
The benefit would be that servers can more safely enable Access Control
functionality.
The drawback would be that the model becomes more complicated and therefore
more prone to errors and implementation bugs.
<<inline: graycol.gif>>
<<inline: pic03849.gif>>
<<inline: ecblank.gif>>
