Verizon advertising partner Turn has been caught using Verizon Wireless’s UIDH tracking header to resurrect deleted tracking cookies and share them with dozens of major websites and ad networks, forming a vast web of non-consensual online tracking. Explosive research from Stanford security expert Jonathan Mayer shows that, as we warned in November, Verizon’s UIDH header is being used as an undeletable perma-cookie that makes it impossible for customers to meaningfully control their online privacy.
A virtually unchecked and unbound company with near-monopoly status in many US areas doing something scummy? I am so surprised.
As I already mentioned in the article about Cameron and encryption, these kind of things are precisely the reason why the Internet community is moving to all encrypted.
The Internet standards making body, the IETF said, after the Snowden leaks:
“to make encryption the norm for Internet traffic”
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentia…
The W3C is working on a draft for transitioning the web to HTTPS-only:
https://w3ctag.github.io/web-https/
The EFF, IdenTrust SSL and Mozilla with sponsering from Cisco and Akamai are making sure HTTPS-certificates are free and easier to install:
https://letsencrypt.org/
Lennie,
Except in this case it’s the website that is in control of whether HTTPS is used or not. So it doesn’t really help. If the website wants to get the user’s ID, it can.
It’s but a few months ago that verizon sold customer information to advertisers without offering any of them a chance to opt in or even opt out. The one-time $7.4M fine was a joke for verizon.
http://transition.fcc.gov/Daily_Releases/Daily_Business/2014/db0903…
The FCC needs to make a serious case of these privacy abuses. Versizon knows this is wrong but they only think in terms of money, so fine them $100M per week until they learn that maintaining customer privacy isn’t something that’s optional or can be defeated with fancy lawyering.
While it’s nice that CA certs are becoming more easily affordable, I’m still keen on seeing DNS-SEC get adopted such that we can secure HTTPS with our own certificates. All websites really should be able to use HTTPs simply by installing the right DEB or RPM, without relying on 3rd party CAs at all.
Edited 2015-01-15 19:41 UTC
I meant if all websites move to HTTPS then Verizon can’t change the HTTP-headers of all mobile HTTP-traffic.
Thus problem solved, because the advertising network can’t add any HTTP-content inside of a HTTPS-webpage.
It’s called ‘mixed content’ and is not usually allowed by the browser policy.
Obviously that doesn’t solve the problem right now, but I’m glad it’s finally going to happen.
Lennie,
Often times the websites are working with the advertisers rather against them, but anyways I put this theory to a test. I’m using desktop browsers instead of mobile ones, but if you can overlook that…
From an HTTPS page:
Loads HTTP scripts: safari
Loads HTTP iframes: safari
Loads HTTP images: safari, chrome, ff
Loads HTTP ajax: chrome, safari
Loads HTTP iframes through a server side redirect: safari, chrome, ff
Loads HTTP ajax through a server side redirect: safari, chrome, ff
So I don’t think HTTPS an effective solution today for stopping Verizon’s tracker beacons, and I haven’t even tested other techniques like css/fonts/popups/media/flash/websockets/…?
Edited 2015-01-15 20:44 UTC
Any gaps are being closed or have already been closed in most modern browsers:
https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mix…
As far as I know the browsers that only support images also block cookies when the image is loaded.
Lennie,
You say this, but my short test today shows they haven’t been closed yet. Apparently they didn’t even try the redirect test, probably because most web developers wouldn’t do that, but advertisers would if it yielded user tracking.
You might argue that browser makers ought to stop supporting HTTP from HTTPS, but you would break things such as content distribution networks and unless you want to block HTTPS -> HTTP navigation in general then determined advertisers could still exploit it with clever multipage requests.
If you want HTTPS everywhere, and don’t mind breaking lots of “legacy” websites in the process, then yes I suppose we could close all the holes.
Edited 2015-01-15 21:34 UTC
As you can see from the table, it’s currrently only 2 browsers that have everything except for images blocked.
It’s going to be a looong transition, I know.
But that is exactly what they are working on.
Content Distribution Networks are making HTTPS not something you pay extra for but something that is free.
Why do you think Akamai is a sponsor of Let’s Encrypt project ?
You can now use HTTPS for free on a free ‘CDN’:
https://www.cloudflare.com/ssl
They are formalising what mixed content is, defining it’s behaviour and how it should be displayed in the browser UI:
http://www.w3.org/TR/mixed-content/
And disabling features that should not be enabled on HTTP:
http://www.w3.org/TR/powerful-features/
Google is ranking HTTPS higher:
http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking…
The chromium developers started the idea of marking HTTP as insecure:
http://www.chromium.org/Home/chromium-security/marking-http-as-non-…
Making sure HTTPS isn’t slow:
http://istlsfastyet.com/
All sorts of things to move to a HTTPS-only worlds.
Lennie,
Yes of course I did read your link and saw the table. While it’s an informative link, I personally tried it myself and was able to get the latest version of Firefox (35) to send an HTTP request from an HTTPS page. So the link is inaccurate or at least incomplete. You don’t have to take my word for it, add a server side redirect on an HTTPs page and you can test it yourself.
Yep I know that it will take a long time to phase out HTTP. Unfortunately it can still be difficult/awkward for shared hosting websites to implement HTTPs since many services still require it to be on a dedicated IPs, but maybe that will fade away over time…
http://stackoverflow.com/questions/5154596/is-sni-actually-used-and…
On the scale of importance, I’d rank IPv4 phaseout to be much more critical, but I’m not holding my breath
Edited 2015-01-15 23:14 UTC
That is why Server Name Indication exists:
http://en.wikipedia.org/wiki/Server_Name_Indication
There are still some browsers that don’t support it though:
http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side
Most important ones are: IE 6, IE 7 and IE 8 on Windows XP. IE8 (which also means Vista) is at below 6%.
And the Android browser on Android 2.x which will also has some share, but IE will take longer to really get rid off.
I think later in 2015 people will start to deploy with SNI on a wider scale.
One of the reasons is, old IE SSL-/TLS-implementation isn’t safe anymore anyway. The default settings doesn’t support safe protocols. And a lot of websites don’t want to allow down-grade attacks just to support IE on a non-supported Windows version.
Cloudflare already does so, they have a million websites: https://blog.cloudflare.com/introducing-universal-ssl/
There are some search engine robots build in Java which still use an older Java version, that sort of stuff, but when people start to deploy it more, they will upgrade too.
Yeah, you are right, redirect still works.
Images are enough. They just need something, anything to be in HTTP then they can insert the tracking codes into it.
Carewolf,
Yep. But to be honest, I have to wonder if an ISP may still have opportunities to add tracking tags to HTTPS streams as well. I took a look at the RFC for TLS negotiation (ie the handshake that has been updated to allow the clients to specify hostnames via SNI).
http://tools.ietf.org/html/rfc6066
There is some negotiation before SNI is able to establish which encryption certificate to use. Client certificates stand out as one possibility, but even the SNI protocol itself allows the client to specify a “ServerNameList” with different “NameTypes”. The intention behind this is to allow the client to specify the domain name it wishes to connect to before the server returns a certificate for that domain, but it might be possible to abuse it by appending other NameTypes to be used for tracking.
I’m still scratching my head why Verizon would have opted for an in-band tracking mechanism in the first place though? Injecting HTTP headers in read time means stateful gateways keeping track of all HTTP sessions and fixing up the TCP windows to compensate for ISP modifications. That can’t come cheaply.
An out of band tracking mechanism would have been far more straightforward; the advertiser could simply use a webservice to request the same data in real time. So I’m baffled why they elected to modify the user’s payloads…maybe there’s a legal difference? Maybe they are using out of band mechanisms too but it hasn’t come to light?
Yes, I totally agree images should also go off the list as well. I believe they can’t use cookies though, at least in IE by default you can’t set cookies though.
That is a start.
My guess is, it is on the list because of webmail.
If you have HTML email, you’d maybe want to load the images and display them.
Gmail these days does a proxy-request and virus-scan, but also only since last year if I remember correctly.
And maybe some sites want to load images from a CDN ? Most sites currently with HTTPS want to keep the secure marker in the addressbar, so they wouldn’t want to load images from HTTP.
Anyway, it’s going to take at least years to get everything to HTTPS.
Edited 2015-01-16 09:50 UTC
And piss off the very groups that keep them in power? You have a very optimistic view of the system if you believe for a moment that the FCC will go against their primary group of supporters. After all, without the FCC, Verizon would not have their regional monopolies.
darknexus,
You should know it’s my soapbox rant, I’m not actually all that optimistic
Verizon even got TWO patents on the usage of UIDH headers:
http://www.google.com/patents/US20130318581
http://www.faqs.org/patents/app/20130318346
I verified that, indeed, VZW is injecting this header into my traffic. However, with the last non-stock ROM I flashed, that header is no longer present.
In all I’d say it’s a sensationalist view of a non-issue IMHO.
Drunkula,
Are you sure about that? These headers are added on verizon’s end and not on your phone. This link provides details:
https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
It’s not something verizon’s installed on the phone, but rather a manipulation of traffic going through their service. Apparently even non-verizon customers have the tracking ids added when they’re roaming or using verizon’s network through resellers.
You can use these two links to see if the headers are added, but you MUST be connected through verizon’s cellular network and not WIFI.
http://lessonslearned.org/sniff
http://www.amibeingtracked.com/
Can anyone verify verizon is still doing this? Enough bad press might coerce them to shut it off.
Be aware that verizon isn’t alone in implementing much more robust web tracking to get advertising dollars.
http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-tes…
Yes I’m sure. I already ran the tests on LTE, not WiFi.