| subject | DoubleClick Opt Out Protocol Failure == Opt In |
|---|---|
| date | May 15, 2000 |
| authors | Gary Ellison <gfe@interhack.net> |
Matt Curtin <cmcurtin@interhack.net> |
|
Doug Monroe <monwel@interhack.net> |
(This article is also available in PostScript. New May 17: see CookiePokey, a demonstration program you can download to see the problem for yourself.)
The DoubleClick implementation of an opt out mechanism is flawed. This defect could result in resumption of tracking a consumers movements on the web.
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.
.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.
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.
id=OPT_OUT, the cookie is effectively ignored. This is an
opt-out cookie.
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.
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.
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.