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.
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.
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)
What if the program just collects the aggregate metrics, sends them and then deletes the actual keystrokes?
Not saying it doesn't send keystrokes, but the video is definitely not proof of that and it bears further investigation, not knee jerk reactions.
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.
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".
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.
Second, maybe they are selling the information to other parties by letting the other parties grab the information themselves.
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.
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.
They're obviously doing bad stuff, but I see no evidence of uploading your keystrokes
com.htc.android.iqagent.action.ui01
actionUI01:49,0
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"...