Last Wednesday, I highlighted recent hubub around a piece of mobile phone metrics collection "spyware" called Carrier IQ. Since then, there have been some significant happenings. Largely because, after the EFF's involvement and Carrier IQ's decision to cease legal threats, researcher Trevor Eckhart provided more explicit documentation [note: the site has been crashing occasionally due to extraordinarily heavy traffic] of how the Carrier IQ software has been implemented on his HTC Evo 3d (Sprint). With Video.

What the software appears to be doing in this case looks pretty bad. And it is, no doubt.

Between the Conde Nast highlight last week, Carrier IQ retracting the legal threats with a 4:35 Thanksgiving-eve news-dump (brilliant PR that, BTW), followed by this video/analysis ...  if this were politics (and, actually, it is) we would say this has grown some legs. And as things with legs do, the story has already run off the rails somewhat. A prime example is an article by Andy Greenberg in Forbes which, despite serious questions raised by the situation, dips into being irresponsible.

A piece of keystroke-sniffing software called Carrier IQ has been embedded so deeply in millions of Nokia, Android, and RIM devices that it’s tough to spot and nearly impossible to remove [..] Paul Ohm, a former Justice Department prosecutor and law professor at the University of Colorado Law School. He thinks it’s also likely grounds for a class action lawsuit based on a federal wiretapping law.

“If CarrierIQ has gotten the handset manufactures to install secret software that records keystrokes intended for text messaging and the Internet and are sending some of that information back somewhere, this is very likely a federal wiretap.”

[...] Carrier IQ captures every keystroke on a device as well as location and other data, and potentially makes that data available to Carrier IQ’s customers. The video he’s created shows every keystroke being sent to the highly-obscured application on the phone before a call, text message, or Internet data packet is ever communicated beyond the phone.

A few things are simply wrong about this article. The wrongness boils down to two general issues: one of likely blame and one of ensuring accurate allegations based on facts in evidence. Based on the information we have it seems the characterization of the software relies on several mistaken premises and could very well be leveling unwarranted charges at CarrierIQ for actions taken and customizations by clients which were completely beyond the company's control. Fundamentally, Greenberg misses what appears to be the nature of the Carrier IQ software/API and also seems unclear on the way Android works. As such, Paul Ohm is not really being given information that is accurate or complete enough to make a very informed analysis.

What Carrier IQ appears to sell is a framework/codebase/API and a suite of utilities for collecting and processing related data. The training materials showed three distinct aspects to the system: (1) app on the device, (2) server that collects data, and (3) "portal" software to interact with the server for reporting and analysis. This is not an application as the typical consumer purchases it. The "stock" Carrier IQ software (described in the last post) is almost certainly provided to the device creators along with source code. Typically, developers use this sort of example code as a demonstration how the major aspects of the API can be implemented; a starting point used to create a custom-tailored implementation for any device. It would be expected to interact correctly with the other two pieces of the system to allow a smooth demonstration of basic capabilities. The fact that there is no known commercial device using the "stock" implementation supports this assessment.

It is almost certain implementation at the device level is developed and customized by the carrier/hardware developer - with features created/activated based on their unique needs by their in-house development team. In the case of the Evo 3D used for the video, this means that HTC, Sprint or both had an opportunity to make significant changes to the Carrier IQ codebase as it is implemented in the device. It is also known that the "portal" software is implemented by the carrier/device manufacturer and appears to simply display and sort records in the compliant format. Data collection appears to be largely or exclusively under the control of the end client as well; superficially, hosting a database which could reside anywhere would seem to be a neutral platform service if provided by Carrier IQ.

I can think of PLENTY of ways Carrier IQ could be in it up to their eyeballs. But it is important to point out, there isn't evidence for any of them yet. Based on the facts thus far known,  In the even that something about Evo's implementation turns out illegal, Carrier IQ is probably positioned as least likely to be responsible. The way this article presents things, it sounds like Carrier IQ somehow tricked hapless carriers and manufacturers into installing spyware on their customer's phones. It seems clear that *if* an implementation behaves as spyware, the device maker defined it's behavior.

A hammer is an undisputed tool until someone bashes a head in with it. I'm not willing to immediately condemn the hammer maker (speaking as a toolmaker myself).

Beyond accusing the potentially wrong party, the technical description of what is being shown in the video is not exactly right. The "captured" information shown in the video is what I call console spam - text that devs put in to track various aspects of their software - that gets spit out on a debugging screen called "the console" as the app is running. When the phone has a bunch of stuff running any of them can be printing to the console at the same time.

Just because something doesn't pop up there doesn't mean that an app somewhere did not see an event (intent) and respond to it. In fact, most other Carrier IQ implementations seem to avoid console output. Similarly, seeing a report in the console of an event triggering an app doesn't necessarily provide specific insight what was done when the trigger was received. The listener might store information, it might start recording from the voice stream, transmit stored information to a server,  increment a counter or simply do nothing. That is showing what the system *can* respond to.

In Android, the limit on what an app *can* do is defined by it's security permissions. And in this respect, regardless if it reports what is done to the console, the application can literally access, record or manipulate every significant aspect of the cell phone ... and if it wants to, quietly implement a routine that responds to any phone event. Technically, several packages that are a part of a device's core have equal access to the deepest levels of the phone. It is the storage and reporting aspects of this that make it troubling, not necessarily that a piece of software created and installed by the device manufacturer is root-level integrated into the OS.

While many people will be caught up on the demonstration showing how the software could access a text message's body, the most concerning thing shown was the demonstration of how it captures web requests. The video did NOT show something happening "before every data packet is sent to the internet" (wrong on so many levels). What it showed was information that is supposed to be immediately encrypted (by webkit?) instead echoed in plaintext to the console. Inside the phone, the "console" is stored in a file called "logcat". This means that even if the information being passed between executing apps was ignored or only kept in a temporary memory variable for some purpose, a plain-text record of the information is stored on the phone in a low-security file ... which appears to finds a consistent exit route from the phone through Google's own voracious private information hoovering ways.

Google Checkin is the service responsible for “checking in” to google with data in /data/system/dropbox. Crash dumps, lastkmesg, dmesg, full logcat dumps are in here. On google checkin (open up market, sync gmail, login to a google service) this data is synced.

As such, we have to assume that anyone using the Evo 3d (at least) who has accessed an https service that utilizes sensitive plaintext requests under the expectation data would be encrypted now likely have that sensitive information stored on Google's server somewhere if indeed Google is archiving logcats.

This really does kind of look like a mess. My bet is whoever controls the CarrierIQ portal for those phones (Sprint, I'm looking at you) will deploy a whole new metrics package to these devices in the next few days. A less bouncy one ... or at least one that doesn't report what it's doing to the console.

There are a million solid and important questions that need to be raised here. And there very well could be cause for a lawsuit or three before all is said and done. But let's figure out what exactly has happened and who did it ... then level informed accusations at the correct party.

[originally posted at kgblogz ... edited slightly for context.]