From: Derek Robinson (firstname.lastname@example.org)
Date: Sun Oct 22 2000 - 03:42:26 PDT
When Cookies Go Bad
October 16, 2000
By Robert Moskowitz
My neighbor is a big catalog shopper; almost all the
family's clothes arrive in the mail. Recently, two of
the merchants she frequents announced plans to drop
their catalogs and offer only Internet-based
purchasing. Understand, my neighbor does not love the
Web. She particularly dislikes all the security horror
stories I often have to tell. And after an hour of
clothing searches using my high-speed DSL line, she
ditched online commerce and returned to her trusty
A number of factors contributed to her very unpleasant
shopping experience. Personally, I haven't seen a
clothing Web site that can compete with a
well-designed catalog for speed and convenience. Even
20 open Web windows cannot compare with a catalog
that's been cut open at the binding and spread out on
a bed. But even more important, if you selectively
block cookies (as I do), Web performance tanks.
HTTP cookies have received a well-deserved bad rap.
Too many Web entrepreneurs have abused them
significantly. Unfortunately, the Web shopping-cart
model is dependent on a device so misused that we
simply cannot trust it. Cookies were added to Web
servers and browsers so clients, rather than servers,
would keep information for a "site visit"; in a
dial-up world filled with crashing desktops, this made
sense. Unfortunately, this has enabled the server to
collect information on the Web user and store or sell
it or just hand it out to anyone who gets past the
all-too-frequently inadequate server security.
Blocking cookies can cripple your browsing experience.
Many Web sites just hang if you're blocking cookies.
Other sites wait for time-outs--often more than a
minute long each--every time an attempt is made to
send you the cookie. And browsers don't help much with
managing cookies. For the most part, they have a
take-it-or-leave-it attitude. Some Unix users handle
this by putting their cookie files on write-protected
file systems. The result? Upon exiting the browser,
the cookies are lost, so the Web site has them only
for that session. This solution is almost foolproof,
though there's still a chance for data collection.
Regrettably, this is not an option available to most
Microsoft Windows users. Thankfully, there are
cookie-aid plug-ins for your browser. The plug-ins
selectively block the most onerous Web sites, leaving
you to cast your fate with Web sites you have to
Blocking cookies from selected URLs lets Web users
only express their distrust of various Web sites, and,
worse yet, the users end up with degraded performance
to boot. It does nothing to address the distrust
that's spread across the Web--the distrust that stops
many people from using online commerce. Given the
current technology, there's probably no way to change
this situation. It still makes sense for the client to
maintain state for Web interaction, particularly for
online shopping. Any nonsigned mechanism used in place
of the current cookie method can be corrupted as
easily as cookies. The only prospect on the horizon is
the use of digital signatures.
Digital signatures in and of themselves solve nothing.
John Q. Thief could still sign anything he wants and
go on selling your personal information. The approach
would require a CA (certificate authority) to enforce
certain privacy rules for all Web sites. The public
would then accept as trustworthy a cookie signed by a
certificate that was issued by this CA. The CA could
maintain a group of Web investigators who would
regularly check the practices of its subscribers. The
signing operation is computationally expensive, but
servers can lessen the impact of this both by
presigning generic site cookies and by using signing
hardware. Online commerce is inundated by bad designs
and suspicion. We can add trust to the equation
through the practice of certification and validation
coupled with digital-signature technology.
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
This archive was generated by hypermail 2b29 : Sun Oct 22 2000 - 03:46:54 PDT