But that commitment is coming under challenge, in view of ongoing revelations about Verizon’s “supercookie” program. The New York Times called it a “Threat to Privacy”; Wired went further, deeming it “a Privacy-Killing Machine.”
Advocates have called for immediately terminating the program, pointing to AT&T’s decision to suspend deployment of a similar technology. But Verizon has refused to make any changes to it, because it is already using the program.
At first glance, this is much like the fights we often see between big companies and consumer watchdogs, between new technologies and businesses on the one hand, and individuals’ interests like privacy on the other. But is it really such a zero-sum game, where one side must lose for the other to win? Or is there something else?
Verizon’s controversial technology basically involves attaching tracking numbers whenever customers view Web pages. Generally, to visit a Web page, my computer (or phone, tablet, etc.) sends a request message to the website with that page. Think of this like a very (very!) fast version of sending a letter through the mail, requesting some information.
Now imagine if the Postal Service assigned an identification number to me, and every time I sent one of those letters, a postal worker opened up the envelope and stamped the ID number inside. That is more or less what Verizon has been doing: Every time a Verizon Wireless customer requests a Web page, Verizon rewrites the request in transit to include a tracking number identifying the customer.
That tracking number is called a “Unique Identifier (UID) Header” by Verizon, but called a “supercookie” or “permacookie” by its critics. It does resemble a “cookie,” the type of tracking number that websites have been using for decades now. But it’s easy for users to delete cookies. Verizon’s tracking number is tacked on by Verizon after the request has been formed and sent, so it cannot be deleted—hence “super-” or “perma-cookie.”
The UID is part of Verizon’s new targeted advertising system. Websites that receive a UID header can, for a fee, ask Verizon for information about the customer associated with the UID, and that data can be used to target advertising to the user.
That targeted advertising system is, in itself, no small privacy concern. Privacy advocates have called for shutting down the supercookie program for good reason: Besides just being creepy, Verizon’s steaming-the-envelope-open approach tends to discourage adoption of privacy-protecting technologies such as end-to-end encryption. This privacy issue will certainly be argued over, negotiated, and possibly regulated or legislated on in the near future, and it would surprise me very little if Verizon dropped or modified its UID technology in the next few months or years—indeed, when I contacted Verizon about this story, a representative told me that Verizon was “working to expand the opt-out to include the identifier referred to as the UIDH, and expect that to be available soon.”
But the UID also raises a second privacy issue, one that is more immediate, one that is perhaps more insidious, and one that Verizon has absolutely no excuse not to fix immediately. This is a problematic use of the UID beyond Verizon’s intentions, most recently highlighted by the activities of an online advertising firm called Turn.
Essentially, using Verizon’s supercookie, Turn figured out a way to keep a tracking tag permanently chained around my neck, despite my best attempts to cast it off.
The episode was reported widely enough to be embarrassing, and Turn announced the same week that it would end these practices. Verizon, for its part, did something of a sheepish non-about-face. Prior to the news about Turn, Verizon had put up a page about the UID header assuring that the UID would not be used by third parties for tracking. But immediately afterward Verizon altered the text, without flagging the changes, to acknowledge Turn’s use of the UID for tracking. The relevant statements, with emphasis added, are reprinted below:
Jan. 14, 2015
Jan. 21, 2015
|It is unlikely that sites and ad entities will attempt to build customer profiles for online advertising or any other purpose using the UIDH for two reasons: First, the UIDH changes frequently. Second, other permanent and longer-term identifiers are already widely available in the wireless area and could be used to build customer profiles.||Recent news reports have raised concerns about how TURN is using the UIDH for purposes outside of Verizon's advertising programs. TURN has announced its intent to discontinue this practice and we will work with other partners to ensure that their use of UIDHs is consistent with the purposes we intended.|
Of course, Verizon’s promise to “work with other partners” skirts the problem. Turn’s clever UID hack resulted not from Turn being a Verizon partner, but rather from Verizon’s forcible attachment of a tracking beacon to all Web requests, visible to all websites, partners or not. If Verizon is to solve the privacy problem it now recognizes, it needs a technological fix, not a partnership change.
The fix is not even my own solution: The Stanford researcher who first looked into the UID header dropped the idea into a footnote back in October, and a Princeton Ph.D. student expanded upon it in an equation. My purpose here isn’t to invent a new fix. It is to show how dead-simple that solution is.
The privacy problem exploited by Turn arises because Verizon sends the same UID tracking number for every request from a customer. So the solution is for Verizon to send different numbers for each request, such that Verizon alone can determine the customer associated with any number. Though I illustrate the solution below in full detail with program code to show that it actually works, the operations are in fact quite simple.
Specifically, Verizon assigns each of its customers a UID, as it does now. But rather than simply inserting the UID into each Web request from the customer, Verizon takes two extra steps for each request. First, it tacks on a random number called a “nonce” to the UID. Second, it scrambles the number based on an encryption algorithm and a password, to make the resulting value look unreadable and random when it is sent out to websites. (The nonce ensures that the encrypted result changes on every request.)
To see this in action, I made up a few UIDs, in a hypothetical situation where one user sent three requests and a second user sent one:
Encrypted value sent to websites
As these examples show, even when the UID is the same, the encrypted value looks entirely different for each request. The receiving websites would have no way of knowing whether these were one user, two users, or four users. Turn couldn’t revive deleted cookies. Yet those websites could still send the encrypted value to Verizon and get back targeted advertising information as they did before, since Verizon knows how to decrypt and extract the customer UIDs.
So just how hard is it to perform such a process? Even in a complicated enterprise programming language like Java, it takes a whole whopping four lines of computer code:
// Set up AES encryption with the secret key
byte nonce = new byte; new java.util.Random().nextBytes(nonce);
// Generate the random number (called a “nonce”)
// Tack the customer UID on after the nonce and encrypt them
When it comes time for Verizon’s advertising system to figure out which customer is associated with one of these random numbers, that process requires all of five lines of code:
// Set up AES decryption using the secret key
byte decrypt = aesCipher.doFinal(cipherText);
// Decrypt the random number received by a website
byte result = new byte[decrypt.length - 4];
System.arraycopy(decrypt, 4, result, 0, result.length);
// Chop off the nonce from the decrypted data
// What remains is the customer’s UID
(The use of the same secret key for encryption and decryption might create some issues depending on the state of Verizon’s servers; if this is a problem, I’d encourage the engineers to look into public key encryption.)
So with just a tiny amount of effort, Verizon could maintain its current business while substantially preventing the misuse of its UID headers. It can have its supercookie and eat it too.
Often the assumption is that technological progress and business interests must be in opposition to privacy. Those who cherish privacy are ridiculed as Luddites, after the 19th-century anti-technology movement. Former Sun Microsystems CEO Scott McNealy’s line, “You have zero privacy anyway—get over it,” has been used to justify all sorts of privacy-invasive moves by companies like Facebook, Twitter, and Google.
But this Verizon episode brings me to the opposite conclusion. The supercookie solution I’ve given above is possible only because of technology such as encryption. New innovations can certainly diminish privacy, but they can also enhance it. It is not technology itself that undercuts privacy; it is lazy technology—like sticking a giant tracking beacon to all Web requests—that undercuts privacy.
Certainly this small fix will not solve all problems—to many, it will not fix the core problem—with Verizon’s supercookie. Verizon cannot declare victory by merely taking up this suggestion. But there is no reason for it to wait. The fix is simple, costing nothing more than a few minutes of engineer time, and the problem being addressed is real and immediate.
Verizon says that it is committed to our privacy, and I hope that commitment is worth nine extra lines of code.
This article is part of Future Tense, a collaboration among Arizona State University, New America, and Slate. Future Tense explores the ways emerging technologies affect society, policy, and culture. To read more, visit the Future Tense blog and the Future Tense home page. You can also follow us on Twitter.