Re: To cookie or not to cookie

I would warn against throwing the baby out with the bathwater here.  I think the problem is not with the technical solution.

The problem access-control is trying to solve is very simple.  access-control is trying to make it easier for a site to share its data with another site.  The current browser same-origin policy exists for a good reason to protect a large class of malicious behaviors, but prevents a large class of legitimate applications. 

What we're hearing from Mozilla is that allowing a site to share data with another site isn't something they're security folks are particularly comfortable with, and absolutely not if that site wants to share is user-specific data.

If I were a security lead at Mozilla, I would feel the same way.  From a liability standpoint, this is a big change.  If your first-and-foremost goal is to prevent that press release that says "Firefox leaking personal data around the web" then you absolutely don't introduce access-control at all (as sites can encode user credentials in the headers instead of in cookies and cause the same problem.)  You certainly don't want to do this without other vendors doing the same.  

Consequently, I'm not sure our problem is in the merits of the technical solution. Our problem is that we're trying to give site owners a powerful tool and Mozilla (and perhaps the others, though I haven't seen them speak on the public alias) doesn't want to risk giving site owners any more sharp objects.  

So the tool we invented seems to solve the problem cleanly and simply, but it may not be a tool that Mozilla is willing to put into the hands of site authors.  

This is too bad IMHO as I believe site authors have to deal with a wide-range of far more subtle security vulnerabilities already.  I'll also state I believe that allowing sites any ability to selectively share data (even without cookies) is better than the present "no sharing" policy.

--Brad

Thomas Roessler <tlr@w3.org> wrote: 
On 2008-02-26 04:44:32 -0800, Jonas Sicking wrote:

> 1. We can leave the spec as is and say that mozilla is intentionally
>    only implementing a subset of the spec at this point.

> If it comes to this we will likely simply drop support for access-control 
> for firefox 3 in order to not hinder deployment by other vendors of the full 
> spec.

> 2. We can change the spec to say that cookies should never be sent.

> 3. We can change the spec to allow for requests both that include
>    cookies, and requests that don't include them. We'd further say
>    that before the UA makes a request that do include cookies it
>    should get the users permission to do so first.

> If we go with 3, note that for the next firefox release we would
> then act as if the user always denies the request to send
> cookies. Implementing UI to ask the user is not going to happen
> for this release. Nothing would prevent it from happening next
> release though.

What this boils down to is that FF3 will not include the model
that's at the basis of the access-control spec.  I would caution
against any of the optional (or "leave it to the implementation")
approaches here, as these will mean a desaster for interoperability.

The "don't send cookies" (and, I presume, by extension "don't send
any ambient authentication data") approaches mean that user
authentication suddenly needs to be based on credentials that are
accessible to the data using site. Which is a rather heavy change to
the solution space here.

> That wouldn't actually change anything at all. The major concern
> is sites sending replies that contain the users private data to
> GET requests that include cookies. This will happen even if the
> reply can't set additional cookies.

I'm slightly surprised that GET turns out to be the main concern,
but so be it.

> I realize a lot of people are probably going to be disappointed
> with this decision, me included. But I hope we can find a way
> forward that minimizes the disappointment, even if that includes
> removing support for any of this from the next firefox release.

As this means the access-control specification as it stands now is
losing its one known browser implementation, it strikes me that we
need to take a step back as a community and find out how we *really*
want to deal with mash-up authentication and authorization.

Regards,
-- 
Thomas Roessler, W3C