In fact, after reviewing all the messages posted about sessions and
cookies and privacy and such, it's become apparent that there is *no*
solution that makes everyone happy. Not that pleasing everyone is
necessarily a goal of the WWW development efforts, but there are very
strong arguments on all sides that must be taken into consideration.
This is really the last time we should go into this as a group - either
let's implement (or make a committment to implement) something, or decide
once and for all to chuck it and leave it to nonstandard practices.
Here's my attempt at a FAP (like an FAQ, but "Frequently Argued Points")
for this issue. I apologize if I let biases cloud the sides, I'm only
human.
1) Session-IDs are marketing fluff that provide no benefit to the user,
weight down the request, and are a threat to privacy.
Pro: Marketing fluff has no place in the world of Internet protocols.
Con: "Fluff" to you is real money to others, and real desires to get
an accurate count of visitors. If a web-protocol-friendly
mechanism isn't implemented, content creators will either
implement it themselves using proxy-unfriendly mechanisms (like
Pathfinder's and IPRO's session-ID's-in-URL's, or HotWired's
password protection) or leave the web and put their content on a
service which does provide them this information. This is not
"blackmail", this is the real deal.
Pro: "Clickstreams" might not be able to violate privacy by themselves,
but when combined with other factors in the web site transactions,
or when combined with another site's logs, can result in compromises.
Con: In extreme cases, this is true. However, SID's *by*themselves*
can not reveal *identity*, since (by most proposals) they are not
persistant across sessions, and are thus pretty useless to use as a
key in a user profile database. It's when a person willingly gives a
site their email address or other personal information that it could be
troublesome. And you know what folks? That's not something any
technology is going to stop. When you give personal information,
you are *always* trusting the remote site to not resell it or do
nasty things with it. This is true today, without session-IDs.
It will be true tomorrow with or without session-IDs.
Pro: Why would a browser author burden the request with a header that
provides the user with no benefit?
Con: No argument there.
2) Session-IDs and Cookies should be folded into the same mechanism,
since there's already a Cookie implementation in Netscape.
Pro: Cookies can be used to store session-ID information - better yet,
having the server give the SID to the client reduces the need for
every request to every site to have a SID.
Con: Cookies should not be used because COOKIE-ACCESSED CONTENT IS NOT
CACHEABLE. The cookie must be part of the key a proxy cache uses to
find cache hits, or else invalid responses are almost guaranteed for
content whose form depends on information in the cookie (such as the
shopping cart example).
3) Cookies can be used to generate user profiles and store them on the
client side, which is more scalable and network-friendly than large
databases on the server-side.
Pro: Many sites (HotWired, for example) allow you to create profiles
on their site to customize your interface to their data, remember
what files you have seen, etc. This is very costly on the server
side - user profiles sent with each request would make this more
scalable.
Con: It's perhaps more scalable in that sense, but breaking caching is
a big price to pay, and in the long run might outweigh the benefits.
Furthermore, data like that (and like items in a shopping cart)
should be handled as first-class data - as an opaque string the client
has no hope of *managing* that information outside of the context of the
server itself.
----------------------------------------------------------------------------
Anyways, at this point I'm ready to throw in the towel and just go back
and tell the people screaming for this kind of functionality and go
"look, without intrusive measures like password protection or broken
mechanisms like session-ID-URL-munging or heuristics which work one day
and not the next, I just can't get that info for you with any reasonable
accuracy." And then we'll see which path they choose.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/