An Alternate Approach to Subverting the Permacookie
Mobile Internet Service Providers (ISPs) are violating their customer's privacy by tagging all unencrypted outgoing HTTP traffic one sends through them, which in turn becomes a tracking ID in multiple ways. Mitigation steps exist to combat this, to include use of VPNs to encrypt data from being read or altered by the ISP. However, we sought to explore other non-obvious approaches.
We explored ways to subvert his behavior by attempting to invalidate the data sent along by the ISP, or to halt the sending of such data/headers at all.
Briefly, our respective approaches were to send packets that already had the HTTP header populated with the appropriate name but with alternate values (i.e. adding a random but valid tracking ID to each packet, thus making the traffic inaccurate and unusable), as well as explored ways to get the ISP technologies to stop providing any tracking header at all.
Though not an exhaustive effort, in the end, we were unsuccessful to both ends. In the first case ISPs ignored the spoofed headers we provided, and in the latter experiments, we were unable to introduce any additional or altered header that caused the ISP to not include the tracking header. What we learned aided in our understanding of what is in place, and we think the sharing of the approach and knowledge gained could aid the respective public dialog. Thus we have published details of this research.
Many US mobile carriers are adding a tracking header to all outgoing unencrypted HTTP requests. They have different respective header names, but it is the same pattern and likely use of the same underlying technology.
It has been dubbed "permacookie" as it has a familial behavior to browser cookies. Client browser cookies are HTTP headers managed at the client machine-level and use a particular HTTP name. Permacookies are managed at the mobile ISP level, and have different HTTP header names depending on the cell carrier.
Carriers are modifying all your unencrypted web activity by tagging all unencrypted HTTP requests with a unique custom header. This includes requests made by apps.
As carriers are embedding your unique ID, which can be used to query for demographic, geographic, and behavioral info, to every unencrypted HTTP request, sites can thus identify you immediately, over time, and across properties. Such can be used inclusively for filtering content, and customizing advertisements. (At the moment, less is known publicly on how it is being utilized by sites.)
A few year back it was reported that "Routers from Juniper Networks will soon include Feeva's zipcode tracking software, assuming ISPs want it."
Weeks ago it broke that "Verizon Wireless was injecting identifiers that link its users to Web requests" and perverting users' privacy. Later others disclosed that Verizon was not alone.
As of this week, AT&T is claiming to cease use of it, for now, but no word from other carriers.
To see such for yourself, visit the sites below, first when on your carrier network, and then later via WIFI. Best approach is to turn off WIFI when executing the carrier test.
Lessonslearned.org's informative page identifies the carrier specific headers (See "Broadcast UID")
Our echo page shows all headers included in any request. If using a cell phone, tablet, or hot-spot for internet, the respective permacookie header will be present if such has been added.
Note: not all towers for the guilty carriers are active, but was for all used in our tests.
Obvious: Encrypt the data so that the carrier router does not have chance to inject HTTP header (Method: SSL sites and VPNs)
Non-obvious: Trick ISP routers by altering requests so they see such as already accurately tagged or not requiring tagging (we discuss such below)
"Obvious" techniques to get around tracking:
Only use SSL sites and resources. Problem with this approach is that not all sites are SSL and even requests inside these sites might not be all SSL.
Use of trusted local anonymous HTTPS proxy. Problems with this approach: hard for lay-users, and who has a trusted local (ie before you hit the internet provider) proxy at their disposal? (Removed after some distance and clarity, as this did not solve the problem, though would allow one to modify outgoing traffic if indeed there was a way to trick the ISP into not tagging via pre-tagging.)
Use of a trusted anonymous HTTPS proxy that strips these headers. Problem with this approach: requires special proxy tuned to remove these headers, and the ISP is still tracking your use, though destination sites would be prevented from seeing such
Use of trusted VPN. This is the best approach as you gain an all ports all protocols tunnel from you to VPN node, while the ISP is in the dark and prevented from seeing/modifying any requests. Problem with this approach: such requires constant connection to a VPN from your mobile device.
Note: proxies are a primitive tool requiring semi-sophisticated technical background, thus not best approach for lay-users.
"Non-obvious" approach explained:
We did some light research and development to see if we could attack this from another angle. Specifically, we explored adding fake tracking headers to HTTP requests and seeing if the ISP routers would then not add their own tracking headers, thinking such were already accurately tagged. Following, user X might not be tracked or exposed, and we could poison the well of tracking and exposing users to sites. We also tried modifying and adding other headers (ie DNT) to see if such had any effect.
Unfortunately, we were initially unsuccessful in this hypothesis, as AT&T always added their own HTTP header, even when they saw our fake ones. We could re-open this effort in the future, but... as AT&T has claimed they will stop using the permacookie we decided to temporarily close the case and seek other attribution endeavors.
"Non-obvious" approach deep-dive:
We built a simple echo web page that outputted all headers for an incoming web request
We built a web page that itself made AJAX requests from one's local browser, via HTTP, to the above echo server
On the above page, there were 3 requests: one on page load, one via AJAX unaltered, and one AJAX with variations of AT&T's header added
The goal was to see if AT&T would not add it's own header if it saw an appropriately formed HTTP header already existing
To test, one need run the page above on their mobile device while not on WIFI
As noted above, this approach was unsuccessful in our quest to prevent the ISP router from adding a header attributed to us
We also observed that carriers ignored the Do Not Track (DNT) header when we included such
If we were successful in spoofing the header, we then planned to see if we could get different advertisements served to us, though we would have been required to locate a partner of AT&T that was consuming the header
Our quest to subvert carrier unencrypted HTTP request tagging via spoofing was unsuccessful. We seek to contribute to the public dialog by sharing our approach and results. We will update this post if we continue this research in the future.
