- From: Dwight Merriman <dmerriman@doubleclick.net>
- Date: Thu, 13 Mar 1997 20:09:29 -0500
- To: http-wg@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
Received on Thursday, 13 March 1997 17:09:50 UTC