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.
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.
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.
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...
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?
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?
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.
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.
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"
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 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.
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.
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.
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].
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.
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.
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 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.
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).
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.
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.
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.