Verizon Wireless injects a unique header into customer web traffic. When the practice came to light last year, it was widely panned. Numerous security researchers pointed out that this “supercookie” could trivially be used to track mobile subscribers, even if they had opted out, cleared their cookies, or entered private browsing mode.1 But Verizon persisted, emphasizing that its own business model did not use the header for tracking.
Out of curiosity, I went looking for a company that was taking advantage of the Verizon header to track consumers. I found one—Turn, a headline Verizon advertising partner. They’re “bringing sexy back to measurement.”
There are, roughly, two ways that a website could track a user with the Verizon header. The sneaky way is to surreptitiously correlate values on the backend. Detecting that is quite tricky. (Though there’s been impressive research progress in the past couple years.)
brazen lazy transparent way is to bolt the header onto existing cookie tracking. If a user’s ID cookie is missing, simply reconstruct it from their Verizon header. In the rich jargon of online privacy, these are dubbed “zombie cookies.” They rise from the grave.2
In late December, I went Verizon zombie hunting. I began by developing a basic web crawler with PhantomJS. It visited popular websites, clearing cookies after each page. On the first run, it spoofed a Verizon advertising header.3 On the second run, it used a vanilla configuration. A post-processing script then scanned for lengthy cookie values that recurred only in the Verizon crawl.
uid cookie on
turn.com immediately appeared suspicious. The same unique value was restored on over a hundred pages.
Confirmation was easy. A request to certain Turn resources, sans Verizon header, simply drops a
$ curl -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=2415230717135370700; Domain=.turn.com; ...
Each cookieless request results in a new ID.
$ curl -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=4425321986559530189; Domain=.turn.com; ...
So far, no surprises. When requests include a Verizon header, though, the subsequent response behavior is different.
$ curl -H "X-UIDH: OTgxNT..." -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=4012847891611109688; Domain=.turn.com;... $ curl -H "X-UIDH: OTgxNT..." -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=2539356028667362074; Domain=.turn.com;... Set-Cookie: uid=4012847891611109688; Domain=.turn.com;...
As before, there’s a new ID. But a second
Set-Cookie header appears; it trumps the first header and restores the old ID.4
Turn does not seem to validate the Verizon header. Sending a totally bogus value, for instance, still results in a zombie cookie.
$ curl -H "X-UIDH: totallybogus" -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=8323135681340417635; Domain=.turn.com;... $ curl -H "X-UIDH: totallybogus" -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=3259412905334729433; Domain=.turn.com;... Set-Cookie: uid=8323135681340417635; Domain=.turn.com;...
The respawning logic also appears to be naïve. It seems to simply replay the latest ID value associated with the header.5
$ curl -H "X-UIDH: fake" -H "Cookie: uid=123456789" -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=123456789; Domain=.turn.com;... $ curl -H "X-UIDH: fake" -D - "http://ad.turn.com/server/ads.js" ... Set-Cookie: uid=3647115064319153191; Domain=.turn.com;... Set-Cookie: uid=123456789; Domain=.turn.com;...
I tried moving between IP addresses and User-Agents, in case those factored into Turn’s behavior. The zombie cookie remained.
Because of implementation quirks, the zombie cookie might not always stick.6 But the basic design and effect are straightforward.
The privacy impact does not, unfortunately, end with Turn. Over the past five years, the online advertising market has shifted from monolithic advertising networks to fragmented advertising exchanges. A technical consequence is that advertising firms routinely swap ID values. In industry lingo, it’s call “cookie syncing.”
In my crawl, Turn’s zombie cookie was sent to or from over thirty other businesses.7 They included Google, Facebook, Yahoo, Twitter, Walmart, and WebMD. How those firms use Turn’s ID, I can’t say—it’s entirely possible that some unknowingly tracked users with a zombie value. They certainly possessed sufficient information.8 It’s especially likely for businesses that dropped their own tracking cookie with Turn’s ID.9
The privacy impact also goes beyond individual mobile browsers. If a Verizon customer tethered with their phone, their notebook could get stuck with the zombie value. (The ultimate in cross-device advertising!) And the zombie value could spread between cookie stores on a device, including between the web browser and individual apps. (The ultimate in inter-app advertising!)
In sum, there are widespread collateral consequences from Turn’s zombie cookie.
If a Verizon Wireless subscriber objects to Turn’s tracking, what’s their recourse? Well, both Verizon and Turn offer opt outs. You might think those would be effective. You would think wrong.
Verizon provides two separate privacy choices related to the header: “Relevant Mobile Advertising” and “Verizon Selects.” Steve Englehardt has compiled a convenient comparison of these programs.10
The accounts that I tested had both Relevant Mobile Advertising and Verizon Selects disabled, as well as every other controllable form of Verizon information sharing. Turn’s zombie cookies kept coming back.
These preferences don’t actually stop Verizon from injecting a unique advertising header. They merely stop Verizon from passing along additional customer information. If a business is using the header as a tracking identifier—like Turn is—the Verizon preferences are entirely ineffective.
Turn’s privacy option also fails to prevent its zombie cookies. I checked by opting out on Turn’s website,11 a process that drops an
optOut=1 cookie and expires ID cookies.12
I then cleared browser state and visited websites where Turn’s zombie cookie had previously respawned. The
uid tracking cookie came back.
What’s more, the
optOut cookie—which is supposed to prevent behavioral ad targeting—did not get resurrected. According to Turn’s own status check, the user’s preference against behavioral advertising was gone.
Status checks for advertising self-regulatory programs confirmed that Turn would use its tracking data for behavioral advertising.13
So, what’s a Verizon subscriber to do? Ad blocking would be effective, but it isn’t supported by the stock Android or iOS browsers. Using a VPN or other secure proxy would work, though that’s quite cumbersome. For an ordinary user, there simply is no defense.
Are These Zombies Legal?
Commercial supercookies, fingerprinting, and zombie cookies are tolerated (if not permitted) under current United States law.17 Any associated consumer deception, however, is a violation of the Federal Trade Commission Act and parallel state statutes.
This isn’t a novel legal theory. The FTC previously used it against Epic Marketplace, for failing to disclose a non-cookie tracking technology. (That case was based on a prior project.) Even an advertising industry self-regulatory body acknowledged that non-cookie tracking requires special notice.
Another viable theory against Turn is that its opt-out mechanism is deceptive. The advertising industry’s self-regulatory guidelines say this:
The technologies that members use for [behavioral advertising] purposes must provide users with an appropriate degree of transparency and control.
It’s weak language, to be sure. Ordinarily, the “appropriate” control is opt-out, difficult to find, implemented as a flimsy cookie, and limits only ad targeting (not tracking!).
In the context of non-cookie tracking technologies, though, the text does have a little bite. A company can use a tracking mechanism that is stickier than a cookie. But for the “control” to be “appropriate,” it must be at least as sticky as the tracking. That’s not just a sensible interpretation—that’s the advertising industry’s own interpretation.
Companies must also ensure that their [behavioral advertising] opt-out mechanism provides consumers with real choice, which may require linking their back-end technologies to existing opt-out mechanisms so that they will function seamlessly no matter what technology is being employed.
As noted above, Turn does not link its Verizon header tracking to a consumer’s opt-out choice.
Are These Headers Legal?
The ideal enforcement target is, of course, Verizon. They started this whole header mess, and they can finish it. Others have previously argued that the unique header violates telecom customer privacy obligations. That might be.14
Given Turn’s zombie cookie practice, I think there’s also a good FCC, FTC, or state deception case against Verizon.15 The company has consistently misrepresented the privacy properties of its header, and especially the impact of its opt-out preferences.
In its explanation of the advertising header, Verizon says:
It is unlikely that sites and ad entities will attempt to build customer profiles for online advertising or any other purpose using the [header] . . . .
Security researchers disagreed. We were right.
For ad tech entities that have a presence on many websites, the [header] does not provide any information beyond . . . other already existing IDs.
False. The header enables more persistent tracking than other technologies, especially on mobile platforms.16
When a customer opts out of [Verizon advertising programs] the [header] cannot be used for advertising purposes because there is no information associated with it available to our ad partners.
Also false. Turn is using the header for ad tracking, and Verizon’s opt-out preferences do not alter Turn’s practices. This is precisely the scenario that security researchers warned about.
When a customer opts out, our partners receive no information, anonymized or otherwise, about those customers.
Again, false. Turn is a partner. And it’s receiving some information about the customer—a persistent unique identifier.
Since the [header] was implemented in 2012, we are not aware of any uses of the [header] other than the intended uses we have described here.
Might want to change that.
Verizon’s statements to the press are also inaccurate. Wired:
According to Verizon spokeswoman Debra Lewis . . . if you opt out of the company’s [header advertising program], then Verizon and its advertising partners won’t be using [the header] to create targeted ads.
Nope. CIO (and customer support):
Verizon spokeswoman Debra Lewis says . . . “If/when a customer opts out . . . there is NO information associated with the ID and therefore, no ability to use it for advertising purposes.”
Negative. Washington Post:
A company spokeswoman, Adria Tomaszewski, said . . . those who are not part of the Verizon advertising program . . . are not able to use the supercookie to track Verizon customers.
“The way it’s built, it wouldn’t be able to be used for that,” Tomaszewski said.
You get the idea.
Internet service providers are in a trusted position. They can arbitrarily observe and tamper with all of a customer’s traffic. What’s more, in the wireless space, carriers can exert control over a customer’s devices.
When ISPs have breached that trust to snoop on subscribers, they’ve landed in trouble. Debacles involving NebuAd, Phorm, and Carrier IQ come to mind. The reasons are evident: consumers have limited information, limited choice, and limited control.
Advertising headers are no different. AT&T has already yanked its program; it’s past time for Verizon to do the same.
Sometimes I write (shorter) stuff at @jonathanmayer.
I owe a debt of gratitude to Steven Englehardt, Arvind Narayanan, Jacob Hoffman-Andrews, and other friends and colleagues who contributed to this work. All views and errors are solely my own.
The graphics in this post remix resources that are Creative Commons licensed.
1. The only viable defense against the Verizon header is securing all traffic through Verizon’s network, e.g. with a VPN.
2. Researchers have previously spotted zombie cookies using Flash LSOs, HTML5 storage, HTTP ETags, and other tracking technologies. John Mitchell and I wrote a survey paper a few years ago synthesizing possibilities.
3. Specifically, I used my own header value from October.
4. Some Turn resources were a little more subtle, responding with just the old ID value. For instance:
$ curl -H "X-UIDH: OTgxNT..." -D - "http://d.turn.com/r/du/" ... Set-Cookie: uid=4012847891611109688; Domain=.turn.com;...
5. In my crawls, I saw more than one ID value get respawned. That suggests that Turn’s mechanism for associating an ID with an X-UIDH header is more convoluted than merely storing and replaying a single value.
Also, I tried testing with an older and newer Verizon header for the same device. They received different ID values, suggesting Turn is treating the header as an opaque identifier.
I should note that Turn’s implementation allows a website to steal a user’s
uid value. That could, potentially, allow an adversary to learn coarse information about the user’s browsing activity (e.g. based on ads displayed).
6. Not all Turn resources receive the Verizon header (e.g. those loaded over HTTPS or over a non-Verizon network). Also, not all Turn resources respawn cookies. An example:
$ curl -H "X-UIDH: OTgxNT..." -D - "http://ad.turn.com/r/cs" ... Set-Cookie: uid=4375890934513601832; Domain=.turn.com;...
If the browser does not have a uid cookie, and some of these resources are also embedded, a race condition arises between HTTP transactions. The browser can thrash between new and old cookie values, depending on request and response timing. In my testing, a zombie cookie was the most common end state.
7. A post-processing script checked URLs, referrers, and cookies for the zombie value. The results are available in a spreadsheet. Based on Turn’s partner APIs, as well as observations from Steven Englehardt, it appears other companies may have received the zombie value.
8. The Verizon header itself, of course, is sufficient information for persistent tracking. The header rotates periodically, however, making Turn’s zombie cookies more robust.
9. Assuming these firms keep HTTP request logs with cookie values, they’d have a zombie IDed database of user web browsing activity.
10. My understanding is the same as Steve’s. Relevant Mobile Advertising is an opt-out program that facilitates demographic and consumer profile targeting. It may also incorporate some behavioral targeting; Verizon’s language is ambiguous. Verizon Selects is a compensated opt-in program; it covers location-based and behavioral targeting.
11. A similar process is available on industry self-regulatory websites.
uid value can subsequently respawn or be reassigned, before the user has cleared their cookies.
13. It’s possible that Turn has an opt-out preference stored on its backend, tied to an
X-UIDH header or
uid cookie value. The technical evidence suggests otherwise—that would render the
optOut cookie entirely redundant and mean all three status checking mechanisms are broken. The definitive answer is in Turn’s backend which, of course, I can’t audit.
14. To my knowledge, no regulatory agency has yet challenged one of these practices as inherently “unfair” or “deceptive” in violation of consumer protection law.
15. One theory is that the header constitutes an unauthorized disclosure of “customer proprietary network information” (CPNI) under Section 222(c) of the Communications Act. Another basis for liability is that the header is “proprietary information” under Section 222(a), a new theory articulated by the FCC in a recent data breach case.
16. In this area, the Federal Communications Commission, the Federal Trade Commission, and the state attorneys general have concurrent authority. The FCC’s deception authority would stem from the Open Internet Order or Section 201 of the Communications Act.
17. According to several journalists, Verizon is keen to compare the header to Apple’s Advertising Identifier on iOS. That ID, while problematic, does have more favorable privacy properties. It isn’t accessible from the browser, users can forcibly change it, there’s an associated privacy signaling mechanism (“Limit Ad Tracking”), and all app developers are bound by enforceable conditions on using it.