Updated Facebook for Android requires "Retrieve Running Apps" permission | Hacker News Reader

Updated Facebook for Android requires "Retrieve Running Apps" permission

play.google.com

35 pointsSoapSeller45 comments

I really hope Google fixes Android's broken security model. As the owner & user of an Android device, I should be able to configure feature access on a per-app basis. It's ridiculous that you have to either grant an app all requested access, or just don't install it. You should be able to install it, but choose which features to grant access to and which to deny.

What if core features of the app rely on the permissions? Is the onus on the app developer to build checks for permissions or on the user to realize the app isn't working the way it should because they disabled some permissions?

I see nothing wrong with making developers check for features before using them. Should be used to it, with the variability of platforms.

The app would define core features and nice-to-have features. The user would be able to disable the nice-to-haves. Admittedly this just pushes the problem one layer down because Facebook would just make everything part of the core and force people to install. And now the user would have the burden of trying to figure out what was going on.

The best use case for oneself would be if missing features are emulated with dummy data using some app-firewall tool. The phone should give any app no chance of finding out, whether e.g. address book access was granted, but instead show fake data.

Of course this would soon be a cat and mouse game if Google really implemented it for everyone: Developers like WhatsApp would check the address book data whether it is statistically sound and if not they would request you to grand access for real, etc.

All the permissions only required for ads (like position, IMEI, full internet access, reading sms, reading address books) would also just have the app terminate if it's not possible, just like today they check for rooted devices based on tools like bash or they check for modified hosts files that block ads.

On iOS the onus is on the developer.

As a full time Android developer, I can tell you that wouldn't be a burden.

