Re: ISSUE 19: Requirements and Usage Scenarios document

Brad, All,

I think Brad's wording captures a requirement we assumed at the start  
of this work and thus has influenced the current model.

Perhaps something like this should be added to the requirements doc.

Regards, Art Barstow
---

On Jan 15, 2008, at 12:25 PM, ext Brad Porter wrote:

> 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 <dorchard@bea.com> 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: public-appformats-request@w3.org
> > [mailto:public-appformats-request@w3.org] 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 ,