RE: Unverifiable Transactions / Cookie draft

I would also point out that besides denying smaller sites revenue,
preventing "unverifiable transactions" only puts a very small bump in
the road of collecting user data. What companies like doubleclick will
end up doing is providing CGI scripts to site providers that will
automatically thunk calls through to the doubleclick.com site. Of course
smaller providers will now have to absorb what amounts to double the
cost per transaction due to their servers have to act as a middle man
for advertising.

User Privacy - 0
Small Web Sites - 0

Exactly who wins here?

		Yaron

> -----Original Message-----
> From:	dmerriman@doubleclick.net [SMTP:dmerriman@doubleclick.net]
> Sent:	Thursday, March 13, 1997 5:09 PM
> To:	http-wg@cuckoo.hpl.hp.com
> Subject:	Unverifiable Transactions / Cookie draft
> 
> I would like to propose modifications to section 4.3.5 of the cookie
> spec. 
> Disabling stateful sessions for unverifiable transactions by default
> is
> basically equivalent to not allowing them at all, because 99% of the
> population will see no reason to change the default.
> 
> In its current form, this section of the spec has potentially huge
> ramifications for Internet advertising networks and remote ad delivery
> services.  Ad networks and remote delivery services use cookies for at
> least three functions: 1) measuring reach, 2) frequency stop
> targeting, and
> 3) user interest targeting.  If the new RFC is adopted, these
> capabilities
> will be lost for networks, but still available and effective for the
> largest individual sites which accept advertising.  I am unsure if ad
> networks, which provide an important economic model for smaller web
> sites,
> will be able to compete effectively in the long term if this happens.
> 
> Additionally, is the differentiation between verifiable and
> non-verifiable
> transactions really necessary?  Verifiable transactions seem to assume
> a
> "trust" between the user and the web site.  However, no inline image
> could
> ever go on a web site without the web site's permission.  If the site
> is
> really trustworthy, it will only affiliate itself with reputable third
> parties.  If it's not trustworthy, the user's trust was misplaced from
> the
> start!
> 
> I do think that privacy is a concern and an important issue.  For
> example,
> I think section 7.1 of the spec is prudent.
> 
> I will not propose any specific language yet, because I am sure there
> are
> many differing opinions at this point.  Some alternatives:
> 
> 1. The non-verifiable rule should be available to the user as an
> option,
> but is disabled by default.
> 2. When an unverifiable session starts and a cookie assignment occurs,
> a
> notification is displayed on the browser's status bar.  The user can
> then,
> through a UI facility, disable the session ex post facto, and the
> browser
> could remember that sessions for the particular unverifiable domain
> should
> automatically be disabled thereafter.
> 3. When an unverifiable session starts and the initial cookie
> assignment
> occurs, a notification is displayed on the browser's status bar.  If
> the
> third party affiliate is "unsavory", the user can hold the primary
> site
> visited responsible and repudiate; for example, the user could refuse
> to
> use the main site in the future.
> 4. Explain the risk in the spec, and let the browser designer choose
> an
> appropriate solution for his or her customers.  In my opinion, things
> which
> are not interoperability issues and can be deferred to the software
> designer should be.
> 
> Comments?
> 
> Dwight Merriman
> DoubleClick

Received on Thursday, 13 March 1997 19:03:36 UTC