First off, there are already lots of places you have to handle compatibility based on the version of the phone, intents available from other apps installed on the phone, or capabilities (even something as basic as a phone can't be guaranteed if you support tablets).

Obviously you can turn small things on and off in a block of code with if statements, but you can handle major changes with the Fragment model. If you have a drastically different UI due to a missing intent/permission/API feature you can actually ship the app with 2 different Fragments and decide which one to show at runtime.

As an aside, I turned off auto-updating for Facebook and will not upgrade from here. Too many permissions, too intrusive to the UI. I have deleted Facebook from my phone before and I'm fine without it now.

As an Android app developer, I agree with this and it would not be a great burden. Developers would only need to add handling for security exceptions, and, perhaps, an explanatory error message.

It is almost unavoidable that this happens. As Android is used more in enterprise settings, permissions such as access to contact databases would have to be selectively granted, and controlled by mobile device management systems.

To not break existing apps, denied request could just success, but return sensible but completely bogus data (no contacts, no apps running, connected to "default" WiFi network with BSSID 02:00:00:00:00:00, etc.)

It's going to be tough to convince every app developer to have their applications work in those circumstances. I would imagine some permissions which are core to the application would be required. Of course, then we are back at the start when app developers mark all their permissions to be core.

"then we are back at the start when app developers mark all their permissions to be core"

It should always be the user's or administrator's choice. There really is no such thing as a "core" permission. Of course some apps become a nullity without some access, but an unhandled security exception in those cases could result, for example, in a more-detailed system message asking if you want to uninstall the app, since you have decided against giving it permissions that the developer has decided are essential. This would also alert you to when a non-location app was trying to sneak a look at where you are.

Of course, they would probably just compensate by making the entire app useless without the track-u permissions enabled :(

It won't solve the problem. The default response will be to simply refuse to run at all. And, for an app like facebook, which has the upper hand, it is not a big deal that the user doesn't like it.

On iOS I can deny permissions one by one: I can deny the Facebook app to access my location, contacts and photos. It runs just fine without all of those.

There could also be an option to provide the app with fake data instead of telling it to not have any permissions, e.g. an empty address book, empty list of currently running apps, a fake network access which actually routes the data through a proxy and so on.

"There could also be an option to provide the app with fake data instead of telling it to not have any permissions,"

Some guys from Cyanogen released a proof on concept a while ago. You could install any Android app and select which permissions to "mock".

Anyway, I think the permission system in Android makes sense the way it is. It forces app developers to declare what they want to do on you system, but the install process stays simple and straightforward. On Windows and OS X, we used to give every app the "do whatever you want with my computer" permission for years.

On Android you risk a shitstorm of bad reviews if you fail to explain the reasoning for permissions to users. And Google can use the permission list and double check apps with critical permissions for malicous behaviour.

Not sure about that, but Android 5.0 is rumored to use SE Linux (or SE Android I guess), which I believe is based on a more extensive permission model.

I can't find the precise announcements right now, but I'm pretty some portions of SEAndroid are already integrated with Android as of 4.2 (maybe 4.1).

Google was asked for this myriad times. I guess, they won't fix it unless something extraordinary happens (like a huge privacy-related scandal).

Apps on Google Play are throughly infested with ads and analytics and whatever. On desktop we used to call this kind of applications "spyware", frown upon them and let antivirus software block those on sight. On tablets, this is a norm of life.

I would like to see Apple, Android and Microsoft provide a mechanism where the developers can explain, in their own terms, why they need access to certain permissions. I own an HTC HD7 which is WindowsPhone 7. I remember installing some generic music player app (for the life of me I cannot remember the name of it). It required access to, among other things, my location information. At this point the installation was cancelled and the app deleted from my phone. All I could think was "Why on Earth do you need to know where I am to let me listen to my music?".

If developers were at least given an opportunity to explain to their users why they are requiring certain information, consumers may be more willing to allow access. It seems to me many apps take a "lets grab all the info we can" approach which is extremely off putting.

Unfortunately, what you describe is the ideal case.

A typical case might be:

1. Developer releases free app

2. Users find it useful

3. Developer seeks to monetize, adds some mobile ad network libraries

4. Ad network libraries want the user's location

5. User's who liked the app now find themselves OK'ing a frivolous-seeming permission during an update, or they have to uninstall the app, potentially losing access to some of their own data.

And so we find our developer on the slippery slope. Putting the power to cause those apps to fail when they do dubious things in the user's hands means that developers would be more discriminating about their monetization partners, among other benefits.

All good points and I'm sure many of the app developers on HN will be able to give reasons as to why they are unable to provide this information on the apps they develop and I suspect it is all closely controlled by the platform as opposed to the developers themselves.

If the app I downloaded said "Our free version requires your location due to our arrangement with our Ad providers" I would have at least known why they were wanting my location.

I know this doesn't solve the problem, people will still have the choice to either accept it (albeit grudgingly) or uninstall the app. What it does do however is acknowledge they are asking for permissions to a users data. If someone asks for my permission to use my car is it unreasonable for me to know why they want it?

If the permission to get the user's location always bugged the user and most users said "no" the ad network library would quickly realize they're losing money by asking and stop asking.

In Android's case there is no way for them to know. The app either has the permission or it's not installed.

In iOS they do know. The user can give permission, not give permission, or can give it and revoke it later. Their analytics can then tell them what percentage of users are not giving them that info.

In any case, you as a developer could also choose to speak up and say to the network ad provider. "I'm choosing a provider that doesn't need more permissions".

> I would like to see Apple, Android and Microsoft provide a mechanism where the developers can explain, in their own terms, why they need access to certain permissions.

iOS (and OS X) does this: when a permission is requested, the developer can provide a usage description string to explain what that capability will be used for: https://developer.apple.com/library/ios/#documentation/Gener...

Note that on iOS permissions are requested to the user at runtime when the app tries to access a restricted capability, which helps understanding the request because it happens in the context of what the user is doing with the app.

Also, each one of them can be accepted or declined separately and turned on or off at a later time.

Thanks for this, not being an iOS user I was unaware of this. This seems a much more sensible approach to take. Hopefully others will follow suit.

The increasing number of permissions that appear to be out of place for this app is exactly why i hit the "force stop" button for the app about a month ago and then went on to hit the uninstall button for it about 3 hours ago. I would like to continue to use the facebooks messaging features though. however their need to include the read/write/edit your SMS/MMS messages permissions is a serious put off and causes me not to want to install it.

That's because they are the SMS app for Facebook Homeified devices.

Are Facebook mobile developers that bad they can't check if they're on a Homeified device and degrade gracefully if they're not?

What are you asking here? They probably can, but they still need to request the permission upfront because that's how Android is set up.

I'm asking who is responsible for the poor application design choice.

It's not a "poor application design choice." Facebook wants to provide the ability for users to send and receive SMS/MMS from the Messenger app. Even though it's a feature you can turn off, the app must request the permission even if it's not using the feature. This is an Android limitation. A better solution would be to the app request permission only when it needs it, such as how an app requests your location or access to your photos on iOS.

Android provides this for some features but not all.

The problem is if an app requests too many permissions it gets messy to just show a pop-up dialog for each and every one.

This is the reason why Google Chrome and Firefox started working on web apps that essentially are just fancy bookmarks those bookmarks provide permissions before hand for the web app so that they don't need to be requested later.

Indeed. However it would be nice if it was a component that can be added on rather than just making an assumtion. Same goes for the autoupdate i heard about a few weeks ago; Ask me first then go do stuff.

I'm not gonna lie, I like using facebook, but I unplugged it from my phone a while ago and haven't regretted it. Social networking is a fun diversion but a terrible lifestyle.

It's pretty much the only thing left they didn't already require, so no big surprise here. Perhaps it's time to switch to only using the web version on my phone...

I do this and don't miss the official app. At first I did miss having my contacts synced, but HaxSync does this fantastically.

https://play.google.com/store/apps/details?id=org.mots.haxsy...

Just bought haxsync and so far its doing exactly what I want - thanks!

Otherwise I just use FB in the browser too.

Over the past couple of years, I've gone from installing tons of native apps to using almost all web apps. It has worked well for me - in fact, I hardly miss native apps!

This is it, the final call, privacy invading has gone to far.

I'm already wearing at least half a tinfoil hat, now it's time to put it on leave it there.

I have already deleted my facebook account a long time ago and honestly I haven't missed it ... at all!

I encrypt all my hard-drives at home and on my laptop, just because I can.

I have several privacy extensions installed in my browser and I try to avoid using chrome unless it's absolutely necessary.

I still use google search and gmail, but I will migrate away from them in the near future.

I do not want to be the product being sold any more, I don't want anyone to be able to put together a complete profile on me with a few clicks on keyboard.

"The line must be drawn here, this far - no further"

Related to the new Facebook Home app-launche feature?

Yup. The Facebook Home pretty much communicates directly with the Facebook App which has all the permissions needed to be a Home Replacement/Launcher.

This is why Facebook Home does not need any permissions.

https://play.google.com/store/apps/details?id=com.facebook.h...

Well it is no wonder they had 'Too many methods'[1] in their Facebook android application if they've packed all the features into their facebook client, and left their messaging and launcher applications as thin wrappers around the core application. Is there any good reason they don't split the functionality to the appropriate applications? Then maybe they wouldn't have to hack dalvik to run a simple facebook client.

[1] : https://www.facebook.com/notes/facebook-engineering/under-th...

Before I installed Facebook Home last night, I'd replaced the Facebook app with a Chrome bookmark, but kept Messenger. I still received and could reply to text notifications, so Messenger is definitely a real app.

I wonder if Home is just a shell so they can maintain huge install counts on the main Facebook app. Then again, they could require the main app for API access and still use Home separately to handle drawing the Home UI and listening for Home interactions.

Wow, I hadn't noticed that.

I wonder if this new permission is for the purpose of app switching, since the launcher doesn't seem to require this permission in it's current functionality. It seems like a bad permission to add if the interface doesn't yet require it. Are they jumping the gun on new features or using it in the backend?

FYI, on Android, you can get a list of installed Applications without any permission.

Reply on news.ycombinator.com