RE: Unverifiable Transactions / Cookie draft

BTW I should clarify that I meant that implementers will generally not
feel bound by sections of a wire protocol which specify UI, not that an
entire protocol would be ignored because it provides UI requirements.

	Yaron

> -----Original Message-----
> From:	Yaron Goland 
> Sent:	Tuesday, March 18, 1997 1:17 AM
> To:	http working group
> Subject:	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:43:43 UTC