I think the requirement is probably closer too: "Must not require content authors or site maintainers to implement new or additional security protections to preserve their existing level of security protection."
The objective originally was not to try to "fix" or "change" the existing security semantics or to otherwise fix the various brokenness of browser sandboxing as that was clearly out-of-scope and more appropriate for the Security activity. As a consequence, it also shouldn't be necessary to be more restrictive than the existing sandbox requires. The concern being that if we're overly restrictive in a way that inhibits valid use cases in order to be more restrictive than the market expects browsers to be today, then the market will produce a less restrictive version to enable the other use cases. Much of the data that is interesting to share between sites is cookie-protected (package tracking data, ticket-itinerary data, etc), so disabling those use-cases could be seen as unnecessarily restrictive. The biggest change enabling cookies is that instead of a new attack vector, it enables a new vector for cross-site sharing of user-data that isn't available today. This is more a privacy issue than a security issue. Without this mechanism, sharing of user-data is a more difficult network-to-network interaction on the backend. That said, the browser doesn't make any real statements about privacy and protection of user-data between sites. The policies around how user data is shared or protected cross-sites are established with a privacy policy between user and site today and the browser doesn't really get involved. Arguably that is the appropriate solution. --Brad David Orchard <[EMAIL PROTECTED]> wrote: Anne, If Cookies would be sent as part of more requests because of deployment of the Access Control spec, then isn't this spec opening a new attack vector? I understand your point that cookies are already sent under img, script and form, but this is something newer and in addition to those. I think one of the rough requirements we have is no new attack vectors. Now maybe that requirement ought to be something like "no new attack vectors that aren't already similar to current attack vectors such as cookies under img, script and form". Cheers, Dave > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Anne > van Kesteren > Sent: Tuesday, January 15, 2008 7:53 AM > To: Jon Ferraiolo > Cc: WAF WG (public) > Subject: Re: ISSUE 19: Requirements and Usage Scenarios document > > > On Tue, 15 Jan 2008 15:20:46 +0100, Jon Ferraiolo > wrote: > > I described a CSRF scenario in > > > http://lists.w3.org/Archives/Public/public-appformats/2008Jan/ 0072.html. > > Search for the word "attack". My example attack vector depends on > > cookies being sent as part of the cross-site request and > assumes that > > the simplicity of using Access Control would result is widespread > > adoption by a new generation of unsophisticated web service > developers > > who will open up their APIs to mashup applications without > > understanding the consequences. > > Note that the big CSRF worry here is that cookies are sent with the > > requests. > > Cookies are already sent for , , and > requests. Nothing new. If people mindless opt in we have > might have a problem (though it's really the people that opt > in that do), but I would expect that dalmationlovers.invalid > & co are using some off the shelf software. > > > -- > Anne van Kesteren > > > >
