People aren't writing novels on their SmartPhones. The typed input from a normal volume of text messages, e-mails, and URLs is actually pretty minute when you think about it. Certainly it would be compressed before being uploaded to their servers. IIRC they cite 140 million active devices so if you figure 3kB per day, which is probably on the high side, that's only 400GB before compression. You can compress text down by about 90% these days. That works out to only 44GB of data uploaded per day.
Did you read any of the articles or watch the video?
The guy shows `adb logcat` running and showing CarrierIQ logging keystrokes with their ASCII codes.
(edit: I make no claims about the transmission of data. I merely took "collection" and assumed that if the app was recording (even if not persistently) keystrokes on my phone that it counted as collection. Further, the fact that it can is enough to piss me off, especially since it seems like makers of this type of software have piss-poor track records for their app security)
And, as been pointed out repeatedly in discussions about the "security" domain, when you add an ability, you inherently add a vector for that ability to be abused.
Even if "raw data" are not currently being uploaded, how thin is the line between this being turned off and it being turned on? And who is in control of that decision?
At an absolute minimum, the situation demands transparency.
As for me, I'm a step closer to being firmly in Stallman's camp.
Right, the argument is logged keystrokes never leave your phone because that amount of data from each Android/Blackberry phone would be a lot more thn 10 GB a day. I agree though, why are they logging it at all if the app isn't sending it to them? Very suspicious.
You, uh... you can enter 10 GB of text on your phone per day? I think maybe if you recorded all of the touch events, you'd end up with many megabytes worth, but I doubt the average user will enter more than a few kilobytes worth of text in a day.
I agree with you they will very easily record all the touch events. If you were typing 10 characters per second (which already seems like quite a lot) after 24h you will not even have a megabyte of information. Just over a megabyte if you encode the character in Unicode. ;-) This is without even take into account that this information can be heavily compressed for the transfert.
I read "that amount of data from each Android/Blackberry phone would be a lot more thn 10 GB a day." as "each device is generating over 10 GB a day." It makes more sense as a total, and really, 10 GB a day is NOTHING. In scientific computing, terabytes a day isn't too unusual, so it's certainly no big deal to store and process 10 GB a day.
When you can show me a tcpdump of your password being sent to CarrierIQ I will believe they are capturing your password.
All I've seen proof of so far is that it is capable of doing so because of how it is called before everything for anything, but let's not jump to conclusions here.
Neither drivebyacct2 nor the video claims the data is stored. Carrier IQ is collecting keystroke data, which you said they were not doing. The video clearly shows, when the user presses the "1" key:
where 49 is the keycode for the "1" key. This means the Carrier IQ code is called to collect and process this event information.
We just don't know what the code is doing with this information. Perhaps it is simply updating statistics and discarding it. So I guess your argument with drivebyacct2 is on the definition of "collecting"...
Logging to logcat does not mean it's sending those keystrokes anywhere on the internet. Logcat is the local system log and doesn't necessarily get sent anywhere but to a ring buffer on the device.
You're implying the difference is intent. I'm saying, their intent isn't known. Their own statement is that they don't want the raw characters, just the stats.
Meanwhile, there are plenty of pieces of code strewn throughout your system that get access to similar bits of sensitive data. For instance, every BSD system has a BPF device and driver that exists solely to tap your network traffic. Luckily, nobody sells a BPF-for-Android product.
I'm not saying that this is a clinching argument. I'm simply making a point that is germane to the discussion. Distilled, it is: "just because a piece of systems code deals with your private information does not make a violation of your privacy; sometimes it does, sometimes it doesn't".
Yeah, but key logging?
What could you possibly do with that data?
Besides, the BPF driver in every BSD system is probably open-source and could be reviewed for intent if in doubt. It's not easy, not everybody can do it, but it is possible.
However, you cannot do that for CarrierIQ. Even if such logs aren't getting sent, you don't know that they haven't installed some kind of mechanism to trigger such an upload on demand.
It's almost 2012 and "open source" doesn't matter that much anymore when it comes to stuff like this: there's enough incentive and basic competence now that someone's going to reverse engineer CarrierIQ, if only to get themselves some press.
To use a situation analogous to the situation with CarrierIQ, he did not have permission and you never even knew he was there or that the camera was there. However, the camera is digital, it is connected to your power outlet with a battery-backed UPS, and it has an active wireless modem attached to it.
Maybe he did send data, maybe he didn't. But he's also sent you a CnD notice and threatening to sue you if you tell anyone.
I am a bit lost at all the down votes but he was recording data that breaches privacy acts. If he did send such data without permission it is a rootkit and can be unlawful (data protection act, uk). Because everyone has collectively found out about this at the same time a CnD would not work.
From your link to the recruiter:
Each handset collects and reports 100's of metrics of device and user behavior in real time.
That's data like phone location, applications used, etc. Very bad yes, keylogger reporting your password, no.