Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cyanogenmod Puts Users in Control of Permissions

Unknown Lamer posted more than 3 years ago | from the google-version-coming-in-20never dept.

Android 170

An anonymous reader writes "Cyanogenmod is soon to have a better permissions systems, allowing its users to deny certain permissions to the applications they install. Users are warned that enabling this feature on the nightly build may cause applications to crash or 'force close', but a new dialog allows them to easily return the permissions to stock if they wish. Hopefully Google implements a system similar to this very soon." This is the biggest feature I've missed from Symbian — it never made sense to me why the permissions system didn't put the user in control from the first release.

cancel ×

170 comments

So That's What Slashdot Is Today (-1)

Anonymous Coward | more than 3 years ago | (#36238114)

This is the biggest feature I've missed from Symbian — it never made sense to me why the permissions system didn't put the user in control from the first release.

So an addition of a permissions functionality to a mobile OS that maybe half the readership has and maybe ten percent of them are willing to flash with the particular mod makes the frontpage now ... because the editor misses this functionality from Symbian?

When you install or update an app, Android already tells you what permissions it's asking for.

Funniest part of the article:

Via: Reddit [reddit.com]

Re:So That's What Slashdot Is Today (5, Informative)

paziek (1329929) | more than 3 years ago | (#36238172)

Yea, it shows what is app asking for, but doesn't let you to choose what to actually give. Now its either all or nothing, but Cyanogenmod lets you to fine-tune permissions for app, so for example that notepad app won't be getting access to your contacts or internet anymore.

Re:So That's What Slashdot Is Today (2)

Mushdot (943219) | more than 3 years ago | (#36238200)

It would be nice if the control was a lot more fine grained within each access type e.g. Do you want to allow the app internet access to a specific URL (for example for high scores) and block any other internet access.

It unnerves me a little to see most apps requesting access to your contacts, internet etc without a more detailed explanation why.

Re:So That's What Slashdot Is Today (1)

cheeks5965 (1682996) | more than 3 years ago | (#36238316)

How could an app developer program around this fine-grained control? Even if he could make sure tha the program failed gracefully when certain permissions were changed, key functions in his app could no longer work. How could that not result in an awful user experience? His app would get awful reviews ("sh!t doesn't work!") and he would lose sales.

Re:So That's What Slashdot Is Today (1)

c.r.o.c.o (123083) | more than 3 years ago | (#36238572)

How could an app developer program around this fine-grained control? Even if he could make sure tha the program failed gracefully when certain permissions were changed, key functions in his app could no longer work. How could that not result in an awful user experience? His app would get awful reviews ("sh!t doesn't work!") and he would lose sales.

First, I run Cyanogen, but not one of the latest nightly builds. I may give it a try later today and report how well it works.

Sometimes there is no way to avoid bad reviews. To give just one example, perfectly working widgets constantly get bad ratings and reviews from people saying "It doesn't work" or "It won't open" because they do not know widgets need to be added to the screen, not opened from the app drawer.

But it doesn't change the fact that far too many apps on the Market request permissions far beyond the scope of their functionality. And as far as I can tell, it's exclusively to collect as much detailed data about the users so it can be resold to advertisers. Why would a battery widget need access to my location? Is the voltage reading dependent on whether I am in North America or in Asia? So if those developers use underhanded tactics to steal information from me, I will just block them.

I already have a modified hosts file that blocks all advertising (sorry, but I really am paying a lot for 3G bandwidth). It's amazing how painfully slow some sites become when ads get loaded, and they speed up by a factor of 10 sometimes without ads.

The needle moves from F to E, but what is E? (1)

tepples (727027) | more than 3 years ago | (#36238780)

because they do not know widgets need to be added to the screen, not opened from the app drawer.

There are ways to work around such cases of ID-ten-tango. In this case, create a main screen that shows the widget and a button to show an explanation of how to add it to the home screen. That way, people who want to use it as a full-screen app can, and people who want to use it as a widget can learn how to do so.

And as far as I can tell, it's exclusively to collect as much detailed data about the users so it can be resold to advertisers.

Would you rather all applications be paid and therefore inaccessible to 1. people using devices without Android Market (such as AOSP Android tablets) and 2. people outside those few countries where Android Market offers paid applications?

Why would a battery widget need access to my location? Is the voltage reading dependent on whether I am in North America or in Asia?

I don't know about Asia, but gasoline gauges are calibrated differently in cars for the United States market compared to cars for the German market due to different expectations among drivers. A car sold in the United States that has started to show empty still has enough gas to get to a gas station, while on a car sold in Germany, empty means zero, and the engine will stop. Likewise, standards for how to visualize battery charge may differ per region.

I really am paying a lot for 3G bandwidth

Then keep 3G data turned off when you're not using applications that require it.

So if those developers use underhanded tactics to steal information from me, I will just block them.

And if the application hasn't been able to phone home in the past week or so, the developer will block you back by closing its activity and opening the Market page for the paid version of the same application.

Re:The needle moves from F to E, but what is E? (1)

h4rr4r (612664) | more than 3 years ago | (#36238952)

Would you rather all applications be paid and therefore inaccessible to 1. people using devices without Android Market (such as AOSP Android tablets) and 2. people outside those few countries where Android Market offers paid applications?

Holy non-sequitur Batman! Lots of free stuff does not rely on tracking you for adds. Some of it does not even have adds. Busybox does not seem to do that, nor does the linux kernel.

I don't know about Asia, but gasoline gauges are calibrated differently in cars for the United States market compared to cars for the German market due to different expectations among drivers. A car sold in the United States that has started to show empty still has enough gas to get to a gas station, while on a car sold in Germany, empty means zero, and the engine will stop. Likewise, standards for how to visualize battery charge may differ per region.

You can either check language, or stop fucking coddling stupid people. Empty should fucking mean empty.

Those aren't Android apps (1)

tepples (727027) | more than 3 years ago | (#36239120)

Holy non-sequitur Batman! Lots of free stuff does not rely on tracking you for adds. Some of it does not even have adds. Busybox does not seem to do that, nor does the linux kernel.

But is either BusyBox or Linux primarily designed to be used as an application within the Android operating environment? There are a lot of applications that are either paid or ad-supported on all platforms where they exist. Many of these include single-player games with original scenarios, a class of application for which I haven't yet seen an effective business model that doesn't involve ads or payment. Angry Birds for Android, for example, has both paid and ad-supported versions on Amazon Appstore.

You can either check language

This works only to the extent that the expectations remain the same across all markets that speak a given language. It can't tell the difference between, say, expectations in Canada and expectations in Great Britain or Australia.

Re:Those aren't Android apps (1)

h4rr4r (612664) | more than 3 years ago | (#36239288)

I do use busybox on android, is that enough for you?
Angry birds indeed does operate that way. It could also just be like angry birds RIO which the whole game is an add. Lots of options.

Looking at languages on my phone now, English(Canada), English(India), English(New Zealand), English(South Africa), English(United Kingdom), English(United States) all exist. I would assume we can safely say Australia and New Zealand are the same damn thing. Languages spoken in different countries even though they claim to be the same are not and the phone language settings recognizes that. Either way you app needs to be able to handle the user being inside without wifi access, or him having a GPS location off shore or at Antarctica.

Re:Those aren't Android apps (0)

Anonymous Coward | more than 3 years ago | (#36239528)

Why does being primarily designed to be used in Android mean it needs to be paid or ad-supported? I can get shitloads of free software (free, not ad-supported) on Windows, Mac or Linux, but these same kinds of applications are begging for money when people write them for phones.

CM nightly builds... (0)

Anonymous Coward | more than 3 years ago | (#36239098)

First, I run Cyanogen, but not one of the latest nightly builds. I may give it a try later today and report how well it works.

Be aware that the latest nightlies for certain brands and models of handsets might be buggy as hell.

For instance I have an HTC Desire BravoC and the latest nightly build of CM7+ I can run without serious problems is number 72 (May 14th), even though they're up to #85 today.

For this particular handset, #72 is truly golden :-D My battery life has easily doubled with this build.

Re:So That's What Slashdot Is Today (2)

tepples (727027) | more than 3 years ago | (#36238662)

How could an app developer program around this fine-grained control? Even if he could make sure tha the program failed gracefully when certain permissions were changed, key functions in his app could no longer work.

// This is pseudocode.
try {
doSomethingRequiringPrivileges();
} catch (SecurityException e) {
alert(appName + " cannot retrieve updated listings because the privilege to connect to the Internet was declined at install time.");
}

Re:So That's What Slashdot Is Today (1)

h4rr4r (612664) | more than 3 years ago | (#36239082)

So then your app never works when you have no internet access? Because the app is not going to know if it was bocked or there just is no access available. You are not going to get a security exception, just no internet access.

Display cached ads for a week (1)

tepples (727027) | more than 3 years ago | (#36239226)

So then your app never works when you have no internet access?

Do you mean on a device that has never had Internet access even once? You need Internet access to download from Android Market or Amazon Appstore in the first place. Or do you mean on a device that has only intermittent Internet access? Some of these ad-supported programs have as their express purpose to interact with a service on the Internet. How well does, say, the official eBay app or the official Twitter app work without Internet access? Others, such as an e-mail client, can work offline, but the data in them becomes out of date after a week or so. Such apps would display cached ads for a week and then ask to be synchronized before running again.

Re:Display cached ads for a week (1)

h4rr4r (612664) | more than 3 years ago | (#36239376)

Fine so then you cache adds great, but that is not what most people want to block. What they really want is to give the advertisers a fake phone number, a fake location, a contacts list that only includes Ben Dover and Harry Baals, and a sampling of SMS messages that include nothing but rude phrases about advertisers.

Ads are not the problem, the issue is the amount of information the advertisers want before they serve them.

Local service businesses (1)

tepples (727027) | more than 3 years ago | (#36239632)

a fake phone number

The problem here is that the "phone state and identity" privilege is too broad. I've read [androidforums.com] that an application that plays audio needs to know that a call is coming in in order to know when to pause playback. And for those applications without a name and password, what unique user identifier do you recommend other than the device's serial number, which the same privilege appears to cover?

a contacts list that only includes Ben Dover and Harry Baals

At least Harry Baals would be correct for my region.

Ads are not the problem, the issue is the amount of information the advertisers want before they serve them.

Say a barber operates in Fort Wayne, Indiana. Haircuts can't be given over mail, phone, or Internet, so the barber only wants to show his message to possible customers in the Fort Wayne area. That's why sponsors want coarse location. And an advertiser wants to know how many unique viewers saw the message and how many impressions per viewer, hence "phone state and identity".

Re:So That's What Slashdot Is Today (1)

datapharmer (1099455) | more than 3 years ago | (#36239850)

check for update. If update check returns a value, check internet: if no internet give privileges message. Otherwise sleep.

Re:So That's What Slashdot Is Today (1)

segin (883667) | more than 3 years ago | (#36238708)

Sounds like you didn't put a lot of thought into your take of the situation, and are trying to push a biased, uninformed opinion. Let me inform.

First of all, a fine-grained permission system like this is nothing new. BlackBerry OS has such a system, where permissions can be granted and revoked on-the-fly, and at any time. It's also worth noting that this is a feature currently unique to CyanogenMod, and not on most people's Android devices. This will thus have no effect for most Android users.

Secondly, it's not like average Joe Moron is going to be using this fine-grained permission control system. Most average users will never worry about fine-grained permission controls, nor will they ever worry about the security implications of the far-reaching permissions that apps ask for as it is, and on the rare occasion that they stumble into an unrecognizable screen or menu, average Joe Moron will have his usual reaction of shutting down his reasoning and logic skills, followed by mashing everything in sight on the phone until something recognizable appears. If anything broke during the course, the user would simply assume he broke it himself.

Thirdly, if an app has code to gracefully failed when permissions were no longer available, then the app would also be able to display an alert or dialog to the user indicating that the permissions required are absent and the ramifications to the user (such as what features are now disabled, or any new limitations arising from lack of permissions, etc.). They won't just "break" and have droves of average users turning in bad reviews and making apps not sell. Y'know, the average users that rooted their phones, installed CyanogenMod, and then started setting fine-grained permissions on their apps. Yeah, those average users.

Re:So That's What Slashdot Is Today (1)

cheeks5965 (1682996) | more than 3 years ago | (#36239740)

Sounds like you didn't put a lot of thought into your take of the situation, and are trying to push a biased, uninformed opinion.

I'm not trying to flame here or push a biased, uninformed opinion... this is what I really think, and please respond if you disagree. That said... [puts on flak jacket]

The permissions paradigm on stock android sucks. It's too coarse grained and does not give the user any information to make an informed decision. There may be an app that legitimately requires your location, say a mapping app. But it may also be using your location for nefarious purposes. No way to know!

The cyanogen mod proposal is better in that it gives an advanced user more control, but it still doesn't give any information on why an app needs a permission, so aside from obvious cases (why does a wallpaper app need to know my location) you can't make an informed decision. See the map example above. So while CM proposal is better, it doesn't solve the underlying problem.

[zips up flak jacket] Isn't a better approach for somebody who can examine the innards of an app to vet the app and make sure it doesn't do anything nefarious? It is not perfect, but they are making an informed decision that the user cannot make. Further, the app would have more restrictions on the system resources it can access, and the user can still turn off location access. This would require all apps to go through a single gatekeeper for vetting, and would not allow sideloading.

This sounds like a much better security model to me, for "casual" users and experienced users alike. Thoughts? [puts on helmet]

Re:So That's What Slashdot Is Today (1)

MadKeithV (102058) | more than 3 years ago | (#36238754)

You know, that sounds like the argument Microsoft developers were making for years and years, until with Windows Vista Microsoft finally admitted that "run all apps as admin" was a lousy idea and implemented UAC (and there was much wailing and gnashing of teeth).
App Developers should write their apps to use the smallest possible amount of permissions to provide the user experience needed, instead of performing a permissions "land grab" just in case. The default should be "you don't have access to anything", and getting more access should require asking really really nicely.
If the app crashes / shuts down / otherwise fails miserably because it's trying, for example, to write temporary files to a system folder, or anything else that should NOT be expected of a well-behaved app, the app developer deserves every single last awful review they get. Getting to the point where developers actually think about that stuff requires transitioning through a period of pain - just like the Windows Vista failure which actually turned into a success by changing a few colours and calling it "Windows 7" (slight exaggeration possible ;-) ).

Re:So That's What Slashdot Is Today (1)

tepples (727027) | more than 3 years ago | (#36238948)

App Developers should write their apps to use the smallest possible amount of permissions to provide the user experience needed

However, a user experience that does not include the end user paying real money to the developer often must include display of messages from sponsors. This in turn involves phoning home to see which companies have sponsored use of the application by users in your geographic area. Therefore, coarse location and Internet access are a given in a lot of free applications.

Re:So That's What Slashdot Is Today (1)

Anonymous Coward | more than 3 years ago | (#36239696)

No. A user experience that does NOT require either paying money or watching ads. PCs are full of genuinely free applications. There's no reason that phones can't have the same.

Re:So That's What Slashdot Is Today (1)

L4t3r4lu5 (1216702) | more than 3 years ago | (#36238498)

I don't install apps which ask for permission to anything I don't see it requiring access to. I only install apps which require Internet Access as they are ad-supported, and that is a condition of using the app for free.

There are many apps which I have "missed out" on using because of this policy, but I'll be honest here; I don't feel like I've missed anything at all.

This fine-grained control is seriously making me consider voiding my warranty, though.

Sounds pretty airtight to me. (1)

exploder (196936) | more than 3 years ago | (#36238556)

Because it would be impossible for a malicious app to access anything else through its own "high-score" URL, right?. Or maybe I'm misunderstanding what you have in mind with this?

Re:So That's What Slashdot Is Today (1)

GIL_Dude (850471) | more than 3 years ago | (#36238210)

Most notepad apps sync to cloud servers. So they would still require "internet" access, which means the ads would not be gone. The biggest problem with being able to remove permissions is that people will use that to try to get rid of in app advertising. That in turn may cripple app functionality. Not a problem for technical users, but for normal users that is not a good experience. For developers, it means less revenue. For these reasons it is doubtful that Google would adopt this model of "you asked for x but I only gave you y".

Re:So That's What Slashdot Is Today (1)

Riceballsan (816702) | more than 3 years ago | (#36238404)

All you need is a simple "warning this app may not function correctly if you deny these rights, if the app does not work you will need to either add these rights or remove the app"

Re:So That's What Slashdot Is Today (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#36238334)

Sounds like a good way to break apps. The tacit assumption here is that apps are asking for more permissions than they need. This seems pretty paranoid, why not just use the app as the author intended or else find some other app that conforms more to your expectations ?

Re:So That's What Slashdot Is Today (1)

0racle (667029) | more than 3 years ago | (#36238406)

I went looking for a better battery display then I had on my CM7'd nook. Every one I looked at requested at least full network access and many had that and local storage access. There is a difference between paranoid and realizing that to do a job a battery widget does not need to talk to the outside world.

Evidence points to Android developers acting like poor Windows developers, expecting and asking for full permissions always instead of doing the right thing and asking for the absolute least amount of privileges needed.

Re:So That's What Slashdot Is Today (0)

Anonymous Coward | more than 3 years ago | (#36238562)

Because it is the norm rather than the exception for an app to demand a metric asston of permissions, so the developer can sell loc info, even what is on the user's contacts.

Droidwall is good, but being able to keep an app out of the contacts or off the GPS is an important privacy tool.

Re:So That's What Slashdot Is Today (1)

tepples (727027) | more than 3 years ago | (#36238840)

why not just use the app as the author intended or else find some other app that conforms more to your expectations ?

In a lot of cases, the developer of the application has a monopoly on a particular interaction, through either an existing business relationship, a copyright, a patent, or a trademark. For example, are users expected to change banks if a given bank's online banking application for Android has such problems? Are users expected to become fans of a different sport if a given sport league's application for Android has problems?

Re:So That's What Slashdot Is Today (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#36239348)

You could argue that if there's a problem of trust between you and an organization you shouldn't be running any code from them at all. And these kind of controls might actually stimulate such an organization to ask for the broadest possible permissions figuring power users will tune them down themselves and they can still profit from the ignorant and the lazy.

Re:So That's What Slashdot Is Today (0)

Anonymous Coward | more than 3 years ago | (#36239132)

Because it's practically EVERY program that asks for these permissions. So your second option (find another) is quite impractical. The first option (deal with it) doesn't sit very well with people who use these devices for accessing personal information like emails, site accounts, SMS, etc.

Re:So That's What Slashdot Is Today (1)

Dr_Barnowl (709838) | more than 3 years ago | (#36238380)

The reason it's this way around is because you can automatically audit which parts of the API the application calls, and thus which permissions it requires to perform all it's functions.

What you can't audit is how the application will respond to having permissions denied - the application may well crash, because it will be receiving "permission denied" exceptions that it was not previously expecting to receive. Since the only way to check this is to have someone look through the code, it's not suitable for an app store with a high publish rate.

A reasonable way around it would be to have feature plugins that installed separately - and demanded only the permissions they required. This would enable the user to control their risk profile while still allowing the core app to function.

Problem is, the app developers don't want the extra work to do this and the app consumers don't want to have to think about it.

Unknown Lamer? (-1)

Anonymous Coward | more than 3 years ago | (#36238130)

Who the fuck is Unknown Lamer? Is this some Taco sockpuppet? If you pull down his pants and his has a penis smaller than that of a toddler's I guess we'll know the truth.

Not gonna happen in stock Android (5, Insightful)

Anonymous Coward | more than 3 years ago | (#36238198)

This feature will never come to stock Android. Google makes their money from Android by delivering ads, which is what pays for all those free apps. If I could download a free app and block it's ability to connect to the internet, I instantly block the ads. You can like it or hate it, but the fact is this ability would cripple the entire current Android ecosystem.

Re:Not gonna happen in stock Android (2, Insightful)

SharpFang (651121) | more than 3 years ago | (#36238322)

There is still option of Google separating "obtain targetted display ads" permission from "Full network control"+"Phone location". Making the "ads" permission unblockable.

I really am not happy that an app which does require access to my local filesystem can simultaneously send its entire content to a remote server and let the author track my location - when all I consent for is to display ads relevant to my city.

Re:Not gonna happen in stock Android (0)

Anonymous Coward | more than 3 years ago | (#36238342)

True, but cyanogenmod mean's root anyway, there you could remove add's much easier, the program is even in the market...

Re:Not gonna happen in stock Android (0)

Anonymous Coward | more than 3 years ago | (#36238374)

That's what people were saying about an ad-blocked for Google Chrome...

Re:Not gonna happen in stock Android (-1)

Anonymous Coward | more than 3 years ago | (#36238546)

There is already a program on the android market that does this it is called "adfree" but you need a rooted phone to use it. I could see android sometime allowing the user to have root control for some phones (would be like a check to allow root access) but for general users won't even know what to do with it.

Re:Not gonna happen in stock Android (5, Informative)

PReDiToR (687141) | more than 3 years ago | (#36238698)

You mean like installing Droidwall [appbrain.com] does?

It's in the market and on XDA-Devs.

If you root you can use AdFree [appbrain.com] too.

Re:Not gonna happen in stock Android (1)

Anonymous Coward | more than 3 years ago | (#36239214)

DroidWall requires root so the people capable of running it aren't in the "normal user" category. So, not really a stock setup at all.

Oops (1)

PReDiToR (687141) | more than 3 years ago | (#36239676)

Yeah, my bad.

Droidwall requires root too.

In case people are filtering ACs.

Re:Not gonna happen in stock Android (2, Insightful)

poetmatt (793785) | more than 3 years ago | (#36238700)

That's not crippling the android ecosystem, that's a benefit and adds value to the system as a whole. All these developers who act like they magically never existed before they made ad-supported apps can shove it and go back to the reality of : ads were never welcome, and developers can live without ad revenue.

Re:Not gonna happen in stock Android (1)

Anonymous Coward | more than 3 years ago | (#36238740)

Doesn't mean we have to like it. Thus, Cyanogenmod.

Maybe people wouldn't mind as much if it was more secure and less insidious. I mean, I don't mind doing stuff like surveys and whatnot in exchange for services, I might even agree to let them collect *some* data. What I don't like is dropping $200 on a phone, not having admin access on it and this idea that all of these guys have a *right* to any and all of my information. Plus, they take advantage of users who simply don't know any better.

To top it off, we're supposed to trust them that nothing is going to go wrong. This year has seen a lot of "nightmare scenarios" overcoming what should have been "reasonable" safeguards (Fukushima, Sony getting hacked, etc). Can you image how screwed the world is if Google or Apple ever get hacked? I'm sorry, but I'm not willing to trust them with that kind of stuff, least of all when they're taking it without my consent.

Re:Not gonna happen in stock Android (0)

gtbritishskull (1435843) | more than 3 years ago | (#36238742)

Or the developer could write the app so that if it can't connect to the internet to get ads, then the app doesn't work (or only work for a limited amount of time, ect.). The ecosystem will adapt.

Re:Not gonna happen in stock Android (0)

hierophanta (1345511) | more than 3 years ago | (#36238764)

i pray for the day that we stop using the term 'ecosystem'

Re:Not gonna happen in stock Android (1)

turkeyfeathers (843622) | more than 3 years ago | (#36239840)

You just used it again.

Re:Not gonna happen in stock Android (0)

Anonymous Coward | more than 3 years ago | (#36239700)

If you define a mutated slime mold in a waste dump as a "ecosystem" then yes. ;)

Because that's what ad-supported information creation services are.

Seriously, that was the stupidest thing Google did (0)

Dr. Manhattan (29720) | more than 3 years ago | (#36238212)

There's no reason they couldn't have let the user set what permissions an app could have. Even if they granted all requested permissions by default, they could allow the user to restrict them after installation. If an app didn't like that, they could still choose to refuse to work.

I'm sure the carriers had some input on that lapse.

Re:Seriously, that was the stupidest thing Google (5, Insightful)

CharlyFoxtrot (1607527) | more than 3 years ago | (#36238424)

Sounds like a headache for developers: "these are the permissions you can ask for, but it's not sure they'll actually be granted." Then you'd have to build in checks absolutely everywhere because you can't rely on anything. Sounds more like a compromise position than anything malicious to me.

Re:Seriously, that was the stupidest thing Google (2)

maxume (22995) | more than 3 years ago | (#36238488)

Or just check at startup and refuse to work at all if the permissions that the developer deems necessary are not available. I imagine that would be a common method of dealing with it, with things eventually reaching the point where developers bothered to ask for minimal permissions and requested that Google create new permissions where users were reluctant to grant broad rights to an app (the latter would happen less, most users aren't going to bother fiddling so much).

Google could avoid a lot of headaches by hiding it behind some preference like "Use Default App Permissions" or "Manage Advanced Permissions" or whatever.

Re:Seriously, that was the stupidest thing Google (0)

Anonymous Coward | more than 3 years ago | (#36238770)

Or just check at startup and refuse to work at all if the permissions that the developer deems necessary are not available.

Kind of like when you install an app, and the system prompts you to allow or deny its installation after viewing a listing of permissions it requires?

Re:Seriously, that was the stupidest thing Google (1)

Dr. Manhattan (29720) | more than 3 years ago | (#36238500)

Set up an API that lets apps query what permissions they actually have. They can set up fallbacks (including "screw you, I'm taking my marbles and going home!") if they choose, right as they're initializing.

Re:Seriously, that was the stupidest thing Google (1)

Anonymous Coward | more than 3 years ago | (#36239034)

Your request was in Android since the beginning. Apps CAN request more permissions (and crash if failure is unhandled). Manifest-listed permissions merely grant the app additional privileges at execution time.

GP was stating that programmers would never handle all the possible permutations of missing permissions, and he's right IMO. Look no further than Windows where 99.9% of applications completely ignore all error codes for WinAPI calls.

Choose between the two: (a) fine-grained permissions model (Android), (b) user configurable permissions (iOS). A combination of the two will never exist because it's too complex for users and app 'programmers' alike.

Re:Seriously, that was the stupidest thing Google (1)

Dr. Manhattan (29720) | more than 3 years ago | (#36239818)

GP was stating that programmers would never handle all the possible permutations of missing permissions, and he's right IMO. Look no further than Windows where 99.9% of applications completely ignore all error codes for WinAPI calls.

So... developers are bad coders, and therefore we should give them free reign over our privacy?

Re:Seriously, that was the stupidest thing Google (0, Troll)

koolfy (1213316) | more than 3 years ago | (#36238506)

Then you'd have to build in checks absolutely everywhere because you can't rely on anything.

You mean.... like what every good programmer should do, to build stable and reliable code ?

Re:Seriously, that was the stupidest thing Google (1)

Xugumad (39311) | more than 3 years ago | (#36238782)

There's a point where it becomes absurd. I don't riddle my code with:

assert 2 + 2 = 4;

because it would be silly to check that the processor is still adding correctly, it's a fundamental assumption. In the same way, I don't think it's unfair to expect that if my app indicates it needs location access, that it can get it. I'm happy that I _need_ to check if location is enabled currently, and handle that the location service may be Wifi or GPS or something else based, but checking things the API told me were true seems a bit of a waste of my time...

Re:Seriously, that was the stupidest thing Google (1)

koolfy (1213316) | more than 3 years ago | (#36238890)

2+2 = 4 is an "internal" operation. It should obviously not fail.

"I need the GPS to give me a location" is a call to an external component (much like accessing internet, opening a file, user input), and failing in this external component, or lack of response should be handled.

Never trust external input.

Re:Seriously, that was the stupidest thing Google (1)

Xugumad (39311) | more than 3 years ago | (#36239334)

Ah... I should explain a little further. When my app asks for location data, it hands over a listener for that data. If the GPS is unavailable, that listener is never called.

If my app asks for location data and does not have permission, then an exception is thrown as if my application is requesting access to something its manifest does not describe it as needing. That's a fairly major difference...

Re:Seriously, that was the stupidest thing Google (1)

h4rr4r (612664) | more than 3 years ago | (#36239410)

In this case that is not what happens. It instead gives you a fake GPS location. At least that is the end goal. Your app can't tell if this location is real or not.

Re:Seriously, that was the stupidest thing Google (1)

Xugumad (39311) | more than 3 years ago | (#36239536)

I once accidentally mangled the GPS location in my app and relocated to a couple of kilometers off the cost of Somalia...

Re:Seriously, that was the stupidest thing Google (0)

Anonymous Coward | more than 3 years ago | (#36239524)

2+2 = 4 is an "internal" operation. It should obviously not fail.

Would you mind drawing the line between "internal" and "external"? I'm confused. In what way is using a math processor different from using a GPS radio, both of which look equally internal to my Nexus One to me? I mean, I don't see a wire coming out of my phone to a GPS chip; it's assumed that's built in to the phone. Same with the cell/wifi radios. Was "2.2 * 2.2 = 4.84" an exotic "external" operation back in the days of explicit floating-point co-processors? And what if I used ASM calls to do math as opposed to letting the compiler or runtime potentially rearrange what I was doing? Would that be more internaler? Is there a limit to what sorts of math functions are "internal"? Is sqrt() "external", despite it being a pretty basic standard lib call?

Seriously, there's a point at which you have to assume parts of the supplied API are to be considered "internal". It's a waste of time otherwise.

Re:Seriously, that was the stupidest thing Google (1)

ChrisMP1 (1130781) | more than 3 years ago | (#36239618)

Would you mind drawing the line between "internal" and "external"?

Sure. Does it result in a system call?

Re:Seriously, that was the stupidest thing Google (1)

h4rr4r (612664) | more than 3 years ago | (#36238898)

So what does your app do when the phone is indoors and does not have wifi access?

At work, unless I turn the wifi on I have no valid location data. I still expect mapping software to let me move the map around myself.

Re:Seriously, that was the stupidest thing Google (1)

Xugumad (39311) | more than 3 years ago | (#36239298)

We're using it to determine distance to a range of locations, so nearest can be presented to the user. The options are presented without distance information, and if no distance is available that simply doesn't change.

Re:Seriously, that was the stupidest thing Google (1)

Captain Spam (66120) | more than 3 years ago | (#36239378)

So what does your app do when the phone is indoors and does not have wifi access?

At work, unless I turn the wifi on I have no valid location data. I still expect mapping software to let me move the map around myself.

If your app is indoors and has no wifi access, LocationManager won't give you any updates. Plain and simple. But LocationManager is still accessible, you can still make calls to it, you can still get the previous known location (for whatever good it is), and you can still register for updates for when you DO get a signal back. It may be never, but LocationManager is still accessible.

If the permission hasn't even been granted, you get fatal exceptions thrown back at you because, as it says in the Android API, it's expected that A) the developer request permissions in the manifest (which are presented to the user at install time) before using calls that demand them, B) the user accepted these permissions when installing the app, and C) the system won't arbitrarily pull permissions out from under the developer at runtime.

C is the important one. I'd say that if the system suddenly decided that an installed app didn't have the permissions it claimed it needed BUT was somehow still installed (instead of, say, just uninstalling the problematic app you apparently don't trust), it has a perfect right to crash horribly, as that breaks the contract of the API. If you stated that your app required permission before installation AND the app was installed, you have that permission. End of story. It prevents absolutely absurd cases like the GP's example of being forced to assert on absolutely everything (yes, even if they're seemingly rudimentary functions and not explicitly specially-named method calls, basic math IS a part of an API, unless you plan on doing raw ASM/machine code/fabricating the processor yourself). A LOT of Android calls require permissions. Having to assert those on every single call or exception-check every Activity/Service lifecycle method is simply ridiculous, needlessly increases code overhead, radically increases execution time, breaks every single app out there, and is purely not needed in a modern development environment.

Re:Seriously, that was the stupidest thing Google (1)

h4rr4r (612664) | more than 3 years ago | (#36239434)

In this case you get the appearance of the former case not the latter. It may well just give you a predefined fake location. Removing permissions surely would cause that issue, but the article indicates it fakes at least some of this data.

Re:Seriously, that was the stupidest thing Google (1)

Dr. Manhattan (29720) | more than 3 years ago | (#36239772)

If the permission hasn't even been granted, you get fatal exceptions thrown back at you because, as it says in the Android API, it's expected that A) the developer request permissions in the manifest (which are presented to the user at install time) before using calls that demand them, B) the user accepted these permissions when installing the app, and C) the system won't arbitrarily pull permissions out from under the developer at runtime.

Of course... what I was explicitly suggesting was not making promise C in the first place.

Were I traveling back in time and influencing Android's design, I would have had the manifest request permissions. Then, at startup, the app could check what permissions it actually has. This allows graceful fallback - perhaps the user doesn't have (or want) a Facebook account, so the app doesn't need to be able to get accounts or contact info. Other parts of the app can still function just fine.

On the the other hand, if the user denies a permission the developer deems crucial, the app can detect this and put up a note - "Bad user! No game for you until you let pull ads from the net!"

Re:Seriously, that was the stupidest thing Google (1)

KlaymenDK (713149) | more than 3 years ago | (#36238536)

There are so many types of Android devices out there, developers have to factor in hardware variance anyway -- and the OS helps with that. There's no reason the same could not be done for permissions. In most cases, it wouldn't be anything a try/catch couldn't handle.

Of course, this would not mean that end users would have a new Big Stick to wave around, developers could easily pick up one of their own -- developers are free to respond to a denied permission by saying "sorry, no ads for me, no game for you". This would be a nice way to balance things out so that nobody gets screwed unless they too screwed around.

Re:Seriously, that was the stupidest thing Google (1)

h4rr4r (612664) | more than 3 years ago | (#36238872)

You should be checking basically everything, ever hear of try and catch?

What would you do if the device just did not have a network connection? Or if it was a new phone and had an empty address book, or no emails yet?

Re:Seriously, that was the stupidest thing Google (1)

Timmmm (636430) | more than 3 years ago | (#36238940)

A much better approach is MockDroid, which just fakes the results of operations for which you have been denied permission.

It works with existing apps and doesn't crash them.

Re:Seriously, that was the stupidest thing Google (4, Informative)

h4rr4r (612664) | more than 3 years ago | (#36239138)

That is what this does. You ask for contacts, you get an empty contacts. You try to use network and sadly there is just is no network connection at all now.

Re:Seriously, that was the stupidest thing Google (0)

Anonymous Coward | more than 3 years ago | (#36238560)

The stupidest thing Google could do is catering to the 1% nerd segment when designing app policies and user controls. Fine-grained & mutable permissions will never take off on a consumer-marketed device/OS.

Re:Seriously, that was the stupidest thing Google (1)

brainzach (2032950) | more than 3 years ago | (#36239324)

Restricting permissions will block ads and break programs. It will take away a source of income from Google and its developers and make the Android OS more buggy.

In properly designed apps, the permissions are there for good reason. Taking away a permission will most likely cause the program to lose functionality, cause force closes or eat up battery life.

There could be some cases where you could block a permission setting and get away with it, but 90% of the population won't be able to figure it out correctly and will instead complain about why their phone is so buggy. In these cases, a good app would have an option in the settings menu to limit things like network access.

Re:Seriously, that was the stupidest thing Google (1)

Threni (635302) | more than 3 years ago | (#36239446)

All Google can do is let you set your desired permission, and then not let you install/run apps which required the blocked permissions. This mod may have its uses but it absolutely will cause problems for certain combinations of user/phone/app.

Context: Android (1)

Chris Pimlott (16212) | more than 3 years ago | (#36238232)

I had no idea what this was about until I read the tags. Context please, editors! Thanks, taggers.

Re:Context: Android (2)

Azmodan (572615) | more than 3 years ago | (#36238268)

There is also a "little green robot" next to the news to indicate that this is an Android related story. Hovering it says "Android".

Re:Context: Android (1)

Anonymous Coward | more than 3 years ago | (#36238300)

More to the point, if he has an Android phone and never even *heard* of CyanogenMod (even if his phone isn't supported), he must have been living under a rock. If he doesn't own an Android phone AND never heard of CyanogenMod, then he's not the intended audience of this article anyway.

Re:Context: Android (1)

mdm-adph (1030332) | more than 3 years ago | (#36238336)

Yes, but there was no icon to indicate that this was a "story." Without the tags, most users would probably have been cast adrift.

Re:Context: Android (0)

Anonymous Coward | more than 3 years ago | (#36238412)

Hi, submitter here. I couldn't come up with a title that would fit in the tiny ass title box, so I decided to go with tags and an URL to Cyanogenmod instead, as well as having "Android" as part of the title. Unfortunately, that led to a pretty bad title that got edited away.

If you care about Android at all, you should know about Cyanogenmod anyway.

Neat (0)

Anonymous Coward | more than 3 years ago | (#36238240)

This is the only thing keeping me on Blackberry - which has Allow/Prompt/Deny for every permission you can think of (even going so far as asking you for each website apps try to connect with)

If this keeps up, maybe I can finally drop the BB and get a smartphone designed for this decade.

Re:Neat (-1)

Anonymous Coward | more than 3 years ago | (#36238304)

This is the only thing keeping me on Blackberry - which has Allow/Prompt/Deny for every permission you can think of (even going so far as asking you for each website apps try to connect with)

If this keeps up, maybe I can finally drop the BB and get a smartphone designed for this decade.

1992 called and wants their blackberry back...

Facebook Apps (2)

wisnoskij (1206448) | more than 3 years ago | (#36238288)

They need this feature for Facebook Apps.

Awesome! (3, Interesting)

Daetrin (576516) | more than 3 years ago | (#36238298)

That would seriously tempt me to try out Cyanogen if Google doesn't implement something like it in the near future, even though i've already got an unlocked Nexus. There are a number of otherwise great apps that i haven't updated in months because they decided to add Facebook integration, so "of course" they need access to my account details now. Sorry, not gonna happen.

Re:Awesome! (2)

jittles (1613415) | more than 3 years ago | (#36238390)

I switched to Cyanogenmod for Gingerbread and I haven't looked back since. I love it. I am thrilled about this feature and am now downloading the nightly as we speak! I am very excited.

Re:Awesome! (2)

Lunix Nutcase (1092239) | more than 3 years ago | (#36238400)

And when you block that the app is just going to crash. Have fun when most of those apps no longer work.

Re:Awesome! (1)

icebraining (1313345) | more than 3 years ago | (#36238612)

most

Citation needed.

Sure, some will; for those the user has the option of running them with the default permissions or uninstalling. Whether they're "most" or just a small number remains to be seen.

Re:Awesome! (1)

h4rr4r (612664) | more than 3 years ago | (#36238692)

Depends on what you block. If you block network, how does the app know that you just don't have a network connection right now?

I use my phone without data when I go to Canada. No way am I paying verizon $30 for 75MB.

Re:Awesome! (1)

monkeyhybrid (1677192) | more than 3 years ago | (#36238804)

From the article:-

"Rather than denying permissions outright, which would surely result in mass force closes, the new feature fakes some of them (phone state, id for starters) in a completely transparent manner."

I'm not sure what services it can fake at the moment, but things like contacts could be done well. Just return an empty contacts list instead of the real one and the app should deal with that ok without a force close. I'm sure you could do similar with a lot of things.

Re:Awesome! (0)

Anonymous Coward | more than 3 years ago | (#36238806)

I rather have an app crash then access my personal data.

The XBMC remote is a good example, it requires a shitload of permissions, like "READ_SMS" for example. Why would it need to read my SMS? Well, for an optional feature.
See: http://code.google.com/p/android-xbmcremote/wiki/Permissions

So no need to grand the permission if you don't require the feature. This seriously makes me think about installing Cyanogenmod. Any crashing apps could be solved by a "predend you have permissions but functions return fake data" option. Want my GPS location? Ok, I'm in the middle of the atlantic, want my phone nummer, ok it's 555-555555.

Re:Awesome! (1)

gtbritishskull (1435843) | more than 3 years ago | (#36238830)

Blocking an app's ability to use Facebook integration would probably behave in one of two ways. Either it would act as if you are not signed into a Facebook account on your phone, or that you don't have the Facebook app installed. If either of these cause an app that didn't previously have Facebook integration to crash, then you are talking about some pretty shitty coders.

It never made sense? (0)

Anonymous Coward | more than 3 years ago | (#36238330)

"This is the biggest feature I've missed from Symbian — it never made sense to me why the permissions system didn't put the user in control from the first release."

Because it would go something like this: "To install your smilies, go into User Preferences and change the setting to 'read/write for all users', then run this unsigned program you downloaded from some sketchy corner of the Internet. Enjoy! [PS: your phone is now rooted and will automatically route all numbers through our $5/minute call center in Hackistan]"

For knowledgeable users, full control over permissions makes sense. For novice users, maybe not.

Re:It never made sense? (1)

icebraining (1313345) | more than 3 years ago | (#36238654)

This is a feature to give apps less permissions. By default they have all they ask for. How does that make the system less secure for novice users?

Symbian went too far (2)

pmontra (738736) | more than 3 years ago | (#36238354)

Foreword: I've got an old Nokia N70 so things might have changed a lot in Symbian.

A very annoying feature of its permission management system is that it is too fine grained and it doesn't remember user decisions across different executions of the same app. It asks me allow/deny every time I open a file or folder (imagine traversing a 4 folders hierarchy, the SD card counts as one) and that's bad enough. Forgetting my answers when I close the app is even worse. Sometimes I leave the phone on in airplane mode at night not to have to go through all those dialogs.

Android seems to have taken the opposite road. Maybe this mod implements a better middle ground.

Re:Symbian went too far (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#36238470)

Sometimes I leave the phone on in airplane mode at night not to have to go through all those dialogs.

You are coming to a sad realization. [C]ancel or [A]llow [youtube.com] ?

Re:Symbian went too far (1)

icebraining (1313345) | more than 3 years ago | (#36238688)

The same happens with my oldish E65. Having to allow Opera Mini to access the 'net every time I run it is definitively annoying.

CM Stories (0)

blackraven14250 (902843) | more than 3 years ago | (#36238466)

Enough stories about CM lately? I think we need more.

Re:CM Stories (0)

Anonymous Coward | more than 3 years ago | (#36238720)

I know, right? I'm a huge CM fan (6.1.1 on a G1 and 7.0.3 on a Nook Color), but even I was a bit taken aback by the way the title read. I couldn't help but think, "Jeez, talk about self-promotion! This is starting to read like Digg now." Rather odd. I'm not sure how I'm going to take a massive influx of users if this keeps up. Of course, the community seemed to absorb the NPR crowd just fine.

Different Trust Model (1)

Anonymous Coward | more than 3 years ago | (#36238854)

This is the biggest feature I've missed from Symbian

Different trust model, Symbian just assumes the user is an idiot and the trust is given by the signing certificate of the application. Not saying it's a good model it's just that it's emerged from a different environment from what we're seeing today.

Dancing Bunny / Dancing Pigs Problem (2)

tlhIngan (30335) | more than 3 years ago | (#36239796)

Sure this is a great addition... for power users who are infallible.

But for Joe Average and power users who fall prey to it (who doesn't?), it doesn't address the primary issue - called the Dancing Bunnies [codinghorror.com] or Dancing Pigs [wikipedia.org] problem. And it's a problem with every OS today - Linux, Windows MacOS X, Android, iOS, and others.

A user will run through many hoops to get what they want. They'll root, jailbreak, install alternative app stores, etc just to save 99 cents for an app. Even if they have to do seemingly complex tasks like install an SSH server, run SSH, type command line commands, etc. It can be amazing how much technical skill the untalented suddenly have.

And the problem is, these are the people that get pwned. Jailbroken iPhones with default SSH passwords. Android phones with botnets installed (courtesy alternate marketplaces), Windows/OS X trojans running botnets, etc. Heck, even Bender skipped his antivirus check for pr0n.

And it's a really difficult problem to solve. Even if these options were global and set reasonably, you can anticipate some app telling you it works better if you do these things to let it get the permissions it wants.

Hell, see the latest Facebook spamming trends [msdn.com] , where people are doing things like copying-and-pasting URLs or godawful long javascript blobs. We're at the point where really, the Honor System virus does exist.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...