Re: Session-Id

Koen Holtman (koen@win.tue.nl)
Tue, 25 Jul 1995 16:29:32 +0200 (MET DST)


John Franks:
>In article <199507241015.MAA06204@wswiop05.win.tue.nl>, Koen Holtman writes:
>>
>> 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.
>
>Can you explain this? I don't understand how redirection affects
>these issues.

Take a browser that has session id SA for a.com and SB for b.com. Now
suppose the user clicks the link http://a.com/blah.gif, which results in a
request to a.com with session-id SA. Instead of serving a gif picture,
a.com now redirects the browser to the URL
http://b.com/bin/grab_id/SA ,
embedding the session-id SA just recieved in the URL. The bin/grab_id
script on b.com now extracts the b.com session-id SB from the request
headers, the session-id SA from the URL, logs (SA,SB), and then serves the
gif (or redirects back to a http://a.com/bin/grab_id_serve/SB which serves
the gif).

Result: b.com knows the pair (SA,SB), and this allows a.com and b.com to
match clicktrails. The browser user will generally not notice that he just
gave away some privacy.

Come to think of it, the same scheme is possible without redirect, by a.com
serving a page with an inline picture with URL http://b.com/bin/grab_id/SA.

To fix this privacy problem, the browser can omit sending session-id's when
resolving redirection and loading inline images.

Of course, this will not stop a.com and b.com from using less accurate
and/or less stealthy methods of matching clicktrails.

>John Franks Dept of Math. Northwestern University
> john@math.nwu.edu

Koen.