// COMPLETE THREAD

Cookie alternatives

5 expanded posts ยท every known parent and child

NODE a00bfcddCookie alternatives
There has been quite a bit of discussion recently about the "cookies"
used by Netscape Navigator and their effects on privacy of users.  Here
is some background and some thoughts on alternatives.

I think the term "cookie" goes back to the 1960's.  According to
legend, there was a virus-like program called "cookie monster" which
would occasionally pop up on people's terminals and say "gimme
cookie".  You then had to type the word "cookie" to satisfy the
program, and it would go away.  The program was hidden in the core
memory of the large, multi-user computer systems which were common in
those days.

I first heard "cookie" used similarly to its current context in the
1970's.  It referred to a data item which would be given by a service
to a client of that service, and which would be used on later
interactions.  I think the usage comes from the cookie monster, where
you imagine the client saying "gimme cookie" to the server.  The cookie
is an "opaque" data item, that is, its structure if any is not visible
or documented for the client.  It has meaning only to the service.

There is a similar concept in cryptography, the "nonce".  A nonce is a
random value which is generated by one party in a cryptographic
protocol and which is exchanged at later stages of the protocol.  The
purpose of the nonce is to prevent replay attacks and to maintain
continuity during the (possibly) many exchanges of data which make up
the protocol.  When the client sends a request to a service it includes
a nonce, and the return reply includes the same nonce.  This way the
client can make sure that this is a reply to its current request and
not something which is replayed from an earlier interaction.

Cookies seem a little more general than nonces, in that nonces are
pretty clearly supposed to be just random numbers, while cookies are
more general and could have internal structure which is known by one of
the parties, although it is usually opaque to the other.

However I think in current usage on the web cookies are most commonly
used basically as nonces, random values whose purpose is to maintain
continuity in a series of interactions.  When a server gives a cookie
to a web browser, that browser supplies the cookie on future
interactions with the server.  The cookie probably does not have any
specific data about the user or the interaction, but is used only to
link up the interactions which take place.  It is most probably used as
an index into a database maintained on the server itself.  Its only
requirements for this purpose are that it is unique and that it can
easily be used as such an index.

One typical usage would be to maintain a "shopping cart" while browsing
at a store.  If I am visiting an online clothing store, I may choose to
buy some pants, a shirt, and a jacket as I browse around.  Each time I
click on the "buy" button, my browser includes the cookie I received
when I first visited the site.  This indexes into a database on the
server which is keeping track of what I have bought.  With each new
item, the cookie allows the server to add it to the correct virtual
shopping cart.  Then when I "check out", again the cookie allows the
server to display everything I bought.

Given that cookies generally work this way it is clear that the notion
of editing cookies doesn't make much sense.  If cookies are opaque data
structures, changing them is just going to make them invalid.  You
might as well just delete them.  This also implies that you don't have
much control over what kinds of information the server is maintaining
in its database which is indexed by your cookie.  In the shopping cart
example, the cookie is sent on every transaction, not just when you
click to make a purchase.  This will allow the server to track your
progress through the site, see which if any ads you have seen, and
generally record many details about your interactions.  More generally,
cookies are used for this purpose even on sites which do not need them
for shopping carts.

As a user of the web, I would prefer to have more control over the kind
of information which servers gather about my browsing habits.  Of
course, since web interactions are voluntary, a server is free to put
whatever restrictions it wishes on clients in return for letting them
access its information.  It can require clients to accept cookies, to
register with their names and addresses, or to FedEx their firstborn
children to the store, for that matter.  Nevertheless to the extent
that I have bargaining clout in these interactions, I will prefer
systems which do not infringe so much upon my privacy.

It is interesting to consider how shopping carts might be done without
cookies and similar technologies which allow servers to get more
information about me than necessary.  I would prefer a system where the
list of things I have chosen to buy is saved on my own computer, in a
format I can clearly see, and without linking my purchase decisions to
other browsing I may have done on that site.

Consider a system where when I click on "buy", a dialog box pops up in
the corner of my screen which is my virtual shopping cart.  It holds a
list of the items I have selected for purchase, with each new item
appended to the list.  When I go to check out, the contents of this
dialog box are uploaded (with my permission) to the site, where payment
arrangements are made.  Since I can see what is being put into the
dialog box and what is being uploaded, I know that I am controlling
exactly what information is being revealed about me.  I don't have to
trust the server to protect my privacy by not recording excessive
information about my browsing.

(Given the difficulties in creating new protocols for this kind of
support, I think a step in the right direction would be to change the
user interface so that cookies are only sent upon user request.  Maybe
you have to shift-click or use some other key modifier to send a cookie.
Then shopping pages could ask you to shift-click the buy button to add
the item to your shopping cart.)

All this is in accord with the general principle that we support here,
of protecting privacy by limiting the collection of infringing data,
rather than trying to pass laws to restrict the dissemination and
sharing of such information.  We support ecash since it allows
transactions without identification, rather than using credit cards but
trying to put legal restrictions on what the CC companies can do with
their transaction data.  Cookies allow many kinds of privacy infringing
data to be collected.  I would prefer to see alternate mechanisms to
allow for the kinds of transactions that cookies are needed for, which
allow users to protect their own privacy.  Are there other uses of
cookies for which alternatives are needed?

