I’ve written a fair bit about mobile phones; they’re considerable conveniences that are accompanied by serious security, privacy, and technical deficiencies. Perhaps unsurprisingly, Apple’s iPhone has received a considerable amount of criticism in the press and by industry because of the Apple aura of producing ‘excellent’ products combined with the general popularity of their mobile device lines.

In this short post I want to revisit two issues I’ve previously written about: the volume of information that the iPhone emits when attached to WiFi networks and its contribution to carriers’ wireless network congestion. The first issue is meant to further document here, for my readers and my own projects, just how much information the iPhone makes available to third-parties. The second, however, reveals that a technical solution resolves the underlying cause of wireless congestion associated with Apple products. Thus, trapping customers into bucket-based data plans in response to congestion primarily served financial bottom lines instead of customers’ interests. This instance of leveraging an inefficient (economic) solution to a technical problem might, then, function as a good example of the difference between ‘reasonable technical management’ that is composed of technical and business goals versus the management of just the network infrastructure itself.

How Loud is Your iPhone?

I recently covered a technical paper on security vulnerabilities in the iOS architecture that examines how application developers can capture an iPhone’s unique identifier to both track the actions taken on a phone and correlate those actions with a particular user. To accomplish either of these consentless data collections, developers must make a few specialized API calls. Thus, while the iPhone makes the information available it doesn’t default to broadcasting it to the world at large; some degree of intentionality is required for application developers to access the information.

When sending data over a network a certain a degree of trust in the network and its administrator is required, and this is especially true when attaching iDevices to a network. Unlike many WiFi appliances and computers, Apple’s mobile consumer line defaults to associating a computer’s user account name with the class of mobile device. For example, when you first connect an iPhone to an Apple computer the device takes a name format of ‘Account User Name’s iPhone’; in my own case, this saw my iPhone named Christopher Parsons’ iPhone. Per Robert Graham over at Errata Security:

This name appears in many places. The first thing your phone needs is a network address, which it gets from the WiFi access-point via something called “DHCP”. The owner of the access-point can pull up the “DHCP Table” at any point in order to see who is connected. They will see your iPhone in that list.

Apple also sends out your name in what’s called “mDNS” packets every couple of minutes. Even though DHCP only makes your name visible at the start of the connection, mDNS will notify everyone on the local network every few minutes thereafter.

This effectively lets a network administrator – or any individual running packet sniffing applications to grab unencrypted data packets out of the air – correlate data traffic not only with particular devices (which is normal with all devices connected to a wireless network) but potentially with the actual individual. This latter correlation, of course, does depend on matching a face and a name, but with the prevalence of photo tagging and social media use more generally, there are good chances that a quick Google search of your name associated with key search terms will turn up your face.

In light of administrators’ abilities to closely identify who is using particular devices, Graham recommends modifying the name associated with the device or getting rid of the ‘iPhone/iPad/iPod Touch’ moniker. Of course, this assumes that the administrator is only examining the mDNS packets and not digging deeper into your unencrypted traffic. If they are digging deeper then renaming the device is insufficient; encryption and obfuscation practices would need to be adopted instead.

Where and why is this significant? If your employer has a ‘no iDevice’ policy at work then you need to think twice before connecting your Apple product to the corporate network. It is incredibly hard to mask that you are using an iPhone or other WiFi-enabled iDevice; the MAC Address and user-agent associated with the browser, along with the actual name of the device, give Apple’s products away very quickly. Encrypting and obfuscating traffic may work, but success is likely dependent on the technologies being used to monitor network traffic. It’s likely that the best way ‘around’ any such policy, then, is to use a 3G enabled device and forgo the corporate WiFi network entirely.

iPhone Gets Quieter at the Tower

Earlier this year I wrote that Apple’s breaking of the 3GPP protocol on the iPhone was the likely cause of many tower congestion problems. Because iOS violated 3GPP it more regularly signalled to AT&T’s towers than smart phones that met the protocol. It was the iPhone’s signalling promiscuity, rather than actual consumer data usage, that was primarily responsible for wireless networks’ woes. Rather than calling out Apple for poor protocol implementation, Apple and AT&T both publicly asserted that the problems were on AT&T’s end. Similar assertions are common internationally amongst wireless carriers selling the iPhone, and this rhetoric generally drives wireless providers’ arguments that wireless bandwidth is already in limited supply. Because of these ‘limits’, high-priced data buckets, throttling, and zealous ‘network management’ is being forced on mobile users.

Nokia Siemens Networks published results of their iOS 4.2 tests  late last month and noted that the newest version of Apple’s iOS corrects the oversignalling problem. Rather than switching between an active and inactive state, iOS devices can take advantage of an intermediate state which lets smart phones wake up quickly when they need to send/receive data while simultaneously reducing the devices’ number of signalling attempts. NSN, in its non-iPhone tests, found that introducing intermediate signalling behaviour results in longer battery life, with devices achieving an 11 hour battery life with the intermediate rest stage as opposed to 6 hour lifespans on the identical devices using active/passive signalling technologies.

What are the impacts of the update for iOS users then? Positively, they can expect longer battery life and more rapid data transit speeds. As an iPhone user myself that uses iOS 4.2 I can confirm that battery life is better than it was with prior operating systems. I haven’t detected a noticeable change in the rapidity of data transit in my daily uses.

Negatively, however, we’re unlikely to see a reversal of the rhetoric that smart phones are the bane of wireless infrastructures. AT&T’s network failures – a combination of infrastructural deficiencies and bad iOS signalling code – are unlikely to be massively ascribed to Apple now that the problem is fixed. Instead, AT&T will continue to support strawman arguments about why ‘all you can eat’ data plans are dangerous to offer, regardless of whether customers want them or not. Data plans will continue to increase in cost, despite decreasing delivery and network infrastructure expenses as mobile devices are updated to correct bad signalling behaviours, more efficiently compress data, and make better use of available spectrum.

Perhaps the most important part of this, however, is that code alone could resolve the fiasco around iOS signalling habits. The economic responses that AT&T and other wireless providers pushed onto their customers were exercises in testing the costs that the market would bear for wireless data, though this ‘test’ demanded first tricking customers about the market’s actual conditions. AT&T and other providers could have gone after smartphone developers – publicly extolling them to improve their signalling techniques, publicly criticizing developers’ lackadaisical response to the problem – but instead we witnessed an (effective) attempt to raise prices instead. This (again) reveals that wireless companies would rather artificially construct perceptions of data scarcity than focus on resolving the problems experienced by smartphone customers in a transparent, honest, and genuine manner. It also underscores Ohm’s point that ‘reasonable network management’ often incorporates financial motives at the expense of ‘pure’ technical solutions to managing the network.

If engineers alone were responsible for addressing Apple devices’ bad signalling behaviour, I doubt we would have seen a several year gap between the introduction of the iPhone and iOS and the correction of a significant problem it caused to wireless networks. Perhaps this constitutes another reason for instituting a neutral third-party to watch over how ISPs and wireless companies alike govern their networks!