(This article is also available in PostScript. New May 17: see CookiePokey, a demonstration program you can download to see the problem for yourself.)

1. Summary

The DoubleClick implementation of an opt out mechanism is flawed. This defect could result in resumption of tracking a consumers movements on the web.

2. Overview

Consumer privacy concerns recently forced DoubleClick into supplying consumers with a mechanism to opt out of its tracking machinery. This advisory describes an implementation flaw in DoubleClick's handling of cookies [1,3] sent from the browser. This defect could result in the consumer being tracked without any knowledge of this activity, contrary to the consumers explicit action of opting out. While testing Netscape 6 Preview Release 1 we discovered aberrant behavior in the DoubleClick opt out mechanism. Following what the DoubleClick server claimed to be a successful opt out, we noticed that the next fetch from a tracked resource would initiate the process of injecting a unique tracking cookie into the browser even though a truly successful opt out should have resulted in an id=OPT_OUT cookie being returned to the server instead.

3. Tracking Protocol

In order to describe this it is useful to first explain the basics of how the DoubleClick AdServer initiates tracking the consumer.

• If the AdServer in the tracking domain (e.g., .doubleclick.net) does not receive a cookie in the request header then a cookie similar to the following is presented to the browser:

          Set-cookie: id=A; path=/; domain=.doubleclick.net; expires=...
  

  The value of ``A'' indicates that the tracking process is being initiated. We refer to this as the priming cookie.
• If the AdServer in the tracking domain receives a priming cookie (i.e., Cookie: id=A), then this cookie is updated to a unique value. For example:

          Set-cookie: id=8abc4321; path=/; domain=.doubleclick.net; expires=...
  

  We refer to this as the tracking cookie.

• If the AdServer in the tracking domain receives a cookie with id=OPT_OUT, the cookie is effectively ignored. This is an opt-out cookie.
• If the AdServer in the tracking domain receives a tracking cookie then DoubleClick correlates the referring page and the target image into the consumer profile keyed off of the unique id.

4. Protocol Defect

The problem we discovered is that the DoubleClick AdServer which initiates the tracking violates RFC 2616 Section 4.2 [2] concerning field name case insensitivity. Specifically, the server fails to recognize the cookie in the request header if the field name is not literally sent in the form Cookie. For example if the field name is all uppercase (COOKIE) DoubleClick does not recognize the cookie.

Netscape 6 Preview Release 1 sends the cookie field name in lowercase (cookie). This gets ignored by the DoubleClick AdServer. This puts Netscape 6 PR1 in a constant state of priming. Therefore the browser will never really succeed to opt out. The user is unlikely to be aware of this since during the opt out procedure DoubleClick reports the "Opt-out completed successfully." The fact that DoubleClick does not verify the results of the opt out and blindly reports success is irresponsible.

5. Privacy Threats

A privacy breach might occur if DoubleClick updates their server software to be RFC 2616 compliant. DoubleClick will then recognize the lowercase cookie field name. A consumer who deliberately went through the opt out process could, without any actions on his part, once again be tracked.

One such scenario is where a consumer went through the opt out process using Communicator 4.7x. At some point he updates to Netscape 6. The next time the consumer visits a site which used DoubleClick for ad serving, the opt out cookie is replaced by a priming cookie.

Another scenario is that if someone temporarily tries Netscape 6 the DoubleClick priming cookie will be put in the cookie store in place of the opt out cookie. If the user goes back to a previous version of Netscape, the user will have been opted back into the system without knowing it.

6. Remedies

DoubleClick must correct their handling of HTTP header field names to be compliant with RFC 2616. The longer this defect persists the greater chance of infringing upon the privacy of an unwitting consumer.

This problem potentially has greater implications than just DoubleClick's own banner ad/tracking network. Because DoubleClick also sells banner ad/tracking servers (under the brand name ``DoubleClick DART''), it is possible that some other sites that use DART will suffer from the cookie problems described above. We tested one such DART server and found that it did not exhibit the stated cookie problem. However, it is difficult to determine precisely what these AdServers are doing so it isn't practical for us to find and to test every version of the DoubleClick/DART AdServer for this problem.

This defect puts Netscape 6 in a very precarious position. However, the software is in its earliest release stage and it is unlikely that it is in any sort of general use. Therefore Netscape developers should, purely as a defensive precaution, change the browser to format the cookie field name the same as Communicator. Specifically, Netscape 6 should always send the cookie field name as Cookie. Note that this is a defensive measure and that the current behavior of Netscape 6 is compliant with this aspect of RFC 2616.

It is worth noting that Netscape 6 is just one of many browsers consumers use today. We do not know if there are other browsers which may be susceptible to this defect. We found that Netscape Communicator, Microsoft Internet Explorer, and Opera Browser are not susceptible to this problem.

Bibliography

1

Netscape Communications Corporation. 
Persistent client state HTTP cookies. 
[online] http://www.netscape.com/newsref/std/cookie_spec.html.

2

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. 
Hypertext transfer protocol - HTTP/1.1. 
RFC 2616, June 1999. 
[online] http://www.ietf.org/rfc/rfc2616.txt.

3

D. Kristol and L. Montulli. 
HTTP state management mechanism. 
RFC 2109, February 1997. 
[online] http://www.ietf.org/rfc/rfc2109.txt.