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

Marc Salomon:
>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.

So you are proposing a kind of authenticated anonymous persistent
user-IDs with limited scope, managed by a local server?  I think that
to make this work, while excluding `bad' forms of cookie sharing, you
would need many additional protocol elements, completely beyond the
scope of the state management draft.

[...]
>|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.  :)

In that case, you should be especially concerned about any privacy
loss due to state management cookies, as we expect them to be
implemented in the next xmosaic version.

>
>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?

It does not really work for 1:1 cookies either, most users will simply
disable such checks, while expecting (quite unreasonably, perhaps)
that nothing really bad will happen.  1:n would allow something really
bad to happen.  This is the real reason why 1:n is a bad idea, see my
previous message.

[...]
>|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.

I misunderstood you, then.

> States could be set
>on a control panel of the UA by the user or turned off if desired.

That seems like an interesting idea to me, but I can't see the
connection to stateful session support.  Adding protocol mechanisms
for this to the state management draft would just delay stateful
session support.

All in all, I see no reason to delay the state management draft. 

I think multi-domain cookies are a bad idea, and under the assumption
that they are not, nothing would be lost if they were introduced in a
later upgrade of the state management mechanism.  `max $ to spend'
control panels may be a good idea, but again nothing would be lost if
they were introduced later.

>-marc

Koen.

Received on Saturday, 15 June 1996 06:50:20 UTC