session-id redux

I was going to talk about the Ego and the Id, but I suppose that can wait 
until later....

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/

Received on Wednesday, 26 July 1995 02:43:22 UTC