How Verizon's Advertising Header Works | Hacker News Reader

How Verizon's Advertising Header Works

webpolicy.org

146 pointsjonathanmayer65 comments

It's one thing for your ISP to be collecting information about you; it's totally another thing for your ISP to be silently modifying your data by adding a tracking header and sending it to all other sites you visit.

Modifying application-level data is something an ISP should never do. What if I happened to be using the exact same header name for some other purpose for a web app API? This should be considered illegal tampering with the content of communications.

The "encrypt everything" proponents are missing the point: yes, encryption (and steganography) can be used to bypass this easily, but I don't want to have to explicitly defend against my ISP modifying my data.

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.

Notably: the exact same device ID (X-UIDH) is injected into HTTP requests from different browsers/apps, or browser tabs in 'privacy' or 'incognito' mode. Also, if you're using 'personal hotspot', any HTTP traffic from a connected desktop/laptop sharing the mobile data service also gets the header.

So VerizonWireless is allowing third-party sites to correlate all HTTP traffic from one device to a single identity, even if you've taken explicit steps (like 'incognito' mode) to try to thwart this, and even if the mobile OS has compartmentalized apps away from seeing each others' identity data/cookies.

Only HTTPS and VPN traffic is immune, and as far as I've been able to find out, there is no way to opt-out. (None of the VerizonWireless privacy settings stop the header from being injected.)

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.

They need to be publicly attacked for doing this. Only massive embarrassment will change the behavior. Maybe get some politicians involved if there are any they haven't bought yet.

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.

Is it though? Or is it like the postal service scrawling a unique ID on the outside of the envelope?

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

I haven't seen it mentioned anywhere, but this can't work over HTTPS. The message is fully encrypted end-to-end and Verizon Wireless can't do anything to alter the content without destroying the whole message.

Seems like a few people know this, lots of talk about SSL & TLS, but I don't think anybody has mentioned it explicitly.

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.

Some are blocked and some aren't... actually I don't know what isn't/is...

The padlock goes away if mixed content shows, though.

Oh, oh, I know, this is the moment where smart people on here tell us that more regulation by the FCC would be a bad thing!

Because you know, a telecommunications provider that manipulates the content of your telecommunication is just screaming out for being an overregulated area of business.

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.

your statement ignores nearly a century of history and a bunch of technological facts.

Anyone know if....

A. It is possible to request your "advertising profile" from them.

B. Can a customer request that gathered information on them be destroyed?

C. If you opted-out today (like me) does that mean that they stop collecting information and continue to sell "your devices" ad profile? Or do they also stop selling your info?

(sending these to Verizon. I'll post if I get answers)

Is this even legal? I mean are ISPs, or telecom in general allowed to identify the requester without their permission? But I imagine it will not work on encrypted connections. SSL FTW?!

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?

it's a good reason to buy iphones. Apple will let a poisoned ca cert on their phones about the same time hell freezes over. Android can probably only be trusted if it's a nexus phone.

apparently suckers believe that lg, the company that makes tvs that upload shows watched or files on your network, or samsung, the company that needs your phone number, address book, gps location, and accounts in order to download jayz mp3s, wouldn't install a cert for verizon

I regularly install a self signed CA cert to reverse engineer the API behind various apps. Your tech-unsavvy person need only follow a couple of steps to install one too, especially if it's their network saying "This increases performance and speed or w/e guff we need to convince you to do this"

I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, and other TLS implementations should be ignoring for compatibility. It's maybe not as easy for ad networks to consume, but where there's money to be made, there's a way.

I think this would work. Am I missing something? Has anyone checked if it's already being done?

[0] https://tools.ietf.org/html/rfc4366#section-2.1

They don't even have to inject anything, it's surprising they're doing this at all. They could just use the TCP/IP source and destination addresses and ports to identify the connection. TLS wouldn't help that. VPN would though.

Maybe, but it sounds more messy. Verizon would have to maintain a semi-public (to their "other" customers, that is, advertisers etc.), low-latency queryable database of {source, destination, customerID} tuples, and ads and/or pages might not finish loading until that query returns. If the ID is more static, the trackers can cache the identity information for awhile after the first time, and Verizon probably has less work to track and resolve IDs.

I haven't had the opportunity to tinker with this, but what if the client sends a X-UIDH: header of it's own? Will VZW overwrite the header, or will it pass it through? If it doesn't clobber it, there's a browser plugin waiting to be written.

It reportedly overwrites a header sent by the client:

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

Given the ordering of the process, that makes sense. I'm not a Verizon customer but I would be gone yesterday if I were after reading about this.

As I understand it, they offer an "opt out" that doesn't actually opt you out of this.

Truly gross behavior, though.

> I'm not a Verizon customer but I would be gone yesterday if I were after reading about this.

And where would you go? AT&T? Is that really a better option?

Sprint and TMo just don't have the reception everywhere I go (or didn't last time I checked).

