Some Data on the Skype iPhone Application

SkypePhoneSkype is a polarizing product for telecom operators and customers. It is an application that lets customers abandon their historical phone services in favour of an encrypted Voice over Internet Protocol (VoIP) communications service that provides ‘free’ calls to computers and cheap rates when making a Skype-to-analogue/cellular phone service. For customers, it extends the choices presented to them and potentially reduces their monthly phone expenses.

The iPhone application for Skype has made headlines as telecom and smartphone manufacturers alike have actively and passively resisted, and ultimately relented, to permitting customers make Skype calls from their iPhones and other mobile devices. Apple has stated that they will not ‘jump through hoops’ to ensure that VoIP applications work through successive operating system updates, and AT&T’s poor data transmission systems likely made them somewhat hesitant to allow another bandwidth-heavy service onto their networks. What really got me interested in the Skype iPhone application, as a Canadian, was the following:

  1. Canadian customers can now install Skype on their iPhones;
  2. There was no place on the web that informed Skype users of how much data was consumed by the iPhone application when in use.

It was #2 that was particularly interesting. Canadian consumers tend to have fairly low default bandwidth caps with Rogers, the primary carrier of the iPhone in Canada, at 1GB in the basic iPhone plan. My thought was this: if the iPhone application actually consumed massive amounts of data Rogers would:

  1. Make a killing on the likely data overages as early adopters shifted over to Skype VoIP in favour of Rogers’ own voice services;
  2. If the application actually consumed a large amount of bandwidth, carriers might see it as ‘technically’ needing to be mediated using some system (perhaps deep packet inspection).

I started putting out feelers, and no one knew how much data the application consumed. Rogers claimed they didn’t know, nor did Apple. A contact on Twitter who worked as customer relations for Skype also doesn’t know the amount of data used, and the information was nowhere (that I could find) on the English-written web. Similarly, my international contacts were uncertain about data requirements. Fortunately, after an extended wait, I’ve finally received word from Skype’s customer service desks (my last ditch effort was to submit a support ticket). Here is how the relevant part of the email reads:

Continue reading

Analysis: ipoque, DPI, and Network Neutrality

netneutralityrallyottawaGerman Deep Packet Inspection (DPI) manufacturer, ipoque, has produced a white paper titled “Deep Packet Inspection: Technology, Applications & Network Neutrality.” In it, the company distinguishes between DPI as a technology and possible applications of the technology in a social environment. After this discussion they provide a differentiated ‘tiering’ of various bandwidth management impacts on network neutrality. In this post I offer a summary and comment of the white paper, and ultimately wonder whether or not there is an effective theoretical model, grounded in empirical study, to frame or characterize network neutrality advocates.

The first thing that ipoque does is try and deflate the typically heard ‘DPI analysis = opening a sealed envelop’ analogy, and argue that it is better to see packets as postcards, where DPI analysis involves looking for particular keywords or characters. In this analysis, because the technology cannot know of the meaning of what is being searched for, the DPI appliances cannot be said to violate one’s privacy given the technology’s lack of contextual awareness. I’ve made a similar kind of argument, that contextual meaning escapes DPI appliances (though along different lines) in a paper that I presented earlier this year titled “Moving Across the Internet: Code-Bodies, Code-Corpses, and Network Architecture,” though I think that its important to recognize a difference between a machine understandingsomething itself versus flagging particular words and symbols for a human operator to review. Ubiquitous, “non-aware,” machine surveillance can have very real effects where a human is alerted to communications – its something of a misnomer to say that privacy isn’t infringed simply because the machine doesn’t know what it’s doing. We ban and regulate all kinds of technologies because of what they can be used for rather than because the technology itself is inherently bad (e.g. wiretaps).
Continue reading

Beyond Fear and Deep Packet Inspection

securitybooksOver the past few days I’ve been able to attend to non-essential reading, which has given me the opportunity to start chewing through Bruce Schneier’s Beyond Fear. The book, in general, is an effort on Bruce’s part to get people thinking critically about security measures. It’s incredibly accessible and easy to read – I’d highly recommend it.

