- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 25 Jul 1995 16:29:32 +0200 (MET DST)
- To: john@math.nwu.edu
- Cc: www-talk@w3.org
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.
Received on Tuesday, 25 July 1995 10:30:14 UTC