W3C home > Mailing lists > Public > public-appformats@w3.org > February 2008

Re: To cookie or not to cookie

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 26 Feb 2008 17:21:24 +0100
To: Jonas Sicking <jonas@sicking.cc>
Cc: Anne van Kesteren <annevk@opera.com>, Brad Porter <bwporter@yahoo.com>, Daniel Veditz <dveditz@mozilla.com>, "WAF WG (public)" <public-appformats@w3.org>, Window Snyder <window@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, Jesse Ruderman <jruderman@gmail.com>
Message-ID: <20080226162124.GB71413@iCoaster.does-not-exist.org>

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  <tlr@w3.org>
Received on Tuesday, 26 February 2008 16:21:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 February 2008 16:21:38 GMT