Early on in the text, Schneier provides a set of questions that ought to be asked before deploying a security system. I want to very briefly think through those questions as they relate to Deep Packet Inspection (DPI) in Canada to begin narrowing a security-derived understanding of the technology in Canada. My hope is that through critically engaging with this technology that a model to capture concerns and worries can start to emerge.

Question 1: What assets are you trying to protect?

  • Network infrastructure from being overwhelmed by data traffic.

Question 2: What are the risks to these assets?

  • Synchronous bandwidth-heavy applications running 24/7 that generate congestion and thus broadly degrade consumer experiences.

Question 3: How well does security mitigate those risks?

Continue reading

Talking About Deep Packet Inspection Tomorrow

chekokoI’ll be chatting with Chris Cook tomorrow between 5:00-5:20 or so about deep packet inspection, network neutrality, and the Canadian situation. This will be the second time that I’ve had the opportunity to talk with Chris, and it’s always a pleasure.  Hit Gorilla Radio’s posting for more information.

I’d just like to publicly thank the University of Victoria’s Communications department for their assistance these past few weeks. They’ve been wonderful in letting various media outlets around the country know about my research, which has let me disclose my research more widely then normal. UVic’s level of support to their graduate students is absolutely amazing – I’d highly recommend that any graduate student interested in a Canadian institution take a look at their offerings. UVic rocks!

Deep Packet Inspection: What Innovation Will ISPs Encourage?

InnovationAll sorts of nasty things as said about ISPs that use Deep Packet Inspection (DPI). ISPs aren’t investing enough in their networks, they just want to punish early adopters of new technologies, they’re looking to deepen their regulatory powers capacities, or they want to track what their customers do online. ISPs, in turn, tend to insist that P2P applications are causing undue network congestion, and DPI is the only measure presently available to them to alleviate such congestion.

At the moment, the constant focus on P2P over the past few years has resulted in various ‘solutions’ including the development of P4P and the shift to UDP. Unfortunately, the cat and mouse game between groups representing record labels, ISPs (to a limited extent), and end-users has led to conflict that has ensured that most of the time and money is being put into ‘offensive’ and ‘defensive’ technologies and tactics online rather than more extensively into bandwidth-limiting technologies. Offensive technologies include those that enable mass analysis of data- and protocol-types to try and stop or delay particular modes of data sharing. While DPI can be factored into this set of technologies, a multitude of network technologies can just as easily fit into this category. ‘Defensive’ technologies include port randomizers, superior encryption and anonymity techniques, and other techniques that are primarily designed to evade particular analyses of network activity.

I should state up front that I don’t want to make myself out to be a technological determinist; neither ‘offensive’ or ‘defensive’ technologies are in a necessary causal relationship with one another. Many of the ‘offensive’ technologies could have been developed in light of increasingly nuanced viral attacks and spam barrages, to say nothing of the heightening complexity of intrusion attacks and pressures from the copyright lobbies. Similarly, encryption and anonymity technologies would have continued to develop, given that in many nations it is impossible to trust local ISPs or governments.

Continue reading

Deep Packet Inspection and the Discourses of Censorship and Regulation

boredomIn the current CRTC hearings over Canadian ISPs’ use of Deep Packet Inspection (DPI) to manage bandwidth, I see two ‘win situations’ for the dominant carriers:

  1. They can continue to throttle ‘problem’ applications in the future;
  2. The CRTC decides to leave the wireless market alone right now.

I want to talk about the effects of throttling problem applications, and how people talking about DPI should focus on the negative consequences of regulation (something that is, admittedly, often done). In thinking about this, however, I want to first attend to the issues of censorship models to render transparent the difficulties in relying on censorship-based arguments to oppose uses of DPI. Following this, I’ll consider some of the effects of regulating access to content through protocol throttling. The aim is to suggest that individuals and groups who are opposed to the throttling of particular application-protocols should focus on the effects of regulation, given that it is a more productive space of analysis and argumentation, instead of focusing on DPI as an instrument for censorship.

Let’s first touch on the language of censorship itself. We typically understand this action in terms of a juridico-discursive model, or a model that relies on rules to permit or negate discourse. There are three common elements to this model-type:

Continue reading