Hal
NODE eec21065Re: Cookie alternatives
At 9:07 AM -0700 7/16/96, Hal wrote:
>There has been quite a bit of discussion recently about the "cookies"
>used by Netscape Navigator and their effects on privacy of users.  Here
>is some background and some thoughts on alternatives.

<omitted>

Other uses of cookies include keeping track of pages you've already
seen/done in a sequential information web site, or in a registration
procedure; or validation of registered users and their expiry dates
(perhaps encrypted with protective data elements to prevent cookie sharing)
to avoid having to refer to a data base and slow the interaction down each
new time. I've seen some sites which appear to pass you a cookie after
you're registered, and in future take you directly to the "operational"
first page (such as the front page of a newspaper).

It's also possible to store personal data, such as the size of your largest
order to date or some such, or whether you've bounced any checks/credit
card transactions--so you get different treatment depending on your past
history. The uses are almost as varied as the mind of the server's
operators.

David
NODE e330c7bfRe: Cookie alternatives
Hal wrote:

[Summary of the Cookie Situation, including an interesting proposal
about client-side shopping carts that could replace some uses of
cookies.]
 
> (Given the difficulties in creating new protocols for this kind of
> support, I think a step in the right direction would be to change the
> user interface so that cookies are only sent upon user request.  Maybe
> you have to shift-click or use some other key modifier to send a cookie.
> Then shopping pages could ask you to shift-click the buy button to add
> the item to your shopping cart.)

Neat idea, but it might be hard to get many users to understand the
interface.  I'm surprised no one's mentioned that this week's beta of
Netscape Navigator (3.0b5, available in U.S. or export strength) has a
configuration option that let's you see an alert box before your browser
accepts a cookie.  It's a little hard to find...  (Note to Jeff W. or
other Netscape folks:  maybe this should move from Network: Protocols to
Security: General.  Makes more sense to keep all the "Show an Alert
Before" choices in one place.)

Joe
NODE a1b6ad9eRe: Cookie alternatives
Hal writes:

> However I think in current usage on the web cookies are most commonly
> used basically as nonces, random values whose purpose is to maintain
> continuity in a series of interactions.  When a server gives a cookie
> to a web browser, that browser supplies the cookie on future
> interactions with the server.  The cookie probably does not have any
> specific data about the user or the interaction, but is used only to
> link up the interactions which take place.  It is most probably used as
> an index into a database maintained on the server itself.
[ snip ]
> As a user of the web, I would prefer to have more control over the kind
> of information which servers gather about my browsing habits.
[ snip ]
>                                          Nevertheless to the extent
> that I have bargaining clout in these interactions, I will prefer
> systems which do not infringe so much upon my privacy.
> 
> It is interesting to consider how shopping carts might be done without
> cookies and similar technologies which allow servers to get more
> information about me than necessary.

I think you're exactly right about how cookies are used, but I believe
privacy concerns stemming from cookies have been blown out of proportion
lately.  For the average Joe User running his single-user PC at home,
connected by modem to his local ISP, it makes little difference whether
a site issues a cookie to Joe or not; his IP address already uniquely
distinguishes him.  The site can simply use his IP address as its
database index.  If Joe deletes his cookie file each night before
invoking the browser, the impact of cookies is completely negated.

Now for those of us who access the net from multi-user systems or from
behind a firewall, the cookie uniquely identifies a particular browser
instance -- that is, it makes us equal to Joe.  And that's the reason
cookies were invented in the first place: because IP address and other
information available to the server didn't provide a unique server
database index.

I don't mean there are no privacy implications at all, and there are 
clearly other ways of accomplishing the cookie's function.  My point is
that merely removing cookies doesn't really help Joe's privacy much.
And it's Joe we ought to be concerned about as he represents the typical
user of today as well as the future.


-- Jeff
NODE c3611391Re: Cookie alternatives
-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 17 Jul 1996, Jeff Barber wrote:

> I think you're exactly right about how cookies are used, but I believe
> privacy concerns stemming from cookies have been blown out of proportion
> lately.  For the average Joe User running his single-user PC at home,
> connected by modem to his local ISP, it makes little difference whether
> a site issues a cookie to Joe or not; his IP address already uniquely
> distinguishes him.  The site can simply use his IP address as its
> database index.  If Joe deletes his cookie file each night before
> invoking the browser, the impact of cookies is completely negated.

That's not entirely correct.  Cookies can be used to establish the route a
person used to get from one page to the next.  Of course, this can also be
done by using the "HTTP-REFERER:" header, but some servers might not have that
capability.

- -- Mark

PGP encrypted mail prefered
Key fingerprint = d61734f2800486ae6f79bfeb70f95348
http://www.voicenet.com/~markm/  


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMe7PI7Zc+sv5siulAQHNuAP+Ou5n+NA5Ij+mra6MaDGBajHzX+f7y8nT
9w/GSGcvIMyTVY3tVklH6i1JpF00qcMG1JYFPrzdc//w8a88tK10/Hnj9j62PzUQ
jqgcoPcoEmZMZK46chlaffeZcLMGb1CJvOMzNjJ12UJxuqEUYcLLX9rsSmjlZLzX
4gob7M0DMtM=
=0+TI
-----END PGP SIGNATURE-----