One of the largest network vendors in the world is planning to offer their ISP partners an opportunity to modify HTTP headers to get ISPs into the advertising racket. Juniper Networks, which sells routers to ISPs, is partnering with Feeva, an advertising solutions company, to modify data packets’ header information so that the packets will include geographic information. These modified packets will be transmitted to any and all websites that the customer visits, and will see individuals receive targeted advertisements according to their geographical location. Effectively, Juniper’s proposal may see ISPs leverage their existing customer service information to modify customers’ data traffic for the purposes of enhancing the geographic relevance of online advertising. This poses an extreme danger to citizens’ locational and communicative privacy.
Should ISPs adopt Juniper’s add-on, we will be witnessing yet another instance of repugnant ‘innovation’ that ISPs are regularly demonstrating in their efforts to enhance their revenue streams. We have already seen them forcibly redirect customers’ DNS requests to ad-laden pages, provide (ineffective) ‘anti-infringement’ software to shield citizens from threats posed by three-strikes laws, and alter the payload content of data packets for advertising. After touching the payload – and oftentimes being burned by regulators – it seems as though the header is the next point of the packet that is to be modified in the sole interest of the ISPs and to the detriment of customers’ privacy.
I recently had an article published through CTheory, one of the world’s leading journals of theory, technology, and culture. The article is titled “Moving Across the Internet: Code-Bodies, Code-Corpses, and Network Architecture.” The article emerged from a presentation I gave at last year’s Critical Digital Studies Workshop that was titled “Moving Online: Your Packets, Your ISP, Your Identity.”
Across the Internet, an arms race between agents supporting and opposing network-based surveillance techniques has quietly unfolded over the past two decades. Whereas the 1990s might be characterized as hosting the first round of the encryption wars, this paper focuses on the contemporary battlescape. Specifically, I consider how ISPs “secure” and “manage” their digital networks using contemporary DPI appliances and the ramifications that these appliances may have on the development, and our understanding, of the code-body. DPI networking appliances operate as surveillance devices that render the digital subject constituted by data packets bare to heuristic analyses, but, despite the ingenuity of these devices, some encryption techniques successfully harden otherwise soft digital flesh and render it opaque. Drawing on Kant and Derrida, I suggest that ISPs’ understanding of the Internet as one of packets arguably corresponds with a Kantian notion of reality-as-such and offers a limited and problematic conception of the code-body. Turning to Derrida, we move beyond protocol alone to consider the specters that are always before, and always after, the code-body; Derrida provides a way of thinking beyond Kantian conceptions of space and time and the reality-as-such code-body and lets us consider the holistic identity of the code-being. Further, Derrida lets us interrogate the nature of DPI networking appliances and see that they resemble thrashing zombie-like code-corpses that always try, but perpetually fail, to become fully self-animated. While Derridean insights suggest that ISPs are unlikely to be successful in wholly understanding or shaping code-bodies, these corporate juggernauts do incite identity transformations that are inculcated in cauldrons of risk and fear. Not even Derridean specters can prevent the rending of digital flesh or act as a total antidote to ISPs’ shaping of consumers’ packet-based bodily identity.
Link to article.
Google Street View has come under fire again, this time for collecting wireless router information and some packets of data whilst wandering the globe and collecting pictures of our streets. It looks like the German authorities, in particular, may come down hard of Google though I’m at odds about the ‘calibre’ of the privacy violation – router information is fair game as far as I’m concerned, though data packets are a little dicier. But before I dig into that, let me outline what’s actually gone on.
Last Friday, Google announced that they had been inadvertently collecting some data packets sent via unencrypted wireless access points for the past three years. This admission came after the Street View program (again) came under criticism from German data protection authorities following Google’s (original, and earlier) admission that they had only been collecting information about wireless routers as they drove their cars around towns. Specifically, the original admission saw Google reveal they had collected the SSID and MAC addresses of routers. In layman’s terms, the SSID is the name of the wireless network that is usually given to the device during configuration processes following the installation of the device (e.g. Apartment 312, Pablo14, or any of the other names that are shown when you scan for wireless networks from your computer). The MAC address a unique number that is associated with each piece of Internet networking equipment; your wireless card in your computer, your LAN card, your router, and your iPhone all have unique numbers. After collecting both the SSID and MAC address of a wireless router the company identified the physical location of the device using a GPS system.
Google collects information about wireless networks and (almost more importantly) their physical location to provide a wifi-based geolocation system. Once they know where wireless routers are, and plot them on a map, you don’t need GPS to plan and trace a route through a city because a wireless card and low-powered computer will suffice. There are claims that this constitutes a privacy infringement, insofar as the correlation of SSID, MAC address, and physical location of the router constitute personal information. I’m not sure that I agree with this, as the Google service stands now.