Care and feeding of www-* mailing lists
Tue, 25 Jul 95 20:41:52 PDT

Mike Meyer:
>[Koen Holtman:]
>> Now, if the user agent uses a different session-id for each server it
>> talks to, the above tracking is made much more difficult, if not
>> completely infeasible. Assuming that the user agent does not send
>> Referer: info, of course.
>That was the point of allowing the client to override a
>server-generated session id.

I'm confused. Do you mean to say you want session-id renegotiation by
the client for the case that two servers want to push the same
session-id value on the client?

If you are, under a `one server only' session-id scheme, this does not
make any sense. If server B knows that the browser is using
session-id 31415 on server A, B can compromise privacy without being
able to set its own session-id on the browser to 31415 too. It can
just set it to 27182, or accept the 27182 proposed by the browser, and
`the browser that uses 31415 on server A uses 27182 on server B'.
This information can then be used later to match clicktrails between A
and B.

>Allowing the client to insist on it being allowed to generate the
>session id solves any privacy problems associated with
>server-generated session ids.

I still think that with `one server only' restrictions, both client
generated and server generated have exactly the same privacy problems.
Could you give a counterexample?

>Yes, this allows clients to create a single session ID and use it when
>talking to all servers. That's a bad idea. Does that mean we have to
>require that a client not do that?

No, we do not need to require that. Browsers on single user machines
that are not behind proxies could use the same session-id for every
server without compromising privacy much more, as they already provide
such a constant session-id: their IP address.

> <mike