[99996] in RedHat Linux List
Re: Cookies location > /dev/null...?
daemon@ATHENA.MIT.EDU (Ramon Gandia)
Wed Nov 18 00:55:09 1998
Date: Tue, 17 Nov 1998 20:50:47 -0900
From: Ramon Gandia <rfg@nook.net>
To: redhat-list@redhat.com
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
Statux wrote:
>
> point is.. if you don't want cookies being written.. then turn them off. Why
> not just leave cookies on or don't visit sites that require cookies. this
> discussion is pointless... make a decision and stick with it.
Lets talk about this a bit, because I am involved in this fairly
heavily.
Here at Nook Net, customers -when they find out what cookies are-
express a desire for privacy. Therefore I installed Junkbuster,
which, among other things, eliminates cookies. the browser
stays cookie enabled but the request for cookie never goes out
past the Junkbuster.
[Let me clarify that cookies are ASKED for by the user, not SET
by the server as is commonly supposed. When you load a page,
the header (which is not visible in the source code) has the
cookie request code. This request goes out to the server that
is assigned to it. Often it is NOT the server of the site the
user is visiting, but a site like ad.doubleclick.com or
linkexchange
or one of those national cookie depositories].
The problem here is that a lot of sites simply will NOT work
without the cookies. They act dumb, or do not let you do all
sort of things like send posted data (forms you fill in).
I call these SHORT TERM cookies. It has nothing to do with the
expiration date of the cookie as desired by the web site, which
is usually years in the future.
In Netscape and Explorer, cookies are written to RAM (memory)
and as long as your browser has not been shut down, the cookies
remain in RAM. When you exit the program, ie, close Netscape
or Explorer, the cookies are written to a cookie file or a jar
file.
When the program is restarted, the cookies in the file are
reloaded into RAM (or available for reloading into RAM).
Let us now see how this could affect privacy. YOu are an
unknowing user. YOu come in on a modem and get a dynamic
IP address which is no help to the remote server. YOu also
have an IP name, like ome-24.nook.net meaning that my DNS
is reporting that modem port #24 has this name. Of course,
this is Joe Smith, and next time he logs on he will be on
a different IP address and port number, so its no help to the
remote server. Likewise, when Jane Doe logs on the internet
via modem, she could get the same IP and port number, but she
is not Joe Smith.
However, the remote server plants a cookie that simply says
"User # 1234". Now, whenever Joe Smith logs in, regardless
of his IP address or domain name address, he is advertising
himself, via the cookie, to be User # 12345. Jane Doe herself
is user # 4567.
Let us now assume that Joe Smith fills out a web form giving
his Name, Address, Social Security number and phone number.
OUch! Now, the Cookie database knows that
User# 12345 is Joe Smith, Box 340, Nome, Alaska, telephone
numbe 907-443-2487 and has social security number 574-29-0868.
Double ouch.
Whenever Mr. Joe Smith visits that site, OR any site with whom
cookie database information is shared with, they know who he
is. The database will eventually accumulate purchasing habits,
spending amounts. It will know that Joe Smith has a preference
for Sex Artifacts, Dildoes and the like and spends big bucks. He
is a candidate for email or regular mail advertising of Sex
Products, and the web pages presented to him as he clicks his
way thru are oriented to this sort of thing.
Jane Doe, on the other hand, is a conservative buyer, more into
jewelry, antiques and historical books.
Now Mr. Joe Smith crashes his computer (or erases his Cookie
File).
Next time he logs in, there is no cookie. No one knows who he
is. But soon enough he signs on to our X site, and gets a NEW
cookie, User $7895, and if he gives one of the identifying
data things, like a Credit Card Number, he is instantly correlated
in the database, who now knows all about him AGAIN.
The trick here is NOT to create the database. Here is where
having a /dev/null file in Linux or a Write Protected cookie file
in DOS/Windows is valuable. This is because from Session to
Session the cookie does not get saved. Therefore, the database
cannot be easily built up. It can, but would take a lot of
hassle and the possibility of errors.
For this reason, to those who MUST have cookies to navigate
certain sites, I advocate very strongly these two pieces of
advice:
(1) Do not fill forms out uneccesarily, specially with
sensitive data. If all that they want is a name and email
address just so you can browse, GIVE A FALSE ONE. Save your
real name, VISA card number etc. for serious uses only.
(2) Trash all cookies when you exit Netscape, Explorer etc by
using the /dev/null link or the write protected cookie file.
This preserves the usefulness of cookies which is to carry the
STATE of one web page to the next,without allowing it to
subvert that use to Marketers, mass merchandisers and the like.
I am going to get static about this that "Cookies are Not Used
That WAy." Nuts. I get offers to join these Cookie Databases
here from time to time. ISP's get that sort of stuff, I guess,
maybe becasue we operate web sites. It is not the intended
use of cookies as they were first envisioned (or so the authors
claim), and Netscape to this day insists they are innocent. But
marketeers have a different agenda, so there it is. If you chose
not to believe me, that is your problem. Its like Sex. If you
believe her/him when he says "I don't have AIDS!", well, its
nice that you are a trusting fellow, aren't you? But that is
precisely how it spreads. Sex, shared needles...and now COOKIES.
--
Ramon Gandia ==== Sysadmin ==== Nook Net ==== http://www.nook.net
285 West First Avenue rfg@nook.net
P.O. Box 970 tel. 907-443-7575
Nome, Alaska 99762-0970 ======================= fax. 907-443-2487
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
