1) By tracking a user from one host to another to another -- all they
need do is find one occurrence where the user provides identifying
information (say, for a free giveaway, or simply to use a popular
search service). As soon as that occurrence is obtained (along with
the session id), the user's entire click trail for that session is
compromised.
2) By observing patterns of behavior that reduce the possible user
sample to one small enough wherein identity can be obtained.
One of the basic rules of experimentation and user surveys is
that the privacy of the subjects may be compromised if too many
categorical questions are asked within a single survey. In this case,
all accessible server logs along the click trail encompass the survey.
3) By associating an invariant marker with each request, the request
set as a whole can be analyzed for other invariant markers that
distinguish that browser from others. These invariant markers can
then be used to connect the identity of more than one session even
when the session ID changes.
>>>******* II. The business-card authentication scheme
>>
>>I don't like this proposal, because it combines two orthogonal
>>concepts.
>>
>> 1) A way for users to keep a standard business-card stored in
>> the client, so they don't have to re-type it by hand.
>>
>> 2) authentication, which should never include unnecessary information
>
>I'm really interested in part 2), and only incidentally happy that it
>may solve part 1). Which part of the business card is unnecessary?
Almost all of it. If you have authentication data, you have already
had a chance to ask for and receive the user's business card data.
The only thing needed for the authentication is the credentials.
> My
>proposal is explicitly aimed at information providers who want to
>operate under a policy of "give me your card and I'll show you my
>stuff" unobtrusively. Are you telling them: "go away -- you can't do
>that"?
No, I'm saying that they can't ask for it on every request. That
would be an intolerable waste of bandwidth.
>>Defining a standard business-card format for browsers is a good idea.
>>However, I would implement it by also defining standard FORM input
>>names, such that when presenting an HTML form for the first time,
>>the browser could pre-fill the data fields for field names that
>>match its predefined business-card field names.
>
>The server could take the business card auth data and fill in the
>form fields in advance. So my proposal covers your needs. Your
>proposal _doesn't_ allow for the no-user-interaction case, which
>I think is critical.
The only thing critical about it is that it not be allowed unless
the user first approves it, in which case it is no more of a
"no-user-interaction case" than an automatically filled-out form.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
(fielding@w3.org) (fielding@ics.uci.edu)