This is the very reason I smashed my iPhone and do not keep a mobile phone on me anymore. Call me paranoid but I'm enjoying life far more without it burning a proverbial hole in my pocket.
It's true that there's always risk involved with advancing technology. Faster, better and more capable phones are better at doing good things for you, but it also makes them more capable of doing bad things to you too.
it depends, on the java side if we are using log.Config correctly and proguard right all logging is defanged and left out of any obfuscated application.
However, on the OS side it depends on what changes HTC made for carriers and how adequate their codeqa testing and security audits were
You should read the article. Apparently any app that you give permission to use the Internet can leak all your data. Are you absolutely positive that every single free app you download is safe?
At least with droidwall, non-whitelisted apps are perfectly able to connect to local ports (in fact I've got a few apps that don't get internet access, and instead get ssh port forwards).
And it looks like (at least on CM) non-whitelisted apps can make DNS queries as well (so they can still send the data home).
This is an awesome reason to root your phone the second you get it. I've done so to both of my Android phones. You know that cyanogenmod is safe from this kind of blatant wiretapping, and on top of that, you don't have to worry about hassling with it when you need to tether, or when you want to install an application that requires root permissions to function well. :)
Actually sometime back CM rejected patches that would allow you to prevent apps from collecting the device ID (which is obviously quite privacy invasive). I still run CM, but boy do I wish an open-source distribution would spring up that actually respects the phone's owner.
If I remember correctly the patch was rejected due to technical reasons, i.e. rejecting the device ID collection would cause the app to FC (force close) or render it unusable in most cases.
You could try something like LBE Privacy Guard (https://market.android.com/details?id=com.lbe.security) which does let you deny permissions to installed apps, try denying the device ID to apps and see how many of them continue to work. I have, and not many do.
Strange. I've used LBE Privacy Guard to block the device ID to loads of apps and have never seen it cause a force close. Doesn't it use per app device id forgery anyway?
The first submitted patch (of the saga) returned a randomly generated ID (which wouldn't cause crashes). It was rejected in order to "not upset app developers". I can see why Google would never accept such a patch into mainline, but such a status-quo kowtow by an 'independent' project astounds me.
I'll have to look into LBEPG and see if it actually fixes this. I had poked around a bit and it seemed painful to implement this kind of functionality in an app, but perhaps they've found a way (or are playing some really invasive games with system libraries).
And for Google's practice of letting manufacturers do whatever bloody stupid thing they want. I'm stunned that this one ever got into production in its current state.
> And for Linus's practice of letting distributions do
> whatever bloody stupid thing they want. I'm stunned that
> this one ever got into production in its current state.
How many of these phones are going to get a patch or updated firmware to fix this problem?
I'm going to guess either very few or none, as most people won't notice/care about this issue, and HTC isn't making any money off supplying updates.
Imagine if Microsoft forced Dell, HP, etc. to handle software security and updates on Windows for PC's they've already sold - it would either never happen or not happen correctly. Swap the players and that's where Android is today.
(yes, I know about alternate firmware - how many non-geeks are capable of using it and have devices that don't have technological blocks like signed bootloaders to prevent it?)
Last I checked, Google isn't volunteering to manage all aspects of Android OS updates for the device vendors (as MS does for Windows), so I don't think the reversal is valid.
Google would get nothing but more work and responsibility out of such an arrangement.
Yes, it would be better for security and end users, but who cares about them? Google is in it for the ad revenue, and the HW vendors are in it to sell units, not have old models with new software compete against their new hardware.
One of the affected models, the Thunderbolt, only now started getting updates to Gingerbread this week. That is, until Verizon halted it due to a major usability bug that should have been identified easily in carrier testing (voicemail notifications don't work).
Given that it took it took HTC this long to get an update to an Android version that's been available in source since December and they still managed to mess it up, I don't have high hopes for something like this getting fixed.
There are only two ways I recommend Android - use a Google-branded phone that Google will provide complete OS support for, or go it alone with OS updates from a 3rd party.
For non-geeks the first option is the only viable one, IMHO.
Thats why I love the Windows Phone and Apple model rather than android. Windows Phone has had more and frequent updates and they are delivered more consistently across carriers. Same is true for Apple.
Apple, yes. Windows Phone, seriously? The same Windows Phone which resulted in bricked phones after the NoDo update.
Windows Phone has the same update model as Android. You need manufacturer and carrier compliance for an update to get to a phone. Plus there is no custom ROM alternative like with Android.
http://www.winsupersite.com/article/windows-7/Windows-Phone-...
Despite the brain-dead implementation that's the cause of this privacy fiasco, HTC has the best track record among Android manufacturers when it comes to releasing updates. So I would hope they address this issue, and fast.
Windows Phone is an infant platform as compared to Apple and Android. But yet look at how fast they learnt after the NoDo delays. Have you gotten the Mango update yet? It rolled out to exsting phones already. And that is not just in US but worldwide. How many updates has Android pushed so soon to its existing phones and that too so widely?
That's fine for personal use many companies strictly prohibit employees from using unauthorized software. You're pretty much stuck with whatever they give you.
I think security risk could be used as a reason to favor web apps over native apps. An untrusted native app has the potential to do much more damage than an untrusted web app.
47 comments
[ 0.29 ms ] story [ 86.9 ms ] threadI call you not overly paranoid, but maybe bizarrely superstitious?
Perhaps it is a testing/debugging-facility that they forgot to remove from the production build?
That'd be about the only semi-plausible excuse for HTC to come out of this alive (when/if mainstream media decides to jump on this).
However, on the OS side it depends on what changes HTC made for carriers and how adequate their codeqa testing and security audits were
I literally can not conceive how it wouldn't have crossed their mind that any local app with network permissions would be able to connect to it.
Were they just being lazy? Or were they forced to do it this way by some ignorant manager? I would love to hear how this happened.
And it looks like (at least on CM) non-whitelisted apps can make DNS queries as well (so they can still send the data home).
I'll have to look into LBEPG and see if it actually fixes this. I had poked around a bit and it seemed painful to implement this kind of functionality in an app, but perhaps they've found a way (or are playing some really invasive games with system libraries).
> And for Linus's practice of letting distributions do > whatever bloody stupid thing they want. I'm stunned that > this one ever got into production in its current state.
Fixed that for you.
I'm going to guess either very few or none, as most people won't notice/care about this issue, and HTC isn't making any money off supplying updates.
Imagine if Microsoft forced Dell, HP, etc. to handle software security and updates on Windows for PC's they've already sold - it would either never happen or not happen correctly. Swap the players and that's where Android is today.
(yes, I know about alternate firmware - how many non-geeks are capable of using it and have devices that don't have technological blocks like signed bootloaders to prevent it?)
"Imagine if Dell, HP, etc forced Microsoft to let them handle software security and updates on Windows for PCs they've already sold..."
Google would get nothing but more work and responsibility out of such an arrangement.
Yes, it would be better for security and end users, but who cares about them? Google is in it for the ad revenue, and the HW vendors are in it to sell units, not have old models with new software compete against their new hardware.
Given that it took it took HTC this long to get an update to an Android version that's been available in source since December and they still managed to mess it up, I don't have high hopes for something like this getting fixed.
For non-geeks the first option is the only viable one, IMHO.
You've obviously settled on the same conclusion.
Do you know how OTA updates are pushed out for the non-Google Android phones that are bought without a contract?
Windows Phone has the same update model as Android. You need manufacturer and carrier compliance for an update to get to a phone. Plus there is no custom ROM alternative like with Android. http://www.winsupersite.com/article/windows-7/Windows-Phone-...
Despite the brain-dead implementation that's the cause of this privacy fiasco, HTC has the best track record among Android manufacturers when it comes to releasing updates. So I would hope they address this issue, and fast.
http://androidandme.com/2011/08/news/updates-or-lack-thereof...
That's fine for personal use many companies strictly prohibit employees from using unauthorized software. You're pretty much stuck with whatever they give you.
I'm pretty sure that even if HTC fixes this mess I would have to wait forever for Orange to push the update with its custom sw.