backtop


Print 31 comment(s) - last by flash2011.. on Dec 13 at 12:54 AM

Code sloppily, pay the price; or as a source puts it "It really appears like Carrier IQ got screwed by HTC."

Cautionary lesson to programmers: code sloppily and it may cost your business dearly.  

One line of code, presumably authored by HTC Corp. (TPE:2498) appears to have been the spark that ignited a wave of press and public hysteria regarding smartphone privacy invasions and a world of woes for HTC, a small telemetry company called Carrier IQ, and Carrier IQ's numerous industry partners.

(Ed./Update V2-  Based on a bit more research, I added theory on the potential of a reference design from Carrier IQ, a case that would send some of the blame back to Carrier IQ (though HTC appears to be the primary negligent party in this one-line botch job.)

I. The Panic

Customers are already queasy about data mining, regardless of whether it is for the purpose of improving products or for financial gain.  While there's always the assurance of anonymity, customers fear -- and perhaps justifiably so -- that their private data could be exposed or maliciously exploited by data miners.

On the surface it appeared that those worst fears were confirmed over the course of the past couple months, when it was found that telemetry firm Carrier IQ appeared to be printing a host of private data to the debug stream in Android, accessible by other apps.  Media jumped to the conclusion that ALL Carrier IQ apps must be doing the same, and the hunt was on for Carrier IQ on various smartphones.  

The search yielded results.  Carrier IQ was found on Android, on the iPhone, and more.  Meanwhile media and members of the public jumped to more and more wild conclusions.  As one reader wrote in my previous post on Carrier IQ:
They are reading every key press, that is an epic fail. It is beyond a significant security/privacy issue...

The only problem is that nobody bothered to dig into the actual code and see if that claim was right.  Or almost nobody.

I started decompiling the pieces of Carrier IQ last week, and while my analysis of the three programs...

/system/bin/iqfd
/system/bin/iqd
com.htc.android.iqagent

... off a newly rooted EVO 4G device I have access to is ongoing, the early results indicate that another member of the security community who also went to the trouble of actually bothering to look at the code -- Dan Rosenberg -- was correct in stating that there's no evidence that Carrier IQ is exposing customers' private information to malicious third parties.

II. The Breach

But what about the debug stream information?  That's a huge security flaw [PDF] in its own right, correct?

Of course it is, but it's important not overblow the security risk here.  Here's the compromise scenario:
  1. IF you install an app with debug permission android.permission.READ_LOGS in its AndroidManifest.xml ...
  2. AND IF you run that app...
  3. AND IF it's malicious...
  4. AND IF it or some other installed app from the same malicious party, which is also installed and running have network permissions ( android.permission.INTERNET)....
Then yes, absolutely your private data (specifically GPS position, SMS text contents, URLs, including uncensored HTTPS strings, and numbers dialed) could be captured, packaged, and sent out to a malicious third party.  Again, let's consider the worse case scenario if this happens:
  1. IF you use an https encrypted website (there's no keylogging outside the dialer app so apps are safe...)...
  2. AND IF that site doesn't properly censor your username and/or password in its string after the base domain in the https URL...
  3. AND IF all of the above (debug app, internet permission, malicious) is true, you could lose your username and/or password to a malicious party.
Again it's easy to overstate the risk, but any data loss is unacceptable, so let's for now consider this an atrocious security breach, even if it only affects a handful of customers out of millions of subscribers.

III. The Blame

So who's to blame?

Dan Rosenberg argued that "com.htc.android.iqagent" was the sole work of HTC, and that it was the app to blame for egregious data prints, but that Carrier IQ's core apps (iqd and iqfd) didn't log any of this information, and didn't even pass along all the things the HTC app was printed (i.e. it did pass along URLs, but didn't pass along text message contents, etc.).

Anyhow the important point Mr. Rosenberg raised is that the exposure of this data to malicious third parties via the debug stream was the (accidental) work of HTC -- NOT Carier IQ.  

And while I was unable to confirm definitively that Carrier IQ was indeed solely authored by HTC, the nature of data flow, the code itself, and even the title seemingly suggests that HTC is the primary author of this code.  And those egregious prints?  

Ed. - I added this thought upon further examination of anothe CIQ code...
Of course this code looks an awful lot like a reference design from Carrier IQ, given its similarities to code seen elsewhere on Samsung Electronics Comp., Ltd.'s (KS:005930) devices.  If this is the case the blame becomes a bit more complicated --  Carrier IQ may have had the debug statement turned on in the reference design it may have been given by Carrier IQ, but it clearly modified the code and was responsible for the finished product.  Why didn't it have the common sense to turn off the debug flag?

They all come down to one fateful line:

protected boolean DBG = true;

(found near the top of com.htc.android.iqagent (class AgentService)

Which rears its ugly head in this conditional:

public void handleMessage(Message paramMessage)
    {
      super.handleMessage(paramMessage);
      AgentService.this.result = Controller.IQInit();
      Intent localIntent = (Intent)paramMessage.obj;
      if (AgentService.this.DBG)
        Log.v(AgentService.TAG, "Action[" + AgentService.submitTime + "]:" + localIntent.getAction());

For the non-Android developers out there, here's what the code cumulatively does:  
  1. The HTC program (Ed. - perhaps based on a Carrier IQ reference code) gets a message from another HTC program or a program it modified to gain access to additional information (such as the default webkit browser).  
    NOTE: Obviously it can only make these modification to core system apps it distributes on its smartphones, not apps downloaded from the Android Market. 
  2. It starts the main Carrier IQ app (in /system/ on HTC devices).
  3. It sends an Intent for the main Carrier IQ to read and log, echoing the data it received.
  4. It checks to see if the debug flag is set.
  5. If this flag is set, it writes a log to the system's debugging cache file with the full details of the Intent (which include various juicy details like SMS contents, etc.).
The problem?  The debug flag is set in the production build.

IV. The Aftermath

If HTC had not left this flag set, perhaps somebody someday might have found out about Carrier IQ.  But the security flaw in the debug stream would never have existed.  And it would have been unlikely that novice developer Trevor Eckhart would have found it while poking around in the debug log -- because nothing would have been printed to the debug log.  And the public witch hunt against Carrier IQ never would have ensued.

Of course this was probably just a careless, but innocent accident on the part of some HTC developer.  But it was a costly one, one that sent ripples of fear, uncertainty, and doubt through a public already fearful of data mining.

That line of code would lead to a world of hurt.

A source close to another devicemaker seconded Mr. Rosenberg's opinion that the module in question appeared to be HTC code and not Carrier IQ code,  when I showed them it.  After showing them the fateful line, they remarked, "It really appears like Carrier IQ got screwed by HTC."

"Screwed" indeed.  Who knows how much business Carrier IQ has lost because of this mess.

Perhaps that explains the dumbfounded statement of Carrier IQ spokesperson Andrew Coward (a special thank you to Network World's Senior Editor John Cox who pointed me to this quote during a discussion),"We're as surprised as anybody to see all that information flowing.  It raises a lot of questions for the industry -- and not [only] for Carrier IQ."

V. The Blame, Redux

The bottom line here is that it increasingly appears that there's a strong likelihood that Carrier IQ was not the one directly responsible for the inadvertent exposure of private data.  The direct responsibility falls on HTC and likely HTC alone (Dan Rosenberg does not mention finding a similar flaw in Samsung implementation of the data passer).

But in terms of a more broad umbrella of responsibility, there's two perspectives you can take here:
  1. The "Tank Argument:
    I made this argument to a colleague, writing about the data breach.  The premise here is that Carrier IQ is somewhat to blame for the products it puts out jointly with its partners, even if the partner made the component that did the damage.  

    I give the analogy of a tank software maker who passes the responsibility of firing the main gun to a third-party who then botches the job and delivers a code that unbeknowst to testers on an extremely rare but predicable occasion erratically fires due to a known bug.  Servicepeople die and the software is scrutinized.  The bug is found and the families of the deceased sue the tank software company AND its partner, even though the partner wrote the flawed subprogram.  The main program maker should have kept track of what was going on its joint finished product, the lawyers might argue.
     
  2. The Small Developer, Big Developer Argument:
    Even with all its recent success Carrier IQ has no where near the resources of HTC.  So you could make the counterargument that HTC's faulty software should be blamed on HTC alone as Carrier IQ as a (respectively) smaller third party who services scores of different device makers and carriers doesn't have the time to individually monitor its partners' associated codes for flaws (and perhaps doesn't even GET uncensored access to these partner codes).  

    This is certainly a fair argument as well.
(Ed. - If my reference code hypothesis is confirmed, this offers some additional stock in the philosophical argument that Carrier IQ should be partly to blame, even if HTC was negligent and lacked common sense in modifying the reference design.)

Whichever argument you buy, the Carrier IQ mess does paint an interesting picture:
  1. HTC accidentally leaves its debug on in a single line of code, exposing Carrier IQs metrics (and more) to the world (and malicious parties).
  2. A non-developer media fails to properly research the issue and assumes its endemic to all Carrier IQ devices (or at least all Android devices) and goes wild, accusing Carrier IQ of installing rootkits and violating user privacy.
  3. A non-developer public fails to understand this is an HTC issue and panics, when in many cases they are at no risk.
  4. Carrier IQ potentially loses millions in business.
Now the exposed information does offer some decent philisophical debates (albeit at the cost of Carrier IQ, et al.'s financial well-being and creation of perhaps unwarranted paranoia among non-HTC device owners):

Should Carrier act as a platform manager and collect anonymized data further safeguarding privacy?

Or...

Should they act as a dumb pipe at the cost of perhaps providing inferior service that might have been improved by telemetry?

The debate is analogous to the question on the merits monitoring/usage data collection in an IT setting, given that your devicemaker and/or carrier are in effect your smartphones' administers and you're just a user, unless you hack your phone and root it. (Hence why Carrier IQ is not a rootkit, even if it keylogs -- it was installed by the administer of the device -- that's the fundamental difference between an administrative monitoring software and a rootkit, by definition.)

The question in IT terms would be something like:

Should an IT department monitor users, at the cost of privacy, in order to counter extreme abusive misbehavior and/or improve service quality?

Or...

Should they act as a dumb pipe at the cost of perhaps providing inferior service and potential abuse?

The world of commercial IT computing has virtually unanimously voted in favor of the former approach -- active administration.

But hey, perhaps the smartphone, despite being an analogous situation (customers wanting to pass of the icky administrative responsibilities on to a service provider who lowers the customers' permissions to user level) -- should be handled differently.

It's a good philisophical debate to be had.

But members of the public and media, please, let us be rational and look at the actual code before we pass judgement and condemn Carrier IQ, Samsung, or anyone else.

APPENDIX:

Methodology:
In my past piece, I relied primarily on the debugging cache a built in log file readable by Android apps or PC-side developer tools like ADB. I personally used "Catlog", a free app by Nolan Lawson, for convenience.  When verifying that it was com.android.htc.iqagent that was doing the talking, I used "Process List" by Tak Kuji to grab and match the pIDs in the log.

In this followup I:
  1. Root my test device.
  2. Mounted in ADB and transferred the appropriate .apk (iq-related) off the phone.
  3. Opened a cmd prompt
  4. (Windows button > type "cmd" in the bar)
  5. Turned the .apk files into .zip files via a rename.
  6. Extracted the contents to a folder. 
  7. Ran dex-translator-0.0.9.3 (free: from a Google Code project) on the classes.dex compressed .jar file:
    QR code --- dex translator
  8. Ran jd-gui.exe (free: from a French developer) to view the resulting classes-dex2jar.jar file.
  9. Poked around in the code!

You can of course try this for yourself and test it out on your Android smartphone of choice.  But beware of the following:
  1. Rooting devices voids their warranty (though a reinstall of the factory rom could obfuscate that fact, should you need a repair... hint, hint).
  2. Decompiling apps you did not make is a gray area of the law.  Typically it's viewed as legal for security researchers.  But be aware that it is a sort of hazy region if your ultra-worried about liability.
Happy reverse engineering!


Comments     Threshold


This article is over a month old, voting and posting comments is disabled

Haha...
By MrTeal on 12/9/2011 5:53:27 PM , Rating: 4
Great piece.

While I can't comment on this specific case, it's not exactly rare for debug code to get left in commercial products. Late nights and inadequate peer review of commits lead to all kinds of problems with functionally fine software going out that might cause unforeseen issues later on.

If your research is accurate, I can't see how carrier IQ can really be expected to take the blame for this. They write the tools, and HTC interfaces them incorrectly. I would in fact say your tank analogy is backwards: Carrier IQ made a main gun that works fine, and when the main contractor integrated it they messed up and a specific combination of speed and shock causes the tank to signal the gun to fire. Yes it was the gun that fired, but it was the implementation that was at fault, not the gun. Expecting a logging and tracking software to parse its commands to determine which would be valid debugging where they might want to see plaintext information vs when it shouldn't be logging really doesn't seem like their problem. If the HTC OS build is telling Carrier IQ to log sensitive data, it falls on HTC.




RE: Haha...
By JasonMick (blog) on 12/9/2011 6:15:59 PM , Rating: 3
quote:
If your research is accurate, I can't see how carrier IQ can really be expected to take the blame for this. They write the tools, and HTC interfaces them incorrectly. I would in fact say your tank analogy is backwards: Carrier IQ made a main gun that works fine, and when the main contractor integrated it they messed up and a specific combination of speed and shock causes the tank to signal the gun to fire. Yes it was the gun that fired, but it was the implementation that was at fault, not the gun. Expecting a logging and tracking software to parse its commands to determine which would be valid debugging where they might want to see plaintext information vs when it shouldn't be logging really doesn't seem like their problem. If the HTC OS build is telling Carrier IQ to log sensitive data, it falls on HTC.

I could buy that the analogy may be non-applicable in this case based on your argument. :)

The tank argument is merely meant to represent the philosophical stance that your company is jointly responsible for the products it produces with others...

I agree that this is a very unrealistic standard in many cases (e.g. a gear maker is not responsible if the transmission maker poorly assembles its product and causes a crash).

In this case there's only two parties involved in this particular case for this particular product (the comprehensive 3-program Carrier IQ package). So you could make more of a legitimate argument that joint blame should be had for flagrant mistakes.

But I think you could probably make a stronger case, as you said, that it's unrealistic to assume that Carrier IQ should have been playing watchdog to make sure HTC didn't screw up its deployment of the product.

I had to play devil's advocate in the article, though, for the sake of trying to be objective and show what I see as both philosophical sides to the argument.

..............................................

That said, I believe the media grossly underresearched this story, while spreading mass panic. Not terribly surprising, but disappointing. My research is by no means perfect or the final end-all-be-all... I could still be proven wrong on some of my conclusions.

That said, I at least honestly TRIED to actually look at and analyze to the best of my time and ability the code I'm writing about, rather than joining the rest of the mob and pushing Carrier IQ a bit closer to the lynching stand.

I'm thankful you appreciated that, even if others don't appreciate my piece as much as you did.


RE: Haha...
By Solandri on 12/10/2011 12:21:21 AM , Rating: 5
I think you're missing the bigger picture of why the media went nuts over this tempest in a teapot. The phone is mine. My carrier made me pay for it/is making me pay for it. If I break it, I have to buy a new one. If I try to quit the service before my contract is up, I have to pay an early termination fee because I haven't finished paying for it. I can customize it to my heart's content, sell it, smash it on the ground, flatten it with a steam roller, etc. and I will not get in trouble for it.

By all rights, the phone is my personal property. The carriers have no right to run any software on it which performs functions beyond those needed to provide the service I contracted with them for. If they do wish to run such software, the very least they should do is ask for my permission first. That's why I don't have a problem with Google's location services in Android. They ask for my permission every time something tries to turn it on. Failure to do this makes the software spyware at best, malware at worst.

I believe selling phones with this sort of software hidden on it should be illegal. It's about as low as selling a computer with a backdoor installed. Just because it ships with the backdoor not doing anything does not make it ok. It's putting in a backdoor in someone else's property without their permission nor knowledge which is the problem. The fact that they haven't yet used the backdoor simply mitigates the severity of the violation, it does not negate the violation itself.

This is something that's been gradually growing the last couple decades - products which you "own" but which are programmed so the seller/manufacturer retains some control. Carriers locking phones to work only with their service or arguing that it's illegal to root your own phone, DVD players which only work with discs from certain regions, music files you buy but which you cannot move easily between devices, consoles which brick themselves if you try to install a non-sanctioned OS, etc. The line has to be drawn somewhere. If they want to retain control over these devices, they shouldn't be selling them. They should be renting them instead. But if they claim to be selling them, then they should be required to treat it as a sale and respect the privacy and independent free will of the new owner.


RE: Haha...
By ekv on 12/10/11, Rating: 0
RE: Haha...
By nocturne_81 on 12/12/2011 6:18:47 PM , Rating: 2
I think you're the one missing the point..

First of all, logging isn't at all the same as spying.. I have yet to see any info stating that any of this data was actively sent to the carrier, HTC, Carrier IQ, or any other party. To me, it seems like it was just some leftover test code that was originally used to check the call structure from hardware buttons and the phone dialer. I didn't see any stated evidence that the software logged anything from the virtual keyboard, such as entered url's or text messages.

Compare it to any modern browser and it's implementation of cookies.. visit my webpage, I have your IP (unless you're a nut and use a proxy), an easily parse-able of every site you visit (and usually what you did while you were there), and if I can give you enough of a reason to log in with your facebook account.. well, the privacy implications are virtually endless. And you have a problem with a phone that logs what numbers you dial? There's no evidence this info was ever abused (sure there's some hack-app devs working on it now though), and I'm sure your carrier already knows what numbers you dial anyways.

Second, purchasing your phone outright and receiving a heavily discounted one under contract are not at all the same things.. You do indeed have the option of spending $750 on a brand new Nexus Prime (mostly) free of bloatware, and can use it on whatever carrier you wish -- if you have the money left to pay for it. Receiving a phone under contract is more of a lease -- you don't really have any free right to use it until the contract is over (when you finished paying for it). It may seem frustrating, but I'm sure it's all explicitly stated in your subscription contract.

Yet another reason I don't own a smartphone.. Buying one outright is just too expensive, and no carrier supports them without a ridiculously overpriced inaptly-named 'unlimited' plan.


RE: Haha...
By drycrust3 on 12/10/2011 1:14:09 AM , Rating: 2
I think its a great piece of journalism. You've put the facts ahead of popularity, which I think is what all good journalists (and scientists) should do.
One of the things that has let a lot of journalists down wasn't so much their lack of understanding about the subject, but that they didn't bother to talk to people that do have an understanding on the subject.


RE: Haha...
By flash2011 on 12/10/2011 9:41:51 PM , Rating: 2
I think you are giving Mick a little too much credit here. I can give him credit for indicating that is was a HTC mistake which allowed the public to be informed about Carrier IQ (I actually am surprised that the code was not obfuscated with proguard or another tool).

However he then spoils the article by largely regurgitating the Carrier IQ talking points. He takes at face value the "false dichotomy" that you either can have this spyware software on your phone or you can have crappy service, completely ignoring the fact that this is largely a US issue (in most other countries you don't need to buy your phone from the carrier to obtain cellphone service). I have heard of no evidence that US cellphone service is superior to service in other countries, if anything the opposite is true.

He also gives the false analogy of comparing the carriers to the IT department. In an IT setting I don't own my laptop or desktop, and I am supposed to be using the IT equipment as part of my job so I have absolutely no expectation of privacy. If I sign up for cell service and buy my own phone, I just don't see why the carrier should be able to see anything inside my phone without my express permission.

The worst part of the article is the subtle slander of anyone who disagrees with his point of view. He calls Trevor Ekhart a "novice developer", even though Trevor has had 10 years working in IT. Rather than realizing that people are legitimately getting upset about losing control of hardware they own, instead he says they "panic" and they are not "rational" ("thanks for setting me straight, Mick!" /sarcasm).

And finally, please don't give him any credit for the "contrarian" opinion. Contrarian opinions drive page views. He was just doing his job. If anything the "courageous" article would have been to keep the heat on Carrier IQ, not to give it a free pass as he has pretty much done here.


RE: Haha...
By ghost.image on 12/11/2011 6:14:00 PM , Rating: 2
I have to agree with Flash on some parts.
As corporate IT you own and control all parts of your network so watching everything and being able to control it is by design and law.
Now to that end what control do wireless carriers have over devices running on their networks? Or maybe the question is how much control should they have?
The reason I ask it the following. Let say someone loads some custom non standard OS on a device, it could be a laptop with wireless data card, it could be a phone or tablet.
It then goes out and creates all sorts of havoc on the network, it could be anything form redirecting DNS queries to overloading cell sights with data. It could even be actively spying on other devices.
What control or right does the carrier have to find out what is going on and shut down, block monitor the device causing the problem as it is now affecting other customers?
The reason I am using the case above is because while you don't work for a carrier, you do sign some sort of agreement with the carrier about running a device on their network which you do not own.
Also one point of disagreement. Trevor while an enthusiast does not show a long as sorted carrier as a programmer or security expert.
Please see http://trevoreckhart.com/ for his resume.
He does show experience in Windows, management using Cisco UI and desktop and laptop support, but nothing regarding custom script implementation across linux builds, large scale security infrastructure planning, nothing.
Now before you send the lynx mob my way I am saying this because:
1. He has a right to experiment, and look into things.
2. He has a right to formulate a theory and present it to peers to support or contradict.
3. He has a right to say what ever he wants to whom ever he wants about what ever he wants*** But there is a catch.

He posted a fire starting storm of a video to millions of non technical people, and it seems now most of it can be shot down, or at least explained.
While I agree there is an HTC implementation issue, I don't know if anything was legally done wrong, so the AFF better stick around his camp for a while.


RE: Haha...
By flash2011 on 12/12/2011 12:03:13 AM , Rating: 2
In answer to your question on "how much control should they have"

Same as what my corporate ISP would have if my server got infected and started flooding the network with spam. They wouldn't require me to install ISP spyware on my server. They would very quickly just cut off my network access. I don't see why wireless phones should be any different. If my phone is misbehaving they just block my id (IMSI/MSISDN) or my phone id (IMEI/MEID) from registering on the network until I have fixed the problem. If some customers want the carrier to administer and spy on their phone, that is fine. This, however, should be opt-in ONLY.

I repeat again that the US cellular experience where the phone is tightly bound to the carrier is largely unique. In **most** countries it is very easy to buy the phone separate from the cellular service. If you don't like your service you just pop in a SIM from another carrier and you are good to go. Overseas carriers just don't have the opportunity to install their spyware on your phone...yet I have not heard about these foreign networks keeling over due to hoards of misbehaving phones.

Whilst techies have known for sometime that carriers are up to these spyware games (e.g. look up flash2011 on slashdot). Trevor Eckhart did a great service by making his youtube video. It started to make the media and public in general aware of what is going on. This truly needs a proper debate, not only about Carrier IQ (which by the way even Eric Schmidt called Carrier IQ a "keylogger" - you would think he would be more careful with his words if he was unsure), but on a whole range of issues related to privacy on mobile devices.

I do find it rather outrageous your attempts to "shoot the messenger" (Trevor Eckhart). First you (and Jason Mick) suggest we should disregard him because he doesn't have the qualifications, even though we are not talking about some obscure hole in the TLS protocol or in AES encryption. We are talking about data logging on a phone. His many years of IT experience **more** than qualifies him to make statements about Carrier IQ (even though he uses "Windows" and started at "Staples" - gee you would think we should ignore **anyone** in IT who never completed a university degree - **cough** Bill Gates **cough ** Steve Jobs **cough** Mark Zuckerberg **cough**).

Then you bring up his recent move to Telogis. Apparently they also write software to handle device metrics. What are you trying to insinuate here? He may now know **too much** about the topic? I may have missed it but, unlike Carrier IQ, I didn't see where Telogic install spyware on consumer devices. Perhaps you are trying to insinuate corporate sabotage? I guess if you throw enough mud, even though none of it is true, some of it will stick. Classic "shoot the messenger".

Your final, most revolting argument, is to suggest that what he did was wrong (another "shoot the messenger" tactic). This is not a case of finding a zero-day vulnerability in Windows and spreading the news all over the web without giving Microsoft the opportunity to fix it. Instead this is a case of shedding some sunlight on a hidden backdoor installed by carriers to vacuum up private data (if you look up my slashdot submission it appears that Verizon is already selling this data, though it comes from a different program). I don't think he claimed to provide a complete analysis (that will come from discovery for the class action lawsuits - I am looking forward to this. Hopefully they don't settle out of court to try to "hush it up"). He just reported what he saw. To say that the tech community needs to "self censor" to protect corporations is just not worthy of a citizen of a country that supposedly prides itself on the First Amendment.


RE: Haha...
By MozeeToby on 12/12/2011 1:27:45 PM , Rating: 2
quote:
the "false dichotomy" that you either can have this spyware software on your phone or you can have crappy service,
Verizon has said repeatedly they don't use this software and it's not been found on any Verizon phones (including mine, and yes I did check). You know, Verizon, the company with the largest network with the fewest dropped calls. This software simply isn't necessarily.


RE: Haha...
By ghost.image on 12/12/2011 4:02:18 PM , Rating: 2
It is an interesting stement that Verizon already resells metrics, or "user usage" and doesn't use Carrier IQ. So another question is how are they getting it?


RE: Haha...
By flash2011 on 12/13/2011 12:54:39 AM , Rating: 2
You are absolutely right. Verizon have said repeatedly that they don't use Carrier IQ. Unfortunately, they have been very careful not to say that may have an equivalent running on their phones. They **must** have an equivalent to be able to do this:

http://www.pcmag.com/article2/0,2817,2394625,00.as...

In theory, you can "opt out" which is wonderful. Unfortunately though if you read the terms of the "opt out" you are opting out of Verizon wireless using your private data for very specific reasons. It doesn't stop them from capturing your private data and using it for other purposes.


Wow, terrible code
By MeesterNid on 12/11/2011 1:47:32 PM , Rating: 2
Not only are they violating the principle of least knowledge here:
quote:
AgentService.this.result = Controller.IQInit();


but then there is 0 encapsulation when accessing the "obj" property here:
quote:
Intent localIntent = (Intent)paramMessage.obj;


Code review time.




RE: Wow, terrible code
By ghost.image on 12/11/2011 6:15:27 PM , Rating: 2
I am sure all code for all device implementations will go through the review process at this point.


RE: Wow, terrible code
By rs2 on 12/11/2011 7:33:40 PM , Rating: 3
You're wasting your time, reviewing code that was spit out by a decompiler. There's no way of knowing how closely it conforms to the originally written code.


Both arguments are wrong and without basis.
By Trisped on 12/9/2011 7:41:06 PM , Rating: 2
In the article you present two arguments: The "Tank Argument and The Small Developer, Big Developer Argument.

Both are wrong as they do not actually reflect the relationship between software developers and users.

When a code library is written and given to another person to implement, it is 100% this other person's choice how to implement the library. While the original writer will often give samples showing a sample implementation or even in a few cases, help the implementer directly, it is always the implementer's responsibility to verify that the implementation is appropriate for their intended use.

To say Carrier IQ cares any blame for how HTC implemented their code is incorrect, as they had no control (and probably no knowledge) over how HTC decided to implement their code.




By JasonMick (blog) on 12/9/2011 8:15:27 PM , Rating: 2
quote:
When a code library is written and given to another person to implement, it is 100% this other person's choice how to implement the library. While the original writer will often give samples showing a sample implementation or even in a few cases, help the implementer directly, it is always the implementer's responsibility to verify that the implementation is appropriate for their intended use.

To say Carrier IQ cares any blame for how HTC implemented their code is incorrect, as they had no control (and probably no knowledge) over how HTC decided to implement their code.

True, but I've seen a copy of the Samsung Carrier IQ source and it's very similar in calls/structure to the HTC code though it also has some key differences.

That leads me to believe that the code in question is a reference design, originally written by Carrier IQ, but modified by HTC. I could be wrong on that hypothesis.

If this was the case, would your perspective change?

Don't get me wrong... I still personally believe the primary party at fault was HTC for lacking common sense of removing sensitive debug logic from a production code.

But if Carrier IQ wrote the code that's printing the debug with the intention (likely explicitly voiced to OEMs), that they should turn it off once their designs were complete then perhaps, it is in a way CIQ is to blame too, albeit in a lesser regard.


By Trisped on 12/11/2011 9:42:09 PM , Rating: 2
quote:
That leads me to believe that the code in question is a reference design, originally written by Carrier IQ, but modified by HTC. I could be wrong on that hypothesis.

If this was the case, would your perspective change?

If Carrier IQ wrote sample code which included writing to a debug stream all values passed in, when these values often contain sensitive information then I would say Carrier IQ had done wrong, though the full fault of the problem would still be 100% HTC's because it is the implementer's job to make sure the code sample is implemented appropriately for the intended use.

That being said, debug logging systems are usually unique for each application. Some times they are written to a flat file, an xml file, a SQL database, or some other method. For Carrier IQ to specifically indicate how to log debug data would indicate that they would know how all users of their code log this information. My experience with Android is limited, but I do not think there is a generic, always used, debug logging system. If there is an Android debug logging system, I would suggest lobbying Google to make it easier to tell when software is released with debugging on. Weather there is such a system or not, it is still 100% HTC's fault for the unsafe release.

What is more likely is either HTC was having trouble debugging and asked Carrier IQ for assistance (not likely), or Carrier IQ's sample code had a line comment indicating that debugging information could be added here (also not likely), or HTC added their standard debugging code to the Carrier IQ sample code to help them verify the information was being processed and reported as expected.

I cannot think of a reasonable condition where code written by HTC which resulted in a security breech would be the fault of Carrier IQ.


Force off
By swizeus on 12/9/2011 9:55:04 PM , Rating: 3
But on the other hand, I saw in a video on youtube about the concern regarding user not to have a choice to turn it off. Even when they have clicked to force stop button. With app that have so many permissions (access to personal information - shown in the video) and not to be able to stop it, who wouldn't freak out ?




RE: Force off
By ghost.image on 12/11/2011 9:49:45 PM , Rating: 2
I think part of the issue is the HTC implementation. Also the debug log isn't exactly what happens on the back end.
A program of this magnitude runs in the back ground and is powerful but then again it needs to be in order to properly monitor a devices performance.
Why it was not supported first and then released to Youtube we will never know but it is out there now.


Carrier IQ Is Still Spyware
By flash2011 on 12/10/2011 12:25:44 AM , Rating: 5
In a scene in the movie "The Tourist" with Johnny Depp's character was trying to report a crime to an Italian police officer. The police officer initially thought the crime was murder but Johnny Depp corrected him and told him it was only attempted murder. So the police officer officer said:

Colonnello Lombardi (police officer): That's not so serious.
Frank Tupelo (Johhny Depp): Mmm, no, not when you downgrade it from a murder. But when you upgrade it from room service it's quite serious.

We know that the carriers have not been upfront about Carrier IQ. We know that it is still sending a lot of private information from your phone whether you are on the network or not. I would class anything sending all URLs I visit or all apps I run to a third party "spyware" if it ran on my PC. I don't see why MY PHONE should be treated any differently.

Perhaps it is not as bad as first thought...but lets not let Carrier IQ or the carriers off the hook. If "catch all" contracts allow this to happen then the law needs to be changed to make this illegal without a specific opt-in (i.e. you can still purchase a wireless plan even if you opt-out).

I really hope this starts a discussion about all the other outrageous privacy violations occurring on your phone (e.g. I recently found a very popular magazine app from a major publishers app was embedded with flurry, smaato and ad-x.co.uk plugins - all being sent personal info like IMEI, android id, and email, with at least ad-x.co.uk sending this information in plain text).




The Problem
By rs2 on 12/11/2011 7:12:31 PM , Rating: 3
A couple of points:

1. The code that comes out of a decompiler is not the same as what the developer originally wrote. Depending upon a number of factors it may be close to the original code, or it may not be. In any case, drawing conclusions about which and/or how many lines of code were screwed up based upon the output of a decompiler is specious reasoning, at best.

2. This one is quite far off the mark:

quote:
The problem? The debug flag is set in the production build.


The problem, if your disassembled code is to be believed, is that a debug flag was used in the first place. The proper way to do this sort of thing in Java is to use a system-property to enable and disable debug mode, not constant flag values hard-coded into the source files. Then the runtime environment determines whether or not debugging features should be enabled, and there's no risk of bad things happening because a developer forgot to change the hard-coded flag value from 'true' to 'false'.

If you're going to call people out for poor coding practices, at least do it properly. Using an instance variable as a debug flag in a Java application is not ever good practice, whether or not the developer remembers to turn the flag off for production.




RE: The Problem
By ghost.image on 12/11/2011 9:44:12 PM , Rating: 2
I think what needs to be worked out as it seems to be is the HTC implementation. We are not sure exactly what and wasn't included in the original code, but it seems at least fr debug someone forgot to turn it off.
I don't know where the blame lies, but it is an interesting discovery to be sure.


By cliffa3 on 12/9/2011 9:17:41 PM , Rating: 3
You can't code sloppy unless 'sloppy' is the name of something you're coding. You can code sloppily. You can write sloppy code, but to do that is to code sloppily.

This site constantly has annoying headlines and summaries that are poorly worded and cause me to have to read them a couple of times to figure out what it's trying to say. Please fix.




Finally
By SkeptiCoder on 12/9/2011 6:54:41 PM , Rating: 2
Thanks for being one of the few rational journalists on this topic, Jason. I mean god, it was like the whole effing world was "Oh mah gawd, we r bein spied on by da carriers". From the very beginning, I knew something fishy was up with the original "research".

Not much of a discovery, in the first place, honestly, as anyone who has ever connected their device while having eclipse open can just look at LogCat and oh, there it is.




...
By Gunbuster on 12/9/2011 10:38:13 PM , Rating: 2
carrier iq still coded software to collect data. They should have done some CYA. It it not like they coded an app to grow flowers and it ended up stealing data...




What can we do now?
By ghost.image on 12/11/2011 5:55:14 PM , Rating: 2
Good Article..
Sometimes the follow on discussions are just as interesting.
From a legal stand point I think we can probably deduce or at minimum assume the following ideas and follow on questions.
1. The carriers probably have something somewhere in their end user agreements regarding data collection and monitoring. What should be changed in their regard? I think most folks are just comfortable with just not having it buried in the end user agreement.
2. Even though you buy the phone and yes for those enthusiasts out there running custom ROMs should be your choice, but what if any control can the carrier, and for that matter the manufacturer hold over their device as dictated by law?
3. I think there has been some confusion on who Carrier IQ's customers are. They are not you, the end user of the phone. They are the carriers. It is like a car analogy, pieces and parts of the car might come from all over, lots of different sub contractors, but the name on the car says Ford. In this instance the people who need to opt in or out is the carrier not you, assuming the end user agreement you signed covers data collection.
4. I would have to say more than likely specifically with HTC and Carrier IQ, HTC would probably hold the majority of responsibility. It is their device and like you said all the other phones as far as we know don't seem to have the debug mode turned on. And while most programs have a debug mode option, the fact it was turned on means it probably was a mistake by an HTC employee.
5. Someone had mentioned that Trevor had ten years of experience. While he is an Android enthusiast to be sure, experienced no. He was working at Staples until 2005. After that he is working at a single company as a systems administrator which is Windows centric. He does not show any programming work history or security work history with regard to specific wireless data protocols. NOTE: this is based off of his online resume, which may hold inaccuracies.
So for reference or further work on Trevor's initial theory I would suggest reading Dan Rosenberg's analysis. Tim Armstrong from Kaspersky Labs. Also there was a blog release from Trend Micro with regard to Carrier IQ. While the Kaspersky, and Trend statements are not as detailed as this, thank you by the way for the details, they are official statements from top quadrant anti virus firms.

This raises a question I would like to pose to everyone to think about:
Android OS is open source. As such it is imperative, and critical that developers pick apart phones, and the OS to look for flaws, and bugs. It is what drives the development of the OS and makes it better faster stronger…
So here is my question and this goes beyond the current issue, and I think is a valid inquiry to any developer or enthusiast.
If, and I mean if Carrier IQ is cleared of any charges or wrong doing, which I think there is a good chance, is Trevor in any way responsible?
I am not picking on Trevor, I really want to pose the question. Based on the article Carrier IQ more than likely didn't do anything wrong in the eyes of the law or isn't the super evil company the media first ran with.
The reason I ask is the following.
1. We can deduce that the information released on Youtube while correct in the fact that yes it is an Android debug log set to verbose, it doesn't show what the software is doing on the back end, so lets say that bad things were stated and what it is doing, or heavily inferred and incorrect for the most part.
2. This was put on Youtube, not an Android developer forum. while I think if you have a theory, great! Post it to the forum, ask people to check it out, respond back with comments. I think this would have more than likely not have been the fire storm we have seen had it not been put on youtube.
Developers would have checked into it, found as you did the flaw, tested other devices, and found it is HTC specific. And to be honest I think the issue could have been resolved quickly and easily.
Instead it was posted to millions on a non technical forum causing all sorts of heart ache I am sure for a small startup.
Write or wrong there more than likely has been thousands spent shoring up security, making sure everything is backed up etc. Anyone who has ever read a class action lawsuit electronic preservation statement knows what a pain in the butt it can be. This all equals dollars spent by the company.
3. While free speech is a right here in the US, the the unfounded statements are proven to be false, even if only partly false, can the person making them be held responsible in some way?

Why am I asking this?
Answer: I am asking this question because it raises the question of a code of conduct regarding development and bug tracking within the open source community. Yes we have a right to say what we want, unless we are threatening heads of state, but what is the best way to handle these things.
While the C&D issued by the software maker might not have been the best move, it was warranted. The AFF carries a lot of weight so the back down as I am assuming to take a different approach.
As developers, and enthusiasts, hackers just sounds bad, how should we conduct ourselves in the future? If things turn out such that Trevor gets dragged through the mud over this, wont this discredit the community as a whole?
I do admit there was a lot of bad journalism going on. People ran with the story which became headlines overnight, and really no one until later decided to actually look at the code like yourself, and Dan.
What can be done as a development community as a whole to ensure that issues are resolved, supported by fact, and delta with in such a way as so shore up the Android community as a whole. We don't want to wind up looking like a bunch of amateurs who cried wolf. That helps no one in the future.




Ok now this is interesting....
By ghost.image on 12/11/2011 6:27:51 PM , Rating: 2
uhm I hate to throw this in here at this very second but.... Has anyone checked out Trevor's linked in Profile: http://www.linkedin.com/in/trevoreckhart/ ?
He says he works for www.telogis.com since Feb 2011. hhmm something smells fishy about this. Take a look at what they do?




A little clarification required
By spaced_ on 12/12/2011 4:15:11 AM , Rating: 2
So I'm a bit confused. Afaict based on evidence in this article that the application is just writing to some form of log. And based on Eckhardt's video he was looking at the same log (certainly didn't look like a packet sniffing log). I will take the article's word that this log is in fact a common debug stream that Android applications have access to.

So it appears it was just an oversight on part of a programmer or team of programmers somewhere who packaged the application that let the debug flag slip through enabled and it's logging stuff it shouldn't.

The video posted in this article doesn't point to any wild claims Eckhardt made. He asked some questions at the end of the video as to what's going on. No harm in that.

So what's all the fuss about? Is it that parts of the media are portraying that Eckhardt's video shows that somehow the logged information is being sent back to the carrier? (e.g. over wi-fi/3g)

Presumably the stream just gets written to a file on the device's native storage? Or is just available in memory, perhaps in some form of android message passing system in memory?

What's the dealio?




Flow of information
By matty67 on 12/12/2011 4:33:26 AM , Rating: 2
So in my understanding, CarrierIQ does collect some information.

There was a flaw that caused HTC to have more info collected as this process was enabled by default due to poor coding.

Someone, presumably CarrierIQ, would then receive far more data than they should due to this error, which should in turn raise some kind of flag they maybe someone somewhere screwed up...

I mean unless I'm missing something that flag should have been a big "!" to whoever was in-charge of that data. As I would think the make - HTC, Samsung, Motorola, etc - would be really useful in this kind of situation. Seeing data flood in from HTC but trickle from everyone else would certainly make raise alarms with myself. I'd say this party would bear a good amount of blame as they would be witness to the flow of info while CarrierIQ and HTC development teams were unaware of the issue/breach. It's rather like a leaky dam... If you see it you should notify the powers that be so that said leak can be fixed as ignoring the problem results in this kind of clusterfrak.




By nocturne_81 on 12/12/2011 5:30:18 PM , Rating: 2
As a non-Android user, I have to admit this whole thing has been confusing.. Logging is a normal feature of any program and OS, especially with any flavor of *nix, so I didn't see exactly what the problem was as long as it was just outputting to basic system logs (assuming the carrier has no direct access to these files). The 'AND IF' list was badly needed to explicitly explain exactly what the problem is and, more specifically, what it isn't...

For the non-programmers out there, just have a little compassion.. Nobody's perfect, and these dumb little bugs have a nasty habit of sneaking into finalized code. In my own projects, I often find myself submitting code with unfinished functions and unterminated lines (or often the exact same 'bug' as this -- leaving in a debug var), only to find myself slamming my head against the desk later on wondering how I could be so stupid. It's just part of a natural process, that will eventually result in a stable and efficient product.

As far as installing bloatware on a device you (supposedly) paid for goes.. just keep complaining to carriers, and eventually it may no longer be worth their cutbacks.




"Spreading the rumors, it's very easy because the people who write about Apple want that story, and you can claim its credible because you spoke to someone at Apple." -- Investment guru Jim Cramer














botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki