In association with heise online

08 April 2008, 15:41

Mechanism of Phorm tracking system revealed

  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

The way in which the Phorm advert serving system tracks users has so far been the subject of much speculation. Now, Richard Clayton of the University of Cambridge Computer Laboratory has published a white paper describing various mechanisms used by the system.

According to the paper, which has been reviewed for accuracy by Phorm, all HTTP requests on port 80 passing through the ISP are presented to a Layer 7 switch, and most of them are passed to the Phorm system. If the GET request from the user's browser does not contain a Phorm ( cookie, it is "307" redirected by the Phorm system to a local system masquerading as, and a cookie is set containing a unique User ID (UID). This request is further redirected to a system that impersonates the domain in the user's original GET request and a new cookie is set in the requested domain but containing the name. Significantly, Clayton states that this is not a conventional "third party" cookie, but a "labelled" first party cookie, so to block it, cookies would have to be disabled for the requested domain rather than the domain. Once set in the user's browser, the cookie is stripped as the request passes back through the Layer 7 switch to the original requested domain. Clayton points out that further requests to the desired domain "… will automatically contain the webwise cookie, and so there will be no need to redirect any of these".

One outcome of this is that port 80 HTTP GET requests only reach their desired destination after having been redirected three times by the Phorm system. None of these manipulations directly contribute to the fulfillment of the requested transaction, but they must necessarily increase latency and reduce robustness to some extent, quite apart from any privacy issues associated with deep packet inspection of the transaction.

Nevertheless, privacy still takes centre stage. Although official opt-out systems are ISP-dependent and have not yet been clearly explained either by Phorm or the participating ISPs, there are apparently some controls the user can implement locally. None of these are guaranteed to completely defeat the system, but they can make tracking by Phorm less intrusive, albeit in some cases with side effects on the browsing experience. The conventional opt-out, however it is implemented in detail by the individual ISP, relies on a cookie in the domain, which supposedly offers a "per user" opt-out. On the other hand, blocking cookies from the domain causes the system to issue a new randomly generated UID for each domain visited, making profiling across web sites impossible. At some unspecified point this situation is detected by the Layer 7 switch and the user's IP address is blacklisted, preventing further redirection. The blacklisting apparently times out eventually, but while it is active it essentially thwarts the profiling capacity of the Phorm system for that IP address. However, as the blacklisting is "per IP address", multi-user systems can not effectively block Phorm tracking on a per user basis. Blocking cookies for the requested target domain potentially causes the system to enter an infinite loop of redirect requests. The Layer 7 switch apparently detects this situation and prevents further redirection of traffic from the source IP address. However, many web sites require cookies, so this approach to Phorm blocking has severe limitations.

Another local configuration option seems to be to change the User Agent String (UAS) of the browser. Phorm apparently uses this to distinguish web traffic from other HTTP traffic so it can ignore the latter. A white list is held of "well-known" UASs for popular browsers. If the UAS of the browser is changed to something that does not appear on this list, HTTP requests from the browser will be ignored. However, there are potential side effects of changing the UAS. Some web sites rely on them to select appropriate content for different browsers and systems, so pages might misformat or software updates might be incorrectly distributed if the UAS is changed.

From the legal perspective, which is the only global restraint likely to have effect, the situation remains unclear. Although it has been stated that it is impossible to associate UIDs with IP addresses or personal details and that "sensitive" web transactions such as with medical sites will be excluded from profiling, there is no warranty that these decisions might not be reversed in the future. A system exists within the ISPs infrastructure that deep packet inspects all web traffic and at that point the IP address is known. Regardless of what is subsequently done with the data obtained, at that point the user is completely exposed. On the Lightbluetouchpaper blog, Clayton sums up "A number of very well-informed people … have suggested that …" the redirect and cookie spoofing "… may be illegal under the Fraud Act 2006 and/or the Computer Misuse Act 1990 … Overall, I learnt nothing about the Phorm system that caused me to change my view that the system performs illegal interception as defined by s1 of the Regulation of Investigatory Powers Act 2000". Furthermore, it is open to question whether the "mere conduit" immunity of ISPs can remain effective once they or third parties with their connivance deep packet inspect their customers' traffic without the customers' explicit and uncoerced consent. This has global liability implications which the participating ISPs seem to have ignored so far.


Print Version | Send by email | Permalink:

  • July's Community Calendar

The H Open

The H Security

The H Developer

The H Internet Toolkit