|
Note: the "cookie jar" referred to was a cgi script that fed your
computer a nasty 4 kilobyte cookie over and over again. It's been disabled
ever since these pages moved from cml138 (running OS/2) to tempest (running
linux) because it was a rexx script, and those don't run on linux.
One day when I have the time I'll recreate it in pearl.
For now I've |
Unhappy with your snack? Not what you expected? Well, use your noggin:
you wouldn't accept cookies from a stranger in real life. Don't do it
on the WWW either.
Did your access to this page take a longer than normal time?
If the cookiejar page was being automatically reloaded, did each
access take a little longer than the preceding? Then your machine
has got cookies on it now.
Cookies are one of those little things on the WWW that aren't a very good idea. They are little files that WWW sites place on your machine, and that your browser automatically sends back to those same sites the next time(s) you visit them. Many sites use these to keep track of who you are, what you have searched for in the past, what you looked at in their site, etc..., and sell that information to marketers who then use it to place an advertisement that they think is tailored to you on the page you are viewing, or worse yet, in your mailbox (electronic or otherwise).
What's even better is that unless you are savvy to them, you never know cookies are there. It's another win-win situation for The Man®: the more you browse and search the net, the more he learns about you. Can we say "I'm a rat in a maze"? I knew that you could.
Cookies come in two varieties. One type is known as "temporary"; it exists only until you close down your browser. The other is known as "permanent", and exists, stored on your harddrive, until it expires (at a time set by the site that served you the cookie). It is the latter that allows sites to track you day after day, year after year. The former is less of a problem, and I'll concede that it might even be beneficial to a few sites. However all the unscrupulous uses of cookies that I list below would still be possible if they used temporary cookies, so I do not see much distinction between the two types on the basis of evilness. (And the evilness of cookies is what this page is all about.)
Some uses of cookies that I've seen on the WWW are so evil that I feel the need to vent publicly about them here on this page.
Do you use the alta vista search engine? (one of the best on the net, as far as I'm concerned) Do you read Dilbert every day? These are two of the many high traffic sites that contain advertisement banners served from the doubleclick.net domain.
The banners are served from the ad.doubleclick.net site with an insidious twist: the URL of the image source contains, embedded in it, include information about the source site. For Dilbert this is just the fact that the ad is to appear on the Dilbert page; the html source looks like
IMG SRC="http://ad.doubleclick.net/ad/www.dilbert.com/"...However for Alta Vista the URL contains your search! For example, if I search for "car" the html source looks like
IMG SRC="http://ad.doubleclick.net/ad/altavista.digital.com/result_front;kw=car;ord=-294008994"So ad.doubleclick.net knows what you are searching for, and uses it to tailor the ad banner you see. When I search for "car" I always get an ad having something to do with cars.
OK, so what? They show you ads tailored to what you are doing. That's ok. The bad news is that the banner ads are accompanied by a permanent cookie. So somewhere in ad.doubleclick.net's database is a record that you visit Dilbert every day, and that you search for cars on Alta Vista. That, and any other pages you visit that contain an ad.doubleclick.net banner, like
(*) means that the html source informs ad.doubleclick.com of the page you are viewing, allowing statistics to be kept about what interests you).
|
This is where I stopped when last editing this page. Below are pieces of material for the rest of the page. |
Unfortunately this site is now defunct, the candidate in question having lost the election. This site featured a questionnaire form that visitors could fill out to help the candidate understand who his supporters where and what where their concerns. It contained questions on the visitor's geographic location like "What state and town/area code are you from?", on their concerns, like "Rank these four items from most important to least important: crime, economy, foreign policy, taxes". So far everything is fine: it's a corporate site, and it's totally ok for them to ask people to volunteer to answer these questions. However when someone fills out a survey like this they (in the western world) have the belief that the answers will be recorded anonymously.
Instead the answers to the survey were saved in a cookie on the visitor's machine! Every time that visitor returned to the site, their answers to the survey were sent with each www request. Could the dole96 site have tailored the returned pages so that they appealed a little more to that particular visitor's locale and concerns? Say, insert a paragraph about how Dole had visited their state the week before, or a quote from the candidate addressing the visitor's biggest concern? Who knows; The Shadow Knows.
There are two steps to getting and keeping cookies off of your machine:
The cookie blocking built into netscape 3.x is a non-solution. It requires you to click Cancel on a requester every time a site tries to serve you a cookie. Surfing a site that uses cookies becomes a requester clicking hell. The Man® wants you to give up that silly privacy business and go back to accepting cookies like the good rat he knows you want to be. But...
There is a very simple solution to permanently block cookies silently on nearly any browser. You'll need a program called a hex-editor (many good editors (ie TextPad) have a hex-editor mode built in). You load the browser's executable into the editor, and search for the string "set-cookie" (it might be in uppercase). Once you've found it, alter it by changing some characters. For example, you could change it to "no-cookies". Lastly you save the altered file.
Now instead of looking for "set-cookie" in the http
headers your browser will be looking for "no-cookies".
When a site sends a cookie it will send "set-cookie" in the
httpd headers, but your browsers will no longer recognize that as
the code for a cookie. Instead the cookie header will ignored.
No requester, no cookie.
Notes on the above technique:
I've read that setting the ACCEPT_COOKIE option in Netscape's preferences file (NETSCAPE.INI under Win3.1, the registry under Win95/NT) to "2" disables cookies. ("0" means always accept, and "1" means "prompt the user, the two options officially available). This is a less drastic alternative to editing the executable, but I don't know if it really works.
Another trick I haven't tested is to edit Netscape's preferences file (or the registry under Win95/NT) so that the cookie file is /dev/null (for real OSes) or c:\nul (for MS-DOS derivative OSes).
A good trick that works with some places is to alter your /etc/host file so that your computer can't reach those who have served you cookies. This works particularly well with ad.doubleclick.net since they like to have other pages link to them. Just add or modify the line beginning with 127.0.0.1 so it looks like
127.0.0.1 localhost ad.doubleclick.netto your /etc/host file, and you'll never get that cookie again when you visit AltaVista (it also gets rid of the ad, an added benefit) or read Dilbert. I especially like this because in AltaVista the search string you enter is passed on to ad.doubleclick.net, so they potentially have in their database everything you (identified by your cookie) have ever searched for on AltaVista. That's worth $money$!
.site.name FALSE / FALSE id=XY56693can be changed to
.site.name FALSE / FALSE id=XY56639and voilà, you are someone else!
Furthermore some sites don't check the contents of cookies very
carefully for validity (after all why should they: they placed it on
your machine without your knowledge---who would have altered it?) You
can freak out or even crash their cgi scripts by scrambling their
cookies in between visits to their site. One thing that commonly screws
up cookie handling programs is feeding them a monster cookie in place
of the normal 10 or 20 character string they expect (you can thank C's
historically poor handling of overflow in strings for this). The
cookie(s) that the cookiejar served you are very useful for this
purpose since they are nearly 4Kbytes in size. To use them cut the
long gibberish text after the COOKIE666666 (your exact cookie number
will vary) and paste it in place of the id number in another site's
cookie.
Knowledge is power; information must be free.