Re: Unverifiable Transactions / Cookie draft

On Mar 14,  6:39pm, Jaye, Dan wrote:
> Subject: RE: Unverifiable Transactions / Cookie draft
> It is clear that the current cookie standard provides the potential of
> abuse and
> could be used to violate an individual's right to privacy.
> However,  the number of web sites and applications that make use of
> "unverifiable transactions" for legitimate, non-privacy invading uses is
> significant and growing.

I would be interested in seeing how you define non-privacy
invading uses.  I ask this because I suspect that there may
be a fundamentally different set of assumptions in play
among different parties to this discussion.  Making those
assumptions explicit may help us make progress.

> EVERY Fortune 500 customer that we have spoken to has multiple domains.
> How do they measure the effectiveness of this channel if they cannot
> aggregate ANONYMOUS log data into visits and visitors?

As I said to Martijn Koster recently, it is important to the users
to understand who may have access to the information they provide
(a clicktrail being part of that information).  A fortune 500
company which maintains seperate subdomains under a
well-known domain can deal with the spec easily; a conglomerate
which has different domains for different companies or
products may have more trouble.  That trouble mirrors, however,
the difficulty a user would have in understanding the relationship
between the sites.  If Procter and Gamble chooses to register
a domain for each product,  how can the user know of their
relationship and the likelihood that the data on the domains
will be aggregated?  As it stood when this spec was written, the
domain was the only clearly identifiable piece of the puzzle that
we knew was in UAs and being displayed to users; I have seen
various other things since, but they are neither standard nor
ubiquitous.   The domain remains ubiquitous and easily verified.

> If possible, we should modify the standards to prevent violations of
> privacy.  At the same time, let's not impose restrictions that will
> obstruct development.  In the end, if we want the media to grow and
> provide lots of free or low-cost content, commercial organizations are
> going to pay a significant portion of the costs.  They will only do this
> if they see that it is an effective place to spend their money.
> Measurement is important.  Effective targeting of information, content,
> and yes, advertising is important.  There are at least a hundred small
> to medium web content sites who depend on advertising networks to
> generate revenue and traffic.

You may have to go beyond your current implementation to make
this work, but I believe it is possible to continue to use advertising
networks under the current spec.  It is simply difficult to do so
without the user knowing that the advertising network has become
involved.  That is the intention of the current design.  There are
still ways around it (granting the advertising network's host a record
in the domain of the content site's domain, for example), but these
have other consequences for reponsibility that accomplish much the
same goals.

> I would like to suggest that we provide a mechanism, similar to a
> Certificate Authority, that would allow for a "unverifiable transaction"
> to be verified against a list of valid site certificates.  These
> certificates could be assigned levels, perhaps using the E-TRUST
> trustmarks, and users could select their privacy level according to
> those trustmarks.  The default behavior could be for the cookies to be
> rejected from all non-verifiable transactions except for ETrust Level 3
> (i.e., anonymous) site certificates.

The deployment of such a mechanism presents problems far
beyond those of the current spec.  It also completely ignores
the problem of legacy browsers without this capability.
If we are going to write all current and legacy user agents
out of the problem statement, we have of lot of other possible

			Ted Hardie

NB: I am not in this message speaking for NASA.


Received on Friday, 14 March 1997 16:10:17 UTC