At 06:06 PM 5/28/96 +0100, Rzepa, Henry wrote: ..deleted...
c) The least well known mechanism for garnering information about the user is the Persistent State Cookie. This is implemented at the server side using some CGI program or script, and supported at the Client side by e.g Netscape. Its a way of remembering some state requested by the user and writing it in the user's local file base, normally into a file called Cookie or "Magic Cookie". Next time the user connects to a site, the server can retrieve the information in this file (via the browser) and act accordingly. At its simplest, a Web page can request you identify your Browser. Next time you connect, it will know this, and take you to the correct page immediately. At its darkest, a visit to site (b) can interrogate the Cookie file created by site (a), and let site (b) know who you have visited previously.
Now this example is NOT possible, at least in Netscape generation 2.0x and 3.x Browsers. Cookies can only be interrogated by the URL that CREATED the cookie, or a 'lower' level URL. Take the following URLs for example: a) http://www.ch.ic.ac.uk/hypermail/chemweb/ b) http://www.ch.ic.ac.uk/hypermail/chemweb/lowerlevel c) http://www.ch.ic.ac.uk/motm d) http://www.netscape.com/ URL b) is can access URL a)'s cookie, but other than that one case NONE of the different URLs can access cookies created by the other URLS. (for example a) CAN NOT read b)'s cookie) I believe that the current 3.x Betas have gone one step further and required EXACT URL matches for cookies. This has caused a lot of compatibility problems for sites which stored some general cookie at a 'higher' level, and accessed it from 'lower' level pages, such as b) accessing a)'s cookie above. I think that pre 2.0x Netscape versions have always required at LEAST the domain name to match to read a cookie (a,b and c above could access each other's cookies, but not cookies created by d.)
If of course the user deletes the cookie file between visits, this mechanism is stopped, but HOW MANY DO? (PS there are programs that can do this automatically. I run one for example on my Mac).
There are security aspects to cookies; see http://home.netscape.com../newsref/std/cookie_spec.html
It appears that this page has NOT been updated with all of the current cookie restrictions. The restrictions specified here are very stringent though, and basically cover everything I described above.
However, this is largely written in programmingspeak, and not easily comprehensible. It is not obvious to me what sort of information could be stored in cookie headers, or garnered by Javascript or whatever (ie SMILES strings?)
Where I do worry is that Netscape does not seem to implement any mechanism for switching the persistent cookie state off.
I don't see a problem here myself, since only the CREATOR of a cookie can access it in the future. If a given URL created a cookie then I don't care if only THAT URL can access that cookie in the future, because, after all, THAT URL stored the information there in the first place.
Anyway, I think that "privacy" on the Internet should be a bigger issue. I know some people will say that by "browsing", you loose all rights to privacy, but as I think I indicate above, there are various levels of potential infringement
I personally am more worried about a 'real world' example that DOES affect me, and that is magazines (and the like) selling their subscription lists to 'junk mailers' or whomever will by them. For some programming related items I will receive 10 copies of junk mail, with slight variations in my name, address, title, etc. This is common in the US, and extends to mail order catalogs selling your name (and what you buy ?), etc. I have found that most 'online' mail order companies have an option to specify that you do NOT want to allow your name to be sold to others, and this a certainly an option I look for.
Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ (Eudora Pro 3.0)
-tim Tim Maffett tim@mdli.com Principal Architect, Internet Technologies MDL Information Systems, Inc. ----- chemweb: A list for Chemical Applications of the Internet. Archived as: http://www.ch.ic.ac.uk/hypermail/chemweb/ To unsubscribe, send to listserver@ic.ac.uk the following message; unsubscribe chemweb List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
participants (1)
- 
                
                Tim Maffett