How Verizon's Advertising Header Works (opens in new tab)

I looked into these legal questions in some detail in an article I wrote for CNET (before leaving to found http://recent.io/ earlier this year). The short answer is that Verizon has more leeway than it would if it's a cable company, and it's possible that VZ's actions implicate the Wiretap Act, but exact implementation details matter: http://www.cnet.com/news/web-monitoring-for-ads-it-may-be-il...

Here's a related article I wrote about Verizon selling customers' geographical locations, app usage, and Web browsing activities: http://www.cnet.com/news/verizon-draws-fire-for-monitoring-a...

My favorite quote from that story: "We're able to view just everything that they do," Bill Diggins, U.S. chief for the Verizon Wireless marketing initiative, told an industry conference earlier this year. "And that's really where data is going today. Data is the new oil." "We're able to identify what that customer likes not by filling out a form, but by analyzing what they do on a day-to-day basis..."

It doesn't work on SSL yet. Although I won't be surprised when in the near future certain carrier-enhanced phones start coming with a Verizon-signed root CA installed that enables them to crack into your SSL stream and do the same thing.

As for its legality, it shouldn't be, but it likely is. After all, it's well established that ISPs may mess around with your TCP and IP packets to enable NAT. So why not with the HTTP stream?

Here is a good analogy to use, one which the politicians will understand: it's like the postal service opening letters not only to read their contents, but to change them before forwarding them onto their intended recipients.

Public outrage will never be enough. There needs to be actual regulation.

It reportedly overwrites a header sent by the client:

https://twitter.com/kennwhite/status/525338284029775872

Maybe someone should write some browser plugins so desktop browsers can send fake X-UIDH headers to help poison the well, just a little.

Better still have the plugin get a group of known headers and distribute them all over.

I wouldn't call it particularly deep packet inspection—they're just rewriting the http requests.

Yes. This is pretty common for mobile data carriers to implement e.g. a transparent caching proxy.

Does Safari on iOS completely block mixed content (http resources embedded on https pages)?

If not, any page that embeds an insecure resource can still track you with this cookie.

If we're going to make fun of a political-theory-cum-religion, we might as well do it right:

Oh, oh, I know, this is when the Free Marketeers will tell us all that it would be so easy to build out a massive continent-spanning cell phone network to compete with Verizon if only the FCC Nanny State weren't in the way.

And that new network would certainly beat a network which has been entrenched for decades, because "Regulatory capture" is the only network effect networks have to deal with. Just keep saying "Regulatory capture" and we're bound to agree that the only way to deal with an imperfect system is to tear it down entirely.

I am sure there lawyers wear $5000 suits and made damn sure the contract is confusing as hell and lawsuit proof.

All mobile operators in the UK provide access to the end user's MSISDN, either via injecting a header or via a reverse IP API call (which gets around the SSL issue). In the UK mobile billing is highly regulated by Ofcom and PhonePayPlus, so only a small number of companies are allowed direct access to the end user's MSISDN. The relevant headers are only added to requests made to approved URLs; I don't believe O2 adding it to every request in 2012 was intentional.

To get around this a number of companies provide services that anonymise the MSISDN, so you can get a unique ID for end users the same as the Verizon header works. I don't know whether this is used by an advertising network or for cross promotion, but I would be highly surprised if it wasn't. Given one of the main proponents of mobile billing are the adult entertainment and gambling industries, I wouldn't put it past them to not have shady business practices like this.

Also Three and O2 are completely separate companies, O2 has a number of MVNOs of which Tesco is one.

(I used to work for a telecom services company in the UK)

My understanding about O2 was that it was a misconfigured proxy - they usually send your mobile number as a header to some internal sites (for example, you can check your pay-and-go account balance without logging in, IIRC), but managed to misconfigure it so it sent your number everywhere. They removed it ASAP, not putting up any sort of fight, so I suspect that's truly the case.

An article on the subject, from the same source: http://www.theregister.co.uk/2012/01/25/o2_number_sharing/

Or even better for Evil jacques_chester, they would have paid more to license it.

I looked in the logs on my public web server I host different sites on. I only found one UIDH record in my modsec_audit logs, but most worryingly it was it was for a personal injury trial lawyer. Made some records semi-anonymous.

--eee7b544-A-- [25/Sep/2014:15:33:19 --0500] VCR8D6wUChkAAG-HuKQAAAAH 70.209.73.XXX 32675 X.X.X.X 80 --eee7b544-B-- GET /wp-content/uploads/2012/07/XXXXXXXXXXX.jpg HTTP/1.1 X-UIDH: MTU4NTI5Mjg3AKafKcbQqnDdCMuP+UbmoCyKvEu8MnDsqV0I+AQ2K/M+ User-Agent: Mozilla/5.0 (Linux; Android 4.4.4; XT1030 Build/SU4.21) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/33.0.0.0 Mobile Safari/537.36 GSA/3.4.16.1149292.arm Host: www.XXXXXXXXX.com Connection: Keep-Alive Accept-Encoding: gzip

I've seen a lot of these headers on traffic that has no business having these headers (internal app traffic to a non-public-facing server)

EDIT: On the one server I sampled, they're included in approx. 10% of requests (mostly Android/iOS traffic)

They can't, because the endpoint is not the one that added the header. Application-level data sent over the network is being modified as it travels through Verizon's equipment.

This is happening after the request has left the browser and the phone

They don't need you giving them ideas.... sheesh!

The previous thread seems to suggest wireless only.

Nobody wants to defend against their ISP but it's clear at this point that you must. Comcast injects ads when you're using one of their wifi hotspots, Verizon has silently recompressed images and now adds these headers, AT&T uses DPI to detect tethering apps and add additional charges to your bill. The internet is a hostile environment.

There WILL be information leak vulnerabilities created by breaching the barrier between app HTTP client contexts and browser client contexts. Apps can now make HTTP requests to servers and correlate them with HTTP requests made from a web browser, which was previously not possible. You don't know which apps you use are using HTTP vs HTTPS to phone home, either. This is a complete compromise of the HTTP privacy model... which I guess proves what should be obvious: that HTTP HAS no privacy model, and that we should be using HTTPS everywhere.

Ah, thinking about it, this plan probably wouldn't work. Its easy enough for them to require sites wanting this ID to opt-in and then only supply the header to the white-listed sites.

Though reading more, sending fake X-UIDH headers on non-Verison traffic could be effective: the consuming sites need to make paid calls to a Verizon service to resolve the token in the header to an identity. Extraneous tokens could cost advertisers money.

I think you mean: Not having to kill battery life and rack up your data usage by having your privacy respected ftw.