Java Cookie Demonstration
This document demonstrates web browser client access to cookies from a java applet. Special thanks to Tom Vrankar for this script, for more information about additional scripts please visit Tom Vrankar's Java Collection.
This applet will work with Netscape Navigator 3.0 and above; hopefully it will eventually work with Microsoft Internet Explorer 3.0. In any case, java execution must be available and enabled. The complete package including the java source code, and this page is available for download in zip format.
In the applet below there are two text components. In the first, you may enter any string to set into your browser as a cookie. The details of the Set-cookie: protocol are followed. In general, cookies are of the form name=value. You may set more than one cookie, but only one with a given name as they will overwrite.
The second text component displays all cookies visible to the applet. It's updated whenever you hit <Enter> or <Return> in the first.
Cookies can take various attributes as described in the protocol spec, and most default to something useful. Notice that only if the domain and path attributes match that of the host document (the default) can a cookie be stored or retrieved.
By default, cookies exist until the browser is exitted; they disappear when you close the browser. Other persistence behavior may be requested with the expires attribute. This sets the time at which a specific cookie is to be deleted from the browser. Here are two commonly used values for expires, to copy and paste onto your cookie assignments:
Your browser stores cookies that persist beyond the current session in a file named something like cookies.txt or cookie.jar, or in a directory named cookies. It is (or consists of) a text file; find it and have a look inside. Delete a line, or a file, and the next time you start your browser, that cookie will be gone.
Cookies previously stored in the browser are not only retrievable by applets but are also transmitted to the server with all domain/path-matching document requests. User "clickstreams" -- a trail of which sites have been browsed by an individual user -- can be remotely tracked by combining these features of various components of the World-Wide Web: browsers storing and transmitting cookies; browsers reporting referring documents in each request; and inline images being served from third-party sites.
Those little advertising graphics and "Top 5%" and "Browser Now" icons can serve more than one purpose. When you view a document containing such icons, your browser sends the matching cookie and the URL of the document on which the graphic appears to the site serving the icon, which needn't be the same as that of the rest of the document. The advertiser's icon server can eventually construct a database listing all documents (containing their icons) which have been viewed from the browser sending a specific cookie. This database would accumulate a detailed profile of the user of that browser.
Further, if you provide any personal information at a participating site, such as via a registration form, this information may be associated, using such a cookie and referrer field database, to your clickstream through all participating sites. In other words, these technologies make it possible for you to be easily followed through "cyberspace", regardless of whether you browse from home or office. Sites carrying this kind of advertising could be compromising (betraying?) your privacy.
Of course, if you have a static IP (SLIP or PPP) and don't go through a proxy server or anonymizer, you're practically sending your name and email address with each connection; all web sites log the address of the client host accessing them. And permitting insecure active content such as plug-ins or Active-X is just asking for it (Java seems okay for now).
You may wish to enable cookie alerts in your browser so that you are informed whenever a cookie is attempting to be set. This gives you the opportunity to view the cookie first, and the option of refusing it if you don't want it following you around. If a site obnoxiously insists on setting a cookie for every page and every graphic, you could consider using a better, competing, site. Although theoretically cookies can be used to provide terrific features to the web, in practice a user seldom benefits from accepting a cookie. You may need to switch to a better browser in order to obtain this level of privacy:
You may also wish to encourage your browser vendor to follow NCSA Mosaic's lead and additionally provide a user switch to disable the anti-privacy Referer field.
Scripting and documentation © 1997-98 Tom Vrankar. All rights reserved
Packaging and distribution Copyright © 1997-98 Cookie Central, All rights reserved.