W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: HTTP State Management Mechanism draft question

From: Dave Kristol <dmk@allegra.att.com>
Date: Tue, 13 Aug 96 17:59:42 EDT
Message-Id: <9608132159.AA06909@zp>
To: pgrand@netcount.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, iesg@ietf.org
Paul Grand <pgrand@netcount.com> wrote:

  > In my review of your document "HTTP State Management Mechanism" dated July
  > 19, 1996, I have come across two points that I find would impede commerce in
  > web usage by eliminating state retention mechanisms.
  > 
  > In the next to last paragraph of section 7.1, it is suggested that at the
  > conclusion of a user agent session, the user agent inquire of the operator
  > if the state information should be retained.  The proposed default value is
  > "No".  This makes it more costly in user agent time and server resources to
  > reestablish the user agent's state.  This raises privacy concerns as it
  > makes it mandatory for one web service to maintain a central database of
  > users' state information.  What is the reason for this?

One of the underlying themes of the State Management Mechanism (aka,
"cookies") proposal is to provide a user with control over the
information about them that accumulates with their Web accesses.  As
articles in the popular and trade press have shown, users are surprised
and disturbed that their Web accesses may be aggregated to form a
profile of what they're doing.  Many say they don't like it.

One way to grant users control is to alert them when things start to
happen, such as when a stateful session begins.  Another is to ask
them, when they exit a user agent, whether they want to retain the
session information or discard it.  The default is to protect the user.

If it's important to a service that the state information be retained
long-term (and section 3 of the I-D makes the point that sessions are
assumed to be relatively short-lived), then it should make a point of
explaining to users why this is so and encourage them not to discard
it.  Let the users decide.  If the user doesn't want the state to be
retained, then issues of cost to the server and user agent are
irrelevant.

As Harald Alvestrand said [in a private message], it's hard to see how
the proposal *reduces* privacy.
  > 
  > In section 4.3.5 eliminating the ability of having "unverifiable"
  > redirection impairs the ability of the web service (chosen by the user agent
  > operator) to engage in using the services of a third party for advertising,
  > content building, download specialized "plugins" or other usage.  This hurts
  > web commerce.  Why is this proposed?

Again, the purpose is to reduce the ability to "do things behind the
user's back." That section also says

    User agents may offer configurable options that allow the user agent, or
    any autonomous programs that the user agent executes, to ignore the
    above rule, so long as these override options default to ``off.''

Once again, this reflects the theme of informing users and letting them
decide.  Users are not unconditionally prevented from doing anything;
they are given choice.  Recall, too, that web services may still use
third-parties for all the things you describe.  They are just prevented
from surreptitiously creating sessions while doing so.

  > 
  > The implementation of these two items would have two deleterious effects:
  > First, they would decrease the privacy and anonymity of web users by storing
  > data about user agents / individuals on servers, not at the user agent,

That sounds nice, but somehow I suspect they're already accumulating data
about user agents/individuals, with or without cookies.

  > under user agent / individual control.  Additionally, login and password
  > exchanges would be required, allowing identity spoofing.

Identity spoofing would seem to be neither easier nor harder than cookie
spoofing.  They're both essentially clear-text.
  > 
  > Second, they would increase the storage, processing and communication
  > requirements of web servers.  Re-establishing inter-session states would
  > require server operators to send and receive extra messages (logins and
  > passwords), extra disk space to keep the personal login, password, and state
  > information, and extra processing to operate a state recover mechanism.

As I said earlier, if users can be persuaded that the information will
be retained for what they consider a good cause, they will likely be
happy to do so, and there is no added burden.  But they must be given
the choice.  And if they choose not to retain the information, the
service operator is violating their trust by attempting to assemble it
in spite of their wishes.

Dave Kristol
Received on Tuesday, 13 August 1996 15:17:57 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:07 EDT