- From: Brian Behlendorf <brian@organic.com>
- Date: Tue, 18 Mar 1997 00:19:22 -0800 (PST)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: http working group <http-wg@cuckoo.hpl.hp.com>
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 00:18:39 UTC