I'm a TMobile customer. Reception is perfectly fine in any metro area. I work in metro areas. Admittedly, I lose service on vacation, but maybe that's for the best.

T-Mobile roams on AT&T.

Or at least, some plans do. My legacy per minute plan does.

I'm pretty sure Sprint roams on Verizon, they just won't offer you service for an address where you would be roaming all the time.

> everywhere I go

That included the middle of the Appalachian mountains.

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.

So, I suppose this means that ads that Verizon customers see are potentially targeted by their home address, age, gender, and call/texting patterns.

Holy shit, if I was a customer that would be ending today, even if I was in a contract, I'd say they pretty clearly are in breach of contract over my privacy expectations, by sharing who I am with every website I visit.

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

Agree. This is going to require regulation, which means putting up with the whining of all the pseudo-libertarians out there.

Using the SOPA visibility strategy could be effective. If enough popular sites redirected requests that had a X-UIDH to a Informational page about the privacy intrusion, people might care (if only for the extra click its causing them).

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.

The largest network in the UK, O2 (and therefore Three and Tesco), were sending your mobile number as a HTTP header to every site you visited [1]. Didn't last long.

ISP's have also tried this in the past - I remember a few in the UK trying to set up an ad-injection model, but can't seem to find them now, other than NebuAd [2].

[1] - http://www.theregister.co.uk/2012/01/25/o2_hands_out_phone_n...

[2] http://en.wikipedia.org/wiki/NebuAd

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/

Universal TLS can't come fast enough.

Doesn't/didn't AT&T also add a header of their own?

http://blog.jgc.org/2012/02/mobile-subscriber-leakage-in-htt...

http://developerboards.att.lithium.com/t5/Technical-Question...

I happen to be in the process of patenting an opt-in system for authenticating and recording requests from users. One of my design goals was to prevent anyone from piggybacking on the scheme to track the users across multiple requests.

It occurs to me that if I'd been suffering from a less overdeveloped sense of decency, I could've filed sooner with something like this and hit Verizon with a lawsuit.

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

That guy really knows how to make out like a bandit.

I work in mobile advertising (not in the US), and my company is partnered with a mobile carrier that does something similar, although the "header enrichment" as it's called is only enabled on specific domains (i.e. requests to our ad server API). I feel that it's unlikely these headers are being set on all web requests. Has anybody verified this claim?

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)

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

At work I was trying to set up VPN access on a few busses we have. We tried using a Verizon device but couldn't because Verizon puts you behind their NAT. It costs $500 to get out from behind it. I guess this is why.

This is actually really good, because if advertisers have an Verizon API to query the cookies for demographic information, in theory intelligence agencies could have an API to query a cookie to see if the device belongs to a U.S. person and stop incidental collection of that stream. Which is what they would do, right?

Oh wait, a bad guy could steal your phone. Guess we'd better collect it all. Hey, I guess we could use that cookie for something...

Shouldn't Chrome and Safari simply block this behavior? Google, for instance, is now presented with a rare situation: users' privacy and their own business concerns are aligned (since audience segmenting is a core product of the Google Display Network).

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

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.

Interesting - my cookie, collected the day this broke, has the same prefix as the author: "981596494\x00"

I'm now getting a different cookie (same physical location) that starts with: "379689122\x00"

Bandwidth costs money, correct? I wonder if for someone with zillions of small HTTP requests (Google, Twitter, Facebook, etc) these costs might be recoverable somehow.

This means that they are doing deep packet inspection and re-writing the actual packets sent over the network, right?

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

wouldn't re-writing the HTTP request require inspecting the packets as deeply as it is possible to?

yes

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

VPN or TLS ftw

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

is this for fios or just wireless?

The previous thread seems to suggest wireless only.

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

Reply on news.ycombinator.com