and I have to say, he has a point: in one world view, we should all hound
DoubleClick network *users*, not DoubleClick. I should reject HotWired, not
them.
Still, the UI power of the "url you typed in" is strong enough to ask "hmm...
don't automatically send cookies to anyone *not* whom I specified in my url"
Comments?
RK
---------------------------------------------------------------------------
Resent-Date: Thu, 13 Mar 1997 20:08:14 -0500 (EST)
From: dmerriman@doubleclick.net (Dwight Merriman)
To: <http-wg@cuckoo.hpl.hp.com>
Subject: Unverifiable Transactions / Cookie draft
Date: Thu, 13 Mar 1997 20:09:29 -0500
X-Msmail-Priority: Normal
X-Priority: 3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"7McYo1.0.jh3.zJAAp"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2640
X-Loop: http-wg@cuckoo.hpl.hp.com
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com
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