Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

On Sat, 15 Jun 1996, Koen Holtman wrote:

> Benjamin Franz:
> >
> >I hate to rain on your parade - but you can't stop sharing of cookie info
> >across cooperating domains. At all.
> 
> I am fully aware that there are numerous tricks which cooperating
> domains can use to share session info.  I did not claim that the
> restriction to single-domain cookies in netscape cookies and in the
> state management draft is a good thing because it prevents all
> sharing.  
> 
> The restriction is a good thing because without it, there would be
> built-in cross-server tracking support in each browser, which is
> something users do not want.  This is not about providing bullet-proof
> privacy protection, this is about the public's perception of whether
> their browser comes with standard built-in user tracking support.

I think you are making a bad mistake. By enhancing the *perception* that
"their browser comes with standard built-in user tracking support." is not
a true statement - you set people up for behaving as it it *weren't* true. 
But actually - it *is* true.. It is worse to *mislead* people as to the
level of privacy protection they can expect from browsers than to let them
know up front that they *can* be tracked across servers. 

> 
> [...]
> >Basically - you can achieve nothing except making me work *slightly*
> >harder to share information with a cooperating domain.
> 
> You will have to work more than just slightly harder.  And after you
> deploy such a system, it will inevitably be discovered, and it will
> result in bad publicity not just for you but for the entire web.  But
> at least this bad publicity won't involve stories about browser
> vendors and the IETF being on your side in the battle over privacy.

Sigh. I write sites for a living. Believe me - it *is* only slightly
harder to use any of the methods I mentioned or others that can be thought
of by any competent programmer than it is to use cookies in the first
place. At least one of the methods I mentioned is *completely*
indetectable by the browser unless I slip up and give them information
that could only have been derived from the other site. There are tons of
other covert channels such as using inline images cross-linked between
sites via a redirect that are unlikely to be noticed. Reading the HTML
won't give them away since the final location is determined 'on the fly'.
You would probably only detect the cross-site inline link if you were to
try to load the inline image out of context.

It will result in much *worse* publicity for the web when it is discovered
that this can be done secretly in ways that are *completely* indetectable
by the user. And by refusing to put public methods for sharing information
into the protocal, you actually enhance the probability of site authors in
fact employing such indetectable methods. And they may not even be
thinking 'covert' but simply 'pretty' or even better - requiring no
special support by the browsers. Authors like things that are transparent
to the users for *esthetic* reasons and things that don't require special
facilities from the browsers because they like to reach the largest
possible audience. Multi-site cookies would be user transparent. So would
covert channels. And the covert channels assume less about the browser
software than cookies do.

> Multi-domain cookies would be a browser vendor public relations
> disaster waiting to happen.  You can't expect browser vendors to
> standardize on the state management draft if multi-domain cookies are
> added.

Maybe. I am sceptical that enough people even understand the issue deeply
enough to make it a public relations distaster. This isn't in conflict
with my 'worse publicity' paragraph because while people are in general
unlikely to full appreciate the dangers of public information sharing -
they certainly dislike *secret* sharing of information on principle. Tends
to push their paranoia button.

-- 
Benjamin Franz

Received on Saturday, 15 June 1996 08:07:06 UTC