One Smart Cookie

One Smart Cookie
By (Dr. Neal Krawetz)

Girl Scout cookies are back in season. And that always makes me think about Thin Mints, Samoas vs Caramel deLites, and HTTP tracking methods.

Over a year ago, there was a large uproar about “perma-cookies”. These are fields added by some ISPs to plain-text HTTP headers. Perma-cookies include information that can be easily used to identify and track individuals. I had blogged about them back in October 2014.

As I munch on my Peanut Butter Patties (or are they Tagalongs? I can never remember which bakery they come from), I thought I would revisit these HTTP tracking headers.

All Abouts (a discontinued cookie)

Over a year ago, the big hoopla concerned tracking headers that Verizon was inserting into HTTP traffic. Specifically, Verizon was adding an X-UIDH header into web requests, and web servers could use these to track individuals, regardless of their network address. (However, I’ve seen no evidence that sites were actually using these values to track users.)

Of course, the 2014 report from Wired was only partially correct. As I noted back in October 2014:

  • Wired says that the strings are “about 50 letters, numbers, and characters”. I’ve only seen 56 and 60 character sequences. The data appears to be a base64-encoded binary set. If you base64 decode the sequence, then you’ll see that it begins with a text number, like “379612345” and it is null-terminated. I don’t know what this is, but it is unique per account. It could be the user’s account number. After that comes a bunch of binary data that I have not yet decoded.
  • Wired says that the string follows the user. This is a half-truth. If you change network addresses, then only the first part of the base64 X-UIDH value stays the same. The rest changes. If services only store the X-UIDH string, then they will not be tracking you. But if they decode the string and use the decoded number, then services can track you regardless of your Verizon-assigned network address.
  • Wired makes it sound like Verizon adds the header to most Verizon clients. However, it isn’t added by every Verizon service. I’ve only seen this on some Verizon Wireless networks. User with FIOS or other Verizon services do not get exposed by this added header. And even people who use Verizon Wireless may not have it added, depending on their location. If your dynamically assigned hostname says “”, then you might be tagged. But if it isn’t, then you’re not.
  • The X-UIDH header is only added when the web request uses HTTP. I have not seen it added to any HTTPS headers. However, most web services use HTTP. And even services like eBay and Paypal load some images with HTTP even when you use HTTPS to connect to the service. So this information will be leaked.

This discovery was quickly followed by accusations that AT&T was doing a similar kind of tracking. AT&T was adding in an “X-ACR” header that includes a tracking ID. However, that isn’t all. Fifteen months ago, I also reported on Vodafone’s use of a “X-VF-ACR” header.

Within months, Verizon reported that they would stop using these cookies — except in limited situations. They even created an FAQ that still says:

When the Verizon and AOL advertising programs are combined, Verizon will send the UIDH only to Verizon companies (including AOL) and to certain partners who help us provide advertising and other services.

Other companies, like AT&T, also said that they would stop using perma-cookies.

Since it has been 15 months, I decided to dig through the logs at FotoForensics and see what has been changed.

Shortbread, or Trefoils?

Let’s start with Verizon’s X-UIDH headers. The number of sightings definitely dropped off after 2014, but they never completely went away. As of today, the last sighting at FotoForensics was on 2015-10-22 (from a user located in/near Belvidere, Illinois). When Verizon first claimed to kill this header, I had a small gap with no sightings. But then they started up again. They continued to use them for over a year since they claimed to stop. (And since I’m definitely not a “Verizon company” or one of their partners, their FAQ contains a bold-faced lie.) With the current two-month gap, I don’t know if they have stopped using them, or are just taking a short break, or — since only some regions still use the headers — maybe users in those areas are not visiting my site right now.

AT&T stated that they would stop using the X-ACR headers with tracking tokens. The last ones I saw were in January 2015 (a year ago). So they do seem to have stopped inserting that header.

I last saw Vodafone’s “X-VF-ACR” header in May 2015. So they also stopped.

And even Cricket Communications appears to have stopped adding in the “X-WAP-KID” header last July.

So far, it looks like a good trend. Except… some carriers are still inserting tracking headers. For example, AT&T stopped using the X-ACR header, but still uses the “X-ATT-IMSI” header to include the Mobile Subscription Identification Number (this number is unique to you). And the X-UP-SUBNO header, which is added by AT&T, Bell Canada, and KDDI in Japan, is still in use. Nokia still adds in the X-NOKIA-MSISDN header, Huawei still uses “X-HUAWEI-IMSI” (really big in India), and Japan’s SoftBank still adds in the X-JPHONE-UID header.


Of all of these different companies that employ tracking methods, I think the worst offender is AT&T. I used to have T-Mobile as my cellphone carrier, but they dropped the pay-as-you-go plan. So instead, I had my phone carrier-unlocked and switched to Consumer Cellular (which offers cheaper options for my use case).

Consumer Cellular has agreements to use T-Mobile T-Mobile, Cingular, and AT&T networks. If my cellphone uses the T-Mobile network, then no extra headers are added to my HTTP requests. However, if my phone uses AT&T’s network, then AT&T appends a lot of personal information to every HTTP request:

  • X-Att-Imsi: This is my International Mobile Subscribed Identity and is unique to my phone.
  • X-Att-Plmn-Id: This contains my MCC+MNC code; that’s the mobile country code (MCC) and mobile network code (MNC). These values identify the country and carrier. For example, MCC 310 is the United States, and MNC 410 in the United States is Cingular Wireless (now AT&T).
  • X-Up-Calling-Line-Id: This contains my cellphone number. Seriously: AT&T sends my direct cellphone number to every website my phone visits. Looking over my web server logs, I see other people who have been through this same path. Thanks to AT&T, I have direct phone numbers for people in Portland, Oregon and Cincinnati, Ohio and Roanoke, Virginia and… I’m actually surprised that my cellphone hasn’t received more telemarketer calls.
  • X-Up-Subno: This very-disturbing field includes a timestamp that shows when (down to the second) I signed up with Consumer Cellular.

I can honestly see no justification for inserting this amount of personal information into HTTP headers. For this reason, I stopped using my cellphone’s data plan. (Fortunately, Consumer Cellular permits me to easily disable the data service.)


I find it disheartening to see that the number of tracking perma-cookies has not significantly decreased. In fact, excluding the three headers that were called out by the media, there has only been an increase in this kind of header alteration and tracking information. For example, Facebook introduced an “X-Fb-Sim-Hni” header that lists your phone’s MCC+MNC, as well as your type of network connection (X-Fb-Connection-Type). Network Associates still uses the X-NAI-ID header, and why does the Apache Rave Portal need to send your username to every site you visit (via the HTTP RAVE-USERNAME header)?

Girl Scout cookies are only available for a limited time each year. In contrast, you can find these perma-cookies and tracking tokens all year long.

January 24, 2016 at 01:31AM
via The Hacker Factor Blog