Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

Koen Holtman <koen@win.tue.nl> wrote:
|>Sharing would be possible only when there were multiple domains in
|>the Set-Cookie header.  Sharing with permission is OK, but leaking is
|>bad.
|Whose permission: permission of the user or permission of service
|authors collaborating to do cross-server user tracking?

My intent on mentioning this was to actually *enhance* privacy by leaving
authorization data at the local server and using a server-generated cookie
(containing no client data) to express an authorization state to other servers
with which the local server cooperates.  1:n domain Cookies can be made safer.

The degree of privacy provided under a 1:n domain Cookie scheme depends on the
application, how much you trust the organization that runs the server and the
amount of control a user has over what cookies are sent out in their name.  Our
user community will trust the UCSF Library to maintain their confidentiality.
 But if you allow cookies from or to Jeff and Akbar's demographic hut and
stateful cookie shack to be sent out under your name...

|Many end users are very concerned about the way current netscape
|cookies can violate their privacy expectations...

I'm an xmosaic man myself, and only run netscape chroot /tmp/foo, suid nobody
when I have to view markup in tables.  :)

draft-ietf-http-state-mgmt-02.txt
|7.  PRIVACY
|7.1  User Agent Control
|   * to notify the user when the user agent is about to send a cookie to
|     the origin server, offering the option not to begin a session.

If this works for a 1:1 cookie:domain mapping, why not for 1:n?

Should this part be enhanced in any event to require the user agent allow the
user the option of inspecting the entire cookie (including information on the
domain(s) to which the cookie applies and any payload) prior to responding to a
set-cookie response?

|Including a `max $ to send' mechanism in the state management draft
|conflicts with the goal of taking away the privacy concerns people now
|have with netscape cookies.

|`client-initiated cookies' are more like a business card mechanism (or more
|like a big brother device, depending on your point of view).

Whoa, there.  I didn't suggest enumerating all possible client states, (at
least not until all LINK REL/REV values have been written up :), just used the
commerce states as examples. States could be set on a control panel of the UA
by the user or turned off if desired.  It would be enticing, though, to start a
price war between several competitive web sites by combining a "comparing
price" and the right "max $ to spend" states.

I see client state (again, commerce as an example only) as something more like
a "just looking" lapel pin that a NYC suit shop used to offer its customers so
they didn't get hassled by salespeople. It was the customer's option--they
don't force you to wear it.  This can apply to many other applications than
commerce.

Allowing for clients to express state in this draft while leaving the
enumeration of well-known client states to other document(s) would be a way to
go.

In no case should a UA ever communicate data on behalf of a person or to any
HTTP server without the users' explicit permission.

|What you call `client-initiated cookies' and `client state' has
|nothing to do with session state management.

Cookies allow the server to express its take on what the client is up to, and
can be used to implement the session metaphor or a multitude of other
applications that look nothing like a traditional session.  Cookies are nothing
more than a (possibly) time-limited rule-fired exchange of data at the protocol
level with the client's cooperation. Why not allow the user the option to
express their application-specific state?

-marc

--

Received on Friday, 14 June 1996 17:12:44 UTC