RE: Unverifiable Transactions / Cookie draft

>----------
>From: 	Ted Hardie[SMTP:hardie@thornhill.arc.nasa.gov]
>Sent: 	Friday, March 14, 1997 7:13 PM
>To: 	Jaye, Dan; 'Yaron Goland'; 'hedlund@best.com ';
>http-wg@cuckoo.hpl.hp.com
>Cc: 	'dmerriman@doubleclick.net'
>Subject: 	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.

Examples of: non-privacy invading uses:
   Content and service aggregators using redirection to allow a visitor
to use many different services under one umbrella where cookies are used
for maintaining state.  Although it is sometimes possible for all of
these to be under one domain, it sometimes is not possible or is
impractical. 

ETRUST and some extremely ardent privacy advocates have indicated that
if information is anonymous (i.e., it can only be aggregated or cannot
be tied back to an individual's identity) is is not "personal"
information.  My contention is that most of the use of unverifiable
transactions is "anonymous" and inherently private.  The potential is
there for abuse however and I would like to see a solution that closes
the loophole without throwing the baby out with the bathwater.
>
>> 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.

The key point is that the user must be informed.  I believe that is why
DoubleClick has suggested that the user be notified that a cookie is
being set and given the opportunity to reject, accept, or specify to
accept all from this domain in the future.  This is actually more
informative than transparently rejecting all cookies without notifying
the user at all.  Once again, I think more information needs to be made
available to the user than just a domain name of the issuer, like a
third party rating system, certificate, etc.  

BTW, we are not an advertising network or a user of one.


>> RECOMMENDATION:
>> 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
>solutions.

Doesn't the current spec ignore current and legacy browsers as well?
>
>		regards,
>			Ted Hardie
>			NASA NIC
>
>NB: I am not in this message speaking for NASA.
>
>-- 
>
>

Received on Friday, 14 March 1997 16:35:50 UTC