RE: Unverifiable Transactions / Cookie draft
Yaron Goland (yarong@microsoft.com)
Tue, 18 Mar 1997 01:41:58 -0800
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
>