This article is more than 1 year old
Carrier IQ VP: App on millions of phones not a privacy risk
Like tiny fish through a net, key taps dropped from memory
Carrier IQ speaks
The Register: Explain what's happening in the video. It does appear that the exact sequence of key taps is monitored or logged.
Coward: Those are two different things. The sequence of keys pressed, the sequence of things that happen on a device, gets passed to the software, and we are passing that through a fine filter to figure out what's needed and what needs to be captured and turned into the analytics. This is incredibly nuanced. To our world, there's a vast difference between seeing activity on a device and taking that information and straight copying, verses doing things that are important for the function of the analytics we need to gather.
We're not collecting data on our own behalf, and that's really important. The data that's being gathered is commissioned by the operators to be gathered. It's under their control, albeit sometimes in our data center, sometimes in their data center. We have no rights to that data.
You certainly have the potential to see the precise sequence of key taps and you do have the potential to see each message sent, the phone numbers somebody dials, the location where they're typing, but you are choosing not to log it?
Correct, and to prove that's the case, we've brought in security consultants to take a look at our code and take a look at what we're doing and validate it.
One of the problems I had with what you said in the past was you said, we can't do it. I had a tough time reconciling your statement that we can't do it with a YouTube video showing a debugger being plugged in and exactly that thing happening. We can't and we don't are two entirely different things.
My point is that the software was never designed to gather and transmit that text. It was designed to filter all the information that comes through. We can't gather that information because the software isn't written that way. That's the point really, that to gather the analytics this information is constantly pumping through your phone, and tapping into that cycle is a function of what you code and what you're looking for. We're putting a huge filter on that to reduce what we're seeing to the essence of what's needed by our customers to solve the problems they have.
If we're looking at a debugger that is monitoring what goes into Carrier IQ and it is showing the precise sequences of key presses, how is it that the software isn't designed to capture the precise sequences of key presses? I'm still having a tough time reconciling what I see in the YouTube video with what you say.
What we're doing is looking at this vast stream of information that’s coming in and we're filtering it to populate specific analytics that get transmitted back. Some of that information has been described as somewhat sensitive. If you have a dropped call, what was your location and so on.
In seeing all this information come through, the software does not have the ability, because of the way it's written, to say I need to capture your SMS message and transmit it up. What we want to know is how many SMS messages were sent and did it succeed or did it fail.
So the question is why are we even seeing some of this content? Why is it important to us? For example, why bother looking at SMS traffic if you're not going to actually capture the content that sits inside it? And there are very specific reasons.
With the SMS one, there are control messages that come to us through SMS. So the back end system, for example, wants your device to check in or deliver an upload of the latest information, it has the ability to send an SMS message to a device to say please upload this information now. So we look at SMS messages that come in, and SMS messages that come in and are tagged with our details we will look at and say OK, this one is for us, let's process it and follow the actions inside of it.
In other words, a phone with Carrier IQ on it may receive an SMS that has formatting in it that calls some sort of an API?
The metaphor that's coming to mind is you're a fisher with a big net and you're catching everything that's out there and then you're quickly deciding we're going to throw this out, we're going to throw this out, we're going to keep this. The concern that we're having is we're seeing you guys catch all this stuff and we're not necessarily seeing you throw everything out.
I like the fishing analogy. It's a good one. To answer your point, we're on a fishing boat out at sea and we're catching fish that are too small and they go back in, and they go back in for two reasons. One, the holes in the net don't catch small fish, i.e. the filtering and/or the fish is the wrong type and it gets thrown out of the boat, hopefully while it's still alive.
And to extend this back to Carrier IQ you throw it out before anyone has seen it or before this information has been divulged to anyone?
What's the reason for monitoring outgoing key taps, key taps that are typed into a Google search, for instance?
There are a sequence of key codes that can be typed by the user that cause the software to do things in the control center. For example, you can be on the phone with support and they'll say key dial this number and that will cause an upload to take place at that particular point in time.
It seems there must be some sort of buffer of received text messages, or a cache. Am I right?
We receive this information in real time, so a text message comes in, we'll look at it. Is it for us? No, discard. So within the software itself there's this kind of fast process. We shouldn't need to buffer this information.
You shouldn't need to? Does that mean you categorically don't do it?
I haven't had that question before. I can't think of a reason why we'd need to buffer it. Because we're operating in real time, we'll see the SMS come in. Is it for us? Yes, OK, let's deal with it. If not, discard. Just like letting the small fish go through the net, the same analogy applies.
Does that mean SMS messages are never logged?
The content of SMS messages are never logged. There are two things that happen when SMS messages are received. One is, obviously, we count them, the ones that succeed, the ones that fail. We do also record the telephone numbers the SMSs are from and to. So for example, if you send and SMS to me and it fails, you want to be able to work out did it not leave your phone, was it a communication problem with the tower, did it somehow not get to me in the last mile. This is a two-way conversation. You need the know both ends of the chain to understand.
The content of the SMS is never stored and never transmitted.
And who has custody of that information?
As with all the information, the information is not controlled by us. It's controlled by the operator. We have no rights to that data.
So what information gets gathered?
We have profiles and the profiles are designed by the operator, and that actually defines what is or is not gathered. We have customers who just collect failed calls with an upload that takes place once a week. We have others . . . where they get an upload once a day that will contain information about what applications you've been using.
How much data on the average phone running Carrier IQ is actually transmitted in a day, a week or a month?
This is a really important point because obviously the more that you take off a device the more processing power you'd need. If we were doing everything that was claimed, we'd be outstripping Google for requirements of architecture.
The typical upload in for customer care information is about 200KB. That's about 200 times 1024 characters.
That's still a fair amount of information.
One of the reasons for that is there's a huge amount of radio information that gets transmitted. The radio conditions around the call are actually the kind of gold for the operator. Meaning what were the messages that were going between the handset and the tower at the time that caused the call to drop? There's a lot of detail in that radio to handset communication that gets captured.
So that would be part of the 200 KB