Re: Session-Id

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
log
   `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

Koen.