The newest threat on the official Android market | Hacker News Reader

The newest threat on the official Android market

blog.avast.com

110 pointsilhackernews43 comments

XPrivacy should really come installed by default with Android: the new versions are really quite good (especially with the cloudsourcing and on-demand bits) and really highlight how atrocious most apps are with your personal data. And it is a hell of a lot more effective than relying on companies like Avast to detect and remove bad actors from the market. I've lost track of the number of times random apps (most of whom are just shells around a website) ask permissions for my full phone number, Google and Facebook accounts, contact info etc. for no reason at all. At this point, I'm scared of using Android without the module. (not that ios or windows are any better)

Yeah, I've been holding back on rooting my Nexus 5 for a while just because I don't want to deal with the full wipe, but this convinced me. Obviously this article is somewhat AV FUD (just don't download the sketchy Spanish night vision app with WRITE_SMS permissions), but it's time I got my permissions in check.

BTW rooting doesn't include a full wipe. Unlocking does.

So you can unlock your device when you buy it and not root it till you are ready.

The entire store experience is the opposite of what Eric Lippert calls the Pit of Success: literally no one involved in the process is incentivized to protect your data. Developers ask for all the permissions they can get away with because users get confused by multiple warnings, users blindly click accept on everything because they've learnt they can't use the app without that, Google is blindly complicit in all this because for some reason, they think everyone is as interested in/capable of protecting user data as they are... (Or they just don't care.)

To be honest, the default approach should be making app developers only be allowed to ask for one permission at a time. This would provide a constraint where the developer would ask for permissions they need only when a user tries out a feature in the app that relies on that one permission.

Accessing the address book is another area where permissions could be made much better. No app really needs access to my entire address book. They just need to launch the built in address book and only get the information they need for the one or more contacts you choose from your address book.

I agree, but look at the grief Microsoft got when they tried it with Vista's UAC prompts... more permission popups is clearly not what the majority of users want.

I think one solution is having the prompts integrate with the sort of crowdsourcing algorithm that XPrivacy has (e.g., if >90% of users have granted the app permissions on the address book, then don't show the prompt.)

Another important feature is that the app should not know if the user has granted it the permissions it asked for. If the user doesn't want to, the system should just feed the app bogus data and let the user continue interacting with other parts of the app (as we see today, most apps don't really need the data they collect in order to work.)

This isn't the problem with UAC prompts. Their problem is that the user simply doesn't have the information to make any kind of informed decision, since the prompts are at pointless places in the lifetime of a process or give very little information on what is actually going to happen ("Do you want to allow the following program [..] to make changes to this computer?").

Android permissions, on the other hand, are reasonably fine-grained and allow the user to deduce what the app is going to do. If the app wants to send a SMS, how hard is it to popup a modal dialog that shows the target number and asks for the permission right there? That is obviously much better than showing it in one big list along with "internet access" in some nag-screen on the store.

Of course the app should know I didn't grant the permission. The only reason you revert to bogus data is because apps currently crash in horrible ways instead of handling it gracefully, as would be the case if this kind of at-the-spot permissions handling was the default.

Showing modal dialogs on every new permission request is how XPrivacy works right now, and while I understand and deal with the process, I can easily see how most people would (rightly) see it as an annoyance. I'm just saying they could easily augment it with their crowdsourced data and reduce the number of prompts, which would mean people will actually pay attention to the prompts when something bad happens.

Re: your second point, you're right, if the on-demand permissions handler were the default, more apps would handle it gracefully. However, it's not, and most apps today crash because they don't handle SecurityException when they call the android APIs. Also, you're assuming developers will act in good faith and will do whatever the users want. I would not be surprised at all if companies like Zynga, if they knew the user didn't give them the permissions, implement all sorts of dark UIs to trick/force the user to give them their data.

Should we not protect users just because they're too trusting with computers to realize what's going on?

>I agree, but look at the grief Microsoft got when they tried it with Vista's UAC prompts... more permission popups is clearly not what the majority of users want.

Android only asks for those permissions when installing the app, which is not too burdensome. Iirc Vista did UAC popups for almost every user action, which people rightfully rose hell about.

> I agree, but look at the grief Microsoft got when they tried it with Vista's UAC prompts... more permission popups is clearly not what the majority of users want.

Counterpoint, iOS appears to have a very successful permissions model in doing exactly this.

* Permissions are asked for one at a time

* Apps are expected to handle rejected permissions, but they're sent dummy data anyway (address book has no contacts, GPS coords is 0,0 etc)

* Permissions can be revoked in Settings.app

I guess something like that may work better in a more limited mobile environment where you don't have to do it 20 times an hour, and it's also easier to do it with touch.

That'd be clicky, but it's on the right lines.

A better way would be to come up with a smart grouping profile for apps that want reasonable common combinations. For example, "Standard application that can access your INTERNET". Give it a nice screen. "Standard application application that can USE YOUR CAMERA and access your INTERNET" would get a big question mark icon.

For any app that wants any weird combination outside the standards, make it opt in like you say - one permission at a time. With each requiring a screaming skull and crossbones.

If you did that, you could integrate more fine-grained permissions into a small number of supported profiles, and developers would be strongly discouraged from choosing anything outside that combination.

They blindly click on ACCEPT because Google stupidly lists relatively benign permissions ("network access", "read phone state", "vibrate") where they should be only listing severe ones. And the permissions they do list are often poorly explained.

I would not say that "network access" is a benign permission. Perhaps checking the state of the network is, but not full network access.

xprivacy and xposed framework give an insane amount of control back to us end users. I suggest everyone cautious of their private data being taken without permission to look into them for android.

Denying permissions breaks most apps (I'd say, 8-9 out of 10 just crash due to unhandled exceptions), so XPrivacy returns fake data (no contacts, no Internet connection, spoofed MAC and IMEI etc.).

But, then, some companies are really upset about spoofing. For example, Swype had serious issues with that to the extent they cried they won't even be able to release their famous keyboard if they weren't be able to get personal data for their analytics. [1] So, CM team decided to not built any spoofing (the only practically working solution to the problem) in.

Dancing bunnies 1 : Security 0

____

[1]: http://www.androidpolice.com/2011/05/25/swype-cyanogenmod-pe...

I see where the Swype folks are coming from, but it's a bit like the people who complained against the existence of mailinator.com a decade back. Are they seriously claiming that a company whose entire business is based on making sense of dubious data will completely break down if its analysis service gets some bad inputs? How do they deal with shady manufacturers who return wrong data?

Swype is operating in a marketplace that is full of apps crying wolf and asking for way more permissions than they need, usually for unknown purposes. For example, I like to read The Verge and use its app[1], but it has "read phone status and identity" and "modify or delete the contents of your USB storage" in its manifest, which I'm not comfortable with. There is nothing that explains what they use this information for, how long they store it, and who they share it with. Heck, my desktop browser doesn't give theverge.com this permission and yet the site functions just fine.

Why should I bare my personal data to the whole world just because one developer is too lazy to implement checks on his inputs?

[1] https://play.google.com/store/apps/details?id=com.verge.andr...

If you don't handle SecurityException you deserve to lose. Google made revocation of permissions possible, but then hid the capability. They chickened out. Making permissions revocable is one of the best enhancements Google could make to Android.

Developers don't really lose anything. A bunch of privacy-caring nerds who don't let spy on them too much? They're a tiny fraction, and even then, they've increased download counter.

If app doesn't handle exceptions, it's the consumers who are at loss. They either lose their privacy or service. Former is worse (in my viewpoint), but still...

(Obviously, losing some dubious malware-ridden "night vision" app is not real loss to begin with, but there are more high-quality apps that are quite disastrous from privacy viewpoint.)

Google has, at least, hinted in this direction. Developers should get a clue. Or they will find more junk data in their analytics, as users deploy more spoofing.

There's no incentive to get a clue. Typical users will click through anyway. And, well, if you don't get a clue you get a possibility to spy on your users.

Unless Google will start actively penalizing requesting more permissions than absolutely necessary, nothing will change. And, considering all top market players (including Google themselves) are actually interested in analytics and whatever and not interested in end-user's privacy, it's very unlikely scenario.

How does Swype make their money? I thought it is a paid app, so why do they need analytics? Are they secretly selling user corpus data?

That post has some really wishy washy handwavy explanations for how IMEI spoofing etc supposedly ruins Swype analytics. I don't buy it.

Swype's issues with spoofing date back to before they were a paid app (that only happened last year). At the time, there were only two ways to get Swype:

1. Your device manufacturer paid to include Swype in their default keyboard (no IMEIs requested or desired, AFAIK). That was where they made their money, at the time.

2. You signed up for Swype's beta program, to get a free version of Swype directly from them (which you sideloaded, possibly on multiple devices and/or ROMs). To me, whether or not they "really" needed IMEIs for their statistics is beside the point. Gathering those statistics was the only thing they were getting out of their beta program, so if you didn't like that deal you should just not participate - not spoil it for other people by giving false information.

The paid version of Swype still collects location information (or at least uses the location API, according to my phone). Paying users of the keyboard would be quite justified in trying to prevent Swype from getting that information.

Given how shady the whole premium SMS/premium number business is to begin with, it should be made legally simple to refuse all payment on charges to them.

eg. Say you notice you suddenly owe $100 on your phone bill due to a phone app causing charges to your bill (or even just because you gullibly fell for a social engineering attack), you should be able to just refuse to pay with no repercussions other than that the premium provider will be sent a notification that you refused to pay and then may block you via caller id from future use of the service.

I doubt this will ever happen since politicians generally don't give a rat's ass about consumers anymore, but it would be nice.

in aus

> Require mobile carriers to provide the option of barring premium SMS and MMS services on all plans from 1 July 2010. This gives consumers a choice to block such services;

http://www.acma.gov.au/theACMA/premium-phone-services-austra...

My SIM came pre-blocked which was nice.

When I asked O2 Germany to do this, they told me they would have to block mobile internet as well.

Bear in mind it is Avast writing this post (not exactly my favourite company at the moment, incorrectly reporting a trojan to a few users in one of my Apps), so the alarmist perspective is motivated by their business.

If the worst they can report on is an obscure and rather obviously dodgy looking App no longer on Google Play then there isn't much for us to worry about.

I thought KitKat was supposed to block apps from automatically sending SMS messages to premium numbers?

This is a nasty piece of malware, but premium SMS scam apps are nothing new to Android. So the article playing up the danger of this random, seemingly single-market focused malware (Hispanophone vs. global) isn't particularly scary.

>I thought KitKat was supposed to block apps from automatically sending SMS messages to premium numbers?

From the analysis posted, it's trying to bypass that by not sending an SMS to a premium number. It's sending the phone number to a website, and whatever it is that is running on that website is subscribing the user to a premium service.

It probably sends a non-premium message too then. There must be some kind of check in the network so that it's not possible to charge someone just by knowing their number.

No check, Premium SMS technically doesn't require any opt-in. Charging on SMS receipt is called "MT billing" [1] and this is how PSMS works in most countries including the US. PSMS is heavily regulated but the nature of the business today makes it unattractive for anything but fraud.

[1] https://en.wikipedia.org/wiki/Reverse_SMS_billing

That's an eye opener. Should be trivial to enforce this on a network level (requiring user initiation), but I guess that is not something network providers would just implement on their own.

I wonder why the app requires SMS write permissions though.

App stores like Google Play should reward apps which require the least amount of permissions by pushing them higher in the search results (and publicize that fact).

Yeah, it reverse bills the SMS. Android can only block your device from sending premium rate SMS, not receiving them (how could it? It's up to your network operator to handle that side of things).

The original idea with reverse-billing was that users could subscribe to services such as weather updates, which would automatically send a message once a day/week, and the user be charged upon receipt. The problem with reverse billing is that it's clearly open to substantial abuse.

It is a Spanish premium subscription number. To subscribe you need to opt-in, either by web (getting a PIN code you need to enter to confirm the subscription) or by SMS (You need to confirm by replying to a free message from the short code).

I guess this app is going through SMS opt-in, sending the reply behind the scenes.

at this point i'd like to recommend cyanogenmod with privacy guard again [1]

or openpdroid [2], or both. the cool thing about openpdroid is that you can spoof location requests too. also, i don't think any other privacy app allows you to block requests to sim and imei info

[1] http://www.androidcentral.com/cyanogenmod-updating-privacy-g...

[2] http://www.xda-developers.com/android/openpdroid-brings-an-o...

I believe XPrivacy[1] looks more promising than OpenPDroid. First of all Xposed Framework feels easier to integrate - no need to mess with full-fledged ROM embedding, just light patch to the Dalvik and reboot.

And the things I really fancy about XPrivacy is that current versions have learning mode (like `su` GUI prompts, configurable to automatically deny or allow after a timeout) and yet-underdeveloped but very promising argument-level permission controls (i.e. allows WebView's loadUrl for one URI, but not another).

[1]: http://forum.xda-developers.com/showthread.php?t=2320783

I hope CyanogenMod (but other ROMs are welcome to do it, too) keeps focusing on the privacy and security aspect.

Looks like it's gone from Google Play.

I'm surprised they went to those measures to get the user's phone number, it seems like there would be much simpler and more inconspicuous ways to do so on Android.

It's a long time since I didn't touch Java, I don't get the instruction "break label217;".

Is it equivalent to a "goto label217" ? (shock and horror !!!)

That won't actually compile. Having decompiled java binaries before, the decompiler will sometimes generate things like that. I think it happens when there's a jump instruction it doesn't know what to do with.

Thank you.

Reply on news.ycombinator.com