RE: Unverifiable Transactions / Cookie draft

There is an interesting assumption being made that protocols have the
right to dictate user interface to software makers. Am I the only one
who finds this development disturbing? Not because I am overly concerned
about protocols dictating UI, the protocol will be roundly ignored and
compliance will be coincidental at best, but rather that by dictating
requirements in areas clearly beyond the scope of a wire protocol, the
authority of the protocol group is lessened.

		Yaron

> -----Original Message-----
> From:	Brian Behlendorf [SMTP:brian@organic.com]
> Sent:	Tuesday, March 18, 1997 12:19 AM
> To:	David W. Morris
> Cc:	http working group
> Subject:	Re: Unverifiable Transactions / Cookie draft
> 
> On Mon, 17 Mar 1997, David W. Morris wrote:
> > In the single very limited involvement I had with advertising, the
> revenue
> > was associated with the click thru on the banner ad, not the bannner
> ad.
> > That would, as I understand the DoubleCLick model would be a click
> to 
> > the DoubleClick site from which a set-cookie wouldn't be considered
> an
> > unverifiable transaction.
> > 
> > If I were advertising, knowing when a user actually asked to see
> more of
> > my message would have tremendous value compared with having my ad
> > where they might have seen it.
> 
> For some models this makes sense - I even know ad models where content
> sites
> are compensated only as a percentage of online sales generated!  But
> there is a
> compelling argument that compensation models based on clickthroughs or
> more are
> flawed because it encourages the content developer to focus
> exclusively on
> pushing people through the ad, rather than actually providing useful
> content.
> I'm sure many content sites would refuse to partake in this.  
> 
> > The bottom line is that WWW advertising is based on a business model
> which
> > didn't even exist a couple of years ago. It is based on leveraging
> > technology which is new and evolving. I am confident that it will
> evolve
> > in response to improvements to the technology..
> 
> The business model of sponsored content has been around forever.  So
> have these
> privacy issues - how do you know that donation you made to the Sierra
> Club last
> year didn't lead to that Democratic National Committee soliciation you
> got
> yesterday?  Looking to technology for a solution to the privacy
> problems is
> as misguided as blaming technology for causing them.  
> 
> I have come to believe over the last year that this is not a problem
> for which
> technology can provide a complete solution.  Intent is everything -
> and even
> browsers that obey this spec and folks who don't use cookies are still
> ripe for
> abuse by parties with intent.  Fortunately abuse is not a requirement
> to make a
> profit in this model - doubleclick doesn't have to be able to do a
> credit check
> on you or know your email address to do what they do.
> 
> Two companies which have similar privacy issues - FireFly and
> Narrowline -
> backed up their claims of consumer protection by paying Coopers &
> Lybrand
> (one of the Big 6 accounting firms) to perform a personal information
> security
> audit.  Perhaps DoubleClick should do the same.
> 
> I think in the long run a solution like one suggested by
> "Jaye, Dan" <DJaye@engagetech.com> in 
> <c=US%a=_%p=CMG%l=ANDEXC01-970314233918Z-22988@wilexc01.cmgi.com>
> is the one which most closely semantically matches what's going on
> here.  The
> issue is one of trust - and trust brokered by a certificate authority
> (be it
> Coopers&Lybrand, ETrust, Better Business Bureau, an organization of
> the EC,
> whatever) makes sense.
> 
> But in the short term... let's not kid ourselves.  This will not
> significantly
> increase the privacy of users on the web.  This is not similar to the
> "opt-in/opt-out" debate amongst direct marketers - of which I am
> firmly in the
> land of "opt-in".  This is a small hurdle - even just using the IP
> number and
> User-Agent as the key to the profiling database would be sufficient
> for many
> uses, and slightly more elaborate schemes can be used to make it much
> more
> precise. That it is a small hurdle to work around is *not* a
> justification for
> putting it in the spec. 
> 
> I am somewhat loath to enter this conversation as I was periphery to
> the
> discussions early on which led to this, and I now have a slightly
> different
> opinion, and we know this RFC has been in development for a long time.
> The
> fact that my opinion can be different today suggests it may be too
> early to try
> and coerce the protocols into implementing policy... just a thought.
> 
> I think Dwight's proposal might be a little overcomplicated -
> something like
> the below might address most concerns out there?
> 
> 1) By default, user agents are configured to prompt for confirmation
> on 
>      receipt of all cookies - unlike today's defaults which is to
> accept
>      all cookies.
> 2) Upon receipt of a cookie, UI must have the options:
>      Accept this cookie
>      Do not accept this cookie
>      Accept all cookies from this domain
>      Never accept cookies from this domain
> 3) UI allows for some indication of pages with content inlined from
> other
>      servers.  Perhaps specially flag cookie requests for inlined
> content too.
> 4) Remove the restriction on unverified transactions.
> 
> Show me this leads to /less/ privacy, particularly in combination with
> all the
> other existing provisions of the current spec.
> 
> I really wish this was a more clear-cut situation - that cookies
> really did
> make the difference between being "database-able" or not.  It doesn't.
> 
> 
> 	Brian
> 
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=--
> brian@organic.com  www.apache.org  hyperreal.com
> http://www.organic.com/JOBS
>

Received on Tuesday, 18 March 1997 01:18:54 UTC