Re: (USERTRACKING) Draft text

While I like Koen's draft I think that there is another point to bring up here, 
the "don't build systems that depend on it" point. If clients start producing 
exotic accept headers as a means of supporting bogus demographic schemes we have 
a clear violation of the "separation of concerns" principle. It will be 
difficult enough to develop the content negotiation scheme. It will be much 
harder todo this if changing the accept header mechanism will break demographic 

There are several hacks which have been agressively marketed as solutions to the 
demographics problem which will prevent usefull work by proxies. Chief culprits 
include systems based on cookies, adding user identifiers to the URI and so on.

The point about these systems is that they are fragile and will break as caching 
is more widely deployed. State Info is a mechanism for improving client/server 
interaction. They are sub-optimal as session identifiers.

I hope that we can address these issues directly in 1.2 and to that end I have 3 
W3C technical drafts which describe an explicit mechanism for supporting session 

I don't have a problem with a site tracking the browsing patterns of its users 
within its site. After all persistent connections would reveal such information 
if they were long enough. The real privacy issues occur when going across sites.

We can't get into the discussion of the privacy issue at this time but when we 
do I believe that there is much more of a middle ground between the content 
providers and privacy advocates than people may believe. The main impediment to 
a working solution is likely to be the one-man-and-his-perl-script companies 
with a clueless hack they want to preserve until they go for a ludicrously 
overpriced IPO.


Received on Sunday, 14 April 1996 17:49:50 UTC