Re: Unverifiable Transactions / Cookie draft

On Thu, 13 Mar 1997, Dwight Merriman wrote:
> I would like to propose modifications to section 4.3.5 of the cookie spec. 
> Disabling stateful sessions for unverifiable transactions by default is
> basically equivalent to not allowing them at all, because 99% of the
> population will see no reason to change the default.

It was the explicit intention of the state-management subgroup (as I
understood it, acting as the notetaker for the subgroup) to disallow this
functionality unless the user expressly tried to enable it.  Unless I am
mistaken, the cookie draft has passed last call and is an RFC; and
revisions are being considered only to address implementation barriers.
But in any case, here is some history and some commentary.

First, here are the notes from the state management subgroup meeting in
which we first discussed this issue.  I believe these notes show that
balancing the issues of user privacy and server maintainer desires is a
difficult task.  The 'unverifiable transaction' wording you address grew
out of this discussion.

--- begin ---
Date: Tue, 19 Dec 1995 20:01:27 -0800 (PST)
From: "M. Hedlund" <>
To: Dave Kristol <>
Subject: Re: state management group (12/19/95 DRAFT minutes)


HTTP Working Group, State management sub-group
12/19/95 conference call

Participants: Dave Kristol, Rohit Khare, Lou Montulli, Marc Hedlund, Ari 
Luotonen, Roy Fielding, Shel Kaplan



Lou stated that Netscape was aware of problems with the "domain" 
attribute and had been trying for some time to come up with better rules
for state-sharing between hosts.  He pointed out that the "three period" 
rule does not adequately cover the case of ''.  Marc and Rohit
noted that '.com.' is still a valid Cookie domain setting, and that it
should not be. 

Lou argued that there is a real security issue driving the need for 
"domain": online shopping sites want to isolate secure servers taking 
credit cards from "public" sites.  Therefore, dispensing with "domain" 
and restricting Cookies to one server only would require a significant 
retooling by existing sites, and would create a less secure structure.

Marc proposed that transference of state information from one host to
another could happen outside of the state management architecture through
the use of hidden fields in forms.  Lou replied that hidden fields were
not adequate if the user backs up a history list to add another Cookie
field, and then submits the "stale" form omitting the new Cookie.  Shel 
noted that he had stopped using hidden fields for state maintainence 
because some browsers allow users to edit hidden fields.

Rohit and Shel suggested a "secret sharing" solution: have the Set-Cookie
response header include an identifying token.  If a new host can send that
token, then it is part of the same site and is allowed access to the
Cookies previously set.  Lou pointed out that this requires another round
trip in order for the server to demonstrate its knowledge of the token,
and that all an unauthorized site would need to do is visit the origin
site to learn the token.  He mentioned Koen Holtmann's http-wg list
comments regarding Cookie spoofing, saying that we should avoid denial of
service attacks through unauthorized Set-Cookies.  Marc noted that two
disparate sites could simply agree to use the same token to share Cookies. 

Marc suggested that the user should be given more information about the
cookie being set, and that by having that information available, the user
could decide whether the domain setting was appropriate.  He mentioned the
Netscape security interface, which informs the user when a secure area is
entered and left, and graphically displays the current security state. 
Cookie warnings could be disabled if the user desired.  Dave cautioned
against assuming that this is sufficient -- shifting the problem onto the
user does not solve it, it just avoids the engineering problem.  Rohit
gave the example of a "Delete this file?" dialog that fails to inform the
user of the consequences of deletion.  It was generally agreed that
informing the user alone was not enough. 

Dave proposed that the user could be informed of the sites that could 
access this cookie when it is set.  Rohit noted that a Set-Cookie for 
* might produce a list of [www1-www13], but that could be added later.  Lou said that doing a domain lookup 
would be expensive.

Dave asked if moving one hostname component to the left would produce a 
usable domain setting.  (In other words, if the machine name is 
'', make the domain setting ''.)  Lou countered 
that a server could set its name to '' and receive a domain 
setting of 'com'.

Marc asked if it would be better to use the server's IP address (so, for 
a Class C address, use the first three components).  Rohit said that has hosts in the U.S. and Europe (one organization can have more 
than one block of Class C addresses).

Rohit asked about the possibility that one entity would want to share 
information across hosts in different top-level domains -- for instance, 
hosts in 'com' and 'org'.  Marc suggested that the problem was already 
bad enough without incorporating that functionality.

Roy agreed that this was a difficult problem, and said that user
information dialog boxes which can be or disabled would be acceptable.

Marc and Lou discussed combining a couple of the proposed solutions in 
order to provide layers of privacy protection.  Particularly, combining 
an improved tail-matching scheme with user-notification dialogs was 
mentioned.  Dave suggested tabling the discussion with that resolution 
and the agreement to continue looking for something better.


--- end ---

As we discussed later in the group, the problem with cookie-sharing between
disparate hosts is that it enables hosts to collaborate to share
information collected from users in seemingly seperate transactions.  For
instance, if I go to site A and give out just my ZIP code, and then go to
site B and give out just my age, I would not expect A or B to have both my
ZIP code and age.  If they collaborate in data collection by sharing
cookies, however, it is certainly possible for A and B to both have these
two pieces of data about me. 

As a group (at least, as I understood it) we decided that it was
inappropriate to write a specification that did not address this issue as
best we could.  The notes above evidence that we had a great deal of
trouble arriving at a workable solution.  (While looking for these notes I
found some painfully funny references to a "final" cookie draft in February
of last year.  Yet here we are, more than a year later, still trying to
standardize one bloody header.)  The solution we did find was crafted to
prevent cookie sharing, as we understood the expectation of users to be
that data entered at one site reaches that site only.  We cited, in this
discussion, the high expectation of privacy associated with Web browsers --
that they did not identify the user with any serial-id, email address, or
other identifying marks, and that this was common knowledge.

That Doubleclick has formed a business model around a loophole in the
original cookie draft is not, as I see it, any reason to compromise the
privacy of future Web users.  I think it is deplorable that you would ask
to modify an agreed-to standard for your commercial gain.  Indeed, as I
describe above, it was a set agenda item of the state management subgroup
to close the loophole in question. 

You suggest, as a solution to your concern:

> 4. Explain the risk in the spec, and let the browser designer choose an
> appropriate solution for his or her customers.  In my opinion, things which
> are not interoperability issues and can be deferred to the software
> designer should be.

You seem to be suggesting that we, as protocol designers and implementors,
ignore the social implications of our work.  Especially given the
widespread adoption of Web protocols, I take strong exception to this
suggestion, and urge members of the working group to reject the above as a
plausible course of action.

But again, I believe this discussion to be moot for the first RFC covering
state management.

M. Hedlund <>

Received on Friday, 14 March 1997 01:52:36 UTC