State Wars, part XI (was: Revised Charter)

Before I get started, let me second Dave Kristol's call for the Netscape
Cookie proposal to be submitted as an Internet-Draft.  I don't mean any of
the following to be a bashing of Netscape as a whole; I recognize that
there are cookie capabilities that other proposals gloss over or omit
entirely; and though I think we've talked most of these subjects to death,
I'm more than happy to go another round on www-talk if that's necessary to
meet the needs cookies address.

I wrote:
>> I certainly agree that state-info should be in there, and I _very_ strongly
>> agree that Dave Kristol's proposal is a far superior implementation to
>> cookies.  Most of my complaints with the cookie proposal have to do with
>> privacy, which has been discussed at length on www-talk.  A number of
>> cookie implementations have had serious privacy problems; and I have yet to
>> see an implementation that gives the user any clue as to what the hell it's
>> doing.

Lou Montulli replied:
>Dave's proposal does nothing to solve the privacy issues that
>cookies bring up.

If you think Dave's measures are insufficient, fine, let's talk about it;
but he devotes Section 6 of his proposal to privacy issues, while the
cookie proposal doesn't even contain the word "privacy," much less do
anything to protect it.  To say he has "done nothing" about privacy issues
around cookies and state-tracking is incorrect.

>But [Dave's proposal] does significantly reduce the capibilities.

Well, yes, privacy protection does tend to reduce the utility of tracking
schemes.  To the extent that you're talking about session-info retrieval
and storage, I will address that after discussing privacy issues, below.

There are two privacy concerns here: what the proposals say and what the
cookie implementators have done.

First, what the proposals say.  The key capability ignored by the cookie
proposal and addressed by Dave's proposal is (emphasis added):

>  3.  Either the _user agent_ or the origin server may terminate a
>      session.

The cookie proposal completely ignores the user's possible desire to
disable, suspend, terminate, or reset session-tracking at any point.
Furthermore, it makes no recommendations to user-agent developers as to how
they might provide methods for the user to protect his or her privacy.
Finally, it makes a poor attempt to isolate session information to
particular domains through "tail matching."  _All_ of these issues are
better addressed -- in some cases, extensively -- by Dave's state-info
proposal.

The cookie proposal also makes greater attempts to preserve state
information beyond the scope that might reasonably be expected,
particularly with its use of expiration dates.  Since the same cookie can
be transmitted to a site indefintely (with a very far distant expiration),
cookie sessions have no definite end.  This is in contrast to Dave's
proposal, which terminates state information when the browser's execution
is stopped.

The one attempt the cookie proposal makes to preserve privacy -- "tail
matching" of server domain names to prevent universal cookies -- is
insufficient.  The cookie proposal states:

>Only hosts within the specified domain can set a cookie for a domain
>       and domains must have at least two (2) periods in them to prevent
>       domains of the form: ".com" and ".edu".

Since a trailing period in a domain name is allowed, '.com.' is a legal
domain setting for a cookie that any .com site could retrieve..  (Recent
implementations of Netscape have addressed this, but the language is still
insufficient.)  Even if a trailing period were not legal, the 'two period'
rule is only sufficient in some regions -- '.ac.uk' has two periods in it,
as does '.com.au'.  Furthermore, there's no reason to believe that two
servers in the same domain should share cookie information -- for instance,
two servers at an ISP might be completely unrelated.  (Dave's proposal is
better on this count by restricting info-sharing to a single server, which
is probably as good as it can get.)

Those are some issues of proposal language where Dave's proposal is, as I
said, "far superior" to the cookie proposal in privacy protections.  Beyond
the language of the proposal, however, cookie implementations have shown
the the lack of privacy recommendations leads directly to privacy abuses.

Here are some questions to consider about Netscape's implementation of cookies:

1. Why doesn't the word "cookie" appear in the Netscape Online Handbook?
2. Why isn't the cookie specification URL given in any README or
implementation notes file?  How are users supposed to know what information
is being kept about them, or for how long?
3. Why can't the user turn off the 'Cookie:' header in a preferences pane?
4. Other than throwing out the cookie file entirely, how would a user reset
a cookie for a particular site or all sites?
5. Why is the user cautioned in the cookie file "# This is a generated
file!  Do not edit."?
6. Why is there no visual indicator of cookie transmission in the
navigator, similar to the "secure key" and blue security color bar?
7. In the Mac version, why did the "MagicCookie" file change from filetype:
TEXT (which  could be opened and read with any text editor) in 1.x to
filetype: COOK (which most editors don't recognize) in 2.x?  Do you realize
that this further hampers the users' ability to be aware of state
information?

(3) - (6) above, at the very least, are privacy conerns raised by the
cookie proposal and addressed by Dave's proposal.  I think it unfair to say
Dave's proposal "does nothing to solve the privacy issues that cookies
bring up."  The cookie proposal is silent about these issues, and
Netscape's implementation has shown that it should not be.

Turning away from privacy, to Lou's other concerns:

>In fact, [Dave's proposal] reduces the capibilities such that it is nearly
>unusable for large scale applications such as online shopping.

I disagree (as a programmer for an online shopping site).  I do agree that
an extremely large online shopping site with many stores or large ordering
possibilities might hit an upper limit with the state-info proposal if they
tried to store all ordering info in the State-info: header.  This concern,
however, is not pressing for the vast majority of ordering systems, which
accumulate a small number of items in each session.  I would like to see
the State-info proposal incorporate the cookie proposal's concept of
"path", which I think would solve this problem.

>A simple session ID requires the server to hold all the state
>information.  This leads to the need for large database lookup's
>and distributed database problems.

Only if the ordering information would exceed a reasonable limit for the
State-info header.  I disagree that this makes State-info "nearly unusable"
for shopping carts, and I think we could solve this by adding "path" to the
State-info response header.


M. Hedlund <hedlund@best.com>

Received on Wednesday, 1 November 1995 18:21:56 UTC