[...]
>Privacy: it seems like letting servers generate the key allows the
>owners of said servers to cooperate to extract more information than
>you would really like them to have. To defeat this, the client should
>be able to tell a server what key it's going to use for a session if
>the server wants session IDs.
This is incorrect. Allowing the client to decide on the key value
will not make the privacy problems go away.
First, if the client uses same the session-ID key for every server (as it
would do in some proposals, the client just generates a key on startup
and always sends it in the From: header), then there is a very great
danger to privacy.
Daniel W. Connolly wrote a few days ago that if service providers pool
their logfiles, then they can get very good statistics
|1) By tracking a user from one host to another to another -- all they
|need do is find one occurrence where the user provides identifying
|information (say, for a free giveaway, or simply to use a popular
|search service). As soon as that occurrence is obtained (along with
|the session id), the user's entire click trail for that session is
|compromised.
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.
However, the redirection (3xx) feature in HTTP would allow cooperating
service providers to obtain (session-id for server a.com,session-id
for server b.com) pairs where both are known (with 100% accuracy) to
originate from the same user agent. This is a sticky problem, but it
can be solved to some degree.
If servers are allowed to determine the content for session-id fields,
they should be only allowed to set them for the session-id field sent
to themselves, not for the session-ids send to other servers. Again,
this restriction makes tracking users from host to host much more
difficult, if not completely infeasible. Again there is a problem
with redirection.
>[...proposal for a symmetrical session-id mechanism...]
>Now, someone tell me why the above is full of holes.
I see no need for your proposed symmetrical session-id mechanism, in
which (if I understand it correctly) clients have the option to
renegotiate on the session key proposed by a server. The option for
such renegotiation does not solve any privacy problems that are not
solved by putting `one server only' restrictions on an asymmetrical
mechanism.
> <mike
Koen.