Slashdot Mirror
Cyanogenmod Puts Users in Control of Permissions
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.
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.
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.
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.
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".
I'm sure the carriers had some input on that lapse.
PHEM - party like it's 1997-2003!
I had no idea what this was about until I read the tags. Context please, editors! Thanks, taggers.
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.
They need this feature for Facebook Apps.
Troll is not a replacement for I disagree.
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.
This Space Intentionally Left Blank
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.
-- Flame me and I will happily flame you back. Bring it!
"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.
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 ?
If all else fails, immortality can always be assured by spectacular error.
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.
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.
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"
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.
"I use a Mac because I'm just better than you are."
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.
If all else fails, immortality can always be assured by spectacular error.
Enough stories about CM lately? I think we need more.
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.
Nerd rage is the funniest rage.
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.
Finally had enough. Come see us over at https://soylentnews.org/
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.
PHEM - party like it's 1997-2003!
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 ?
Segmentation Fault in "Life, Universe and Everything" at line 42. Don't Panic.
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.
"Good news, everyone!"
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?
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
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.
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.
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.
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.
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.
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
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?
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.
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...
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?
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.
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?
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.
Segmentation Fault in "Life, Universe and Everything" at line 42. Don't Panic.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
If all else fails, immortality can always be assured by spectacular error.
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.
Demanding constant attention will only lead to attention.
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.
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.
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.
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.
I once accidentally mangled the GPS location in my app and relocated to a couple of kilometers off the cost of Somalia...
Would you mind drawing the line between "internal" and "external"?
Sure. Does it result in a system call?
<sig> </sig>
a fake phone number
The problem here is that the "phone state and identity" privilege is too broad. I've read 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".
Yeah, my bad.
Droidwall requires root too.
In case people are filtering ACs.
Do not meddle in the affairs of geeks for they are subtle and quick to anger
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.
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]
-- Flame me and I will happily flame you back. Bring it!
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!"
PHEM - party like it's 1997-2003!
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 or Dancing Pigs 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, 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.
So... developers are bad coders, and therefore we should give them free reign over our privacy?
PHEM - party like it's 1997-2003!
Those are two options, and sometimes, selecting one of them is the best thing to do. And other times, a third option (using the app as the author didn't intend) is the best thing to do.
A good computer will recognize that sometimes the owner's interests conflict with
and will always take the owner's side in this conflict.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
check for update. If update check returns a value, check internet: if no internet give privileges message. Otherwise sleep.
Get a web developer
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.
With a PC, all required hardware and software are likely paid for. But with a phone, all these cost extra money:
Fine. Tell the user why the permissions are needed. Do a get for the author's website, if it doesn't come back with a 200 ok in x number of days then don't let the app run or restrict it with a timer.
Get a web developer
PCs are full of genuinely free applications.
I have written another comment about why the presence of free software on PCs isn't a perfect predictor of the presence of free software on mobile phones.
The companies that provide the device or the company that provides the network will control the device.
If google were to implement this, how many apps *would* break because of an error on the permissions?
Maybe I'm off base on this, but if I am please correct me... It's like if Linux didn't have file system permissions the way it does now.. let's say you could write anywhere without any restrictions, and then suddenly there's an update that locked down the file system with permissions the way they are currently. Since the existing applications would try to write to where ever they would normally write, they'd hit errors.. and since the applications weren't written to handle those errors correctly, I'm guessing they would crash or hang.
It goes along with this comment in the summary:
"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"
Here's an example... the one Fedora box I have access to at a local college doesn't have any developer tools installed (no gcc, etc) and I only have regular user access. I can't rpm to install screen, etc. So I setup the same version of Fedora in a VM on my laptop and downloaded the screen source, and compiled it. I then took the binary and using a PHP script on the school box, uploaded screen to an area I had write access. I then moved it into my home folder. I went to run screen, but it crashed as it couldn't make it's socket file in the normal location as I didn't have permission. I had to go back to the VM, and set the flag for configure to tell it to use my ~ directory instead. Then it worked.
What are the chances if Google did implement this, many of the existing applications would force close/hang/crash like the quote says BECAUSE of the change in permissions the applications weren't designed to handle/work around? I'm not saying the applications SHOULD or NEED to have access to half the stuff most of them do request, but should you block one the application "needs", is it still going to run correctly? While I *love* the idea, it sounds like any initial releases of the Android OS that include such a feature will cause a lot of issues with existing applications, which would require a massive amount of updates from the developers. (and again, maybe I'm wrong on this.. and if so please set me straight :) )
I'm not sure what all your battery display does but a good reason to ask for storage access is so you can persist a log/settings in case the user uninstalls/reinstalls the application. Without sdcard write access, all of your files have to be written to the /data/data/youapphere directory and if the user uninstalls your app, those files are gone. If they are on the sdcard and the user decides later to reinstall your program, it can just pick right up where it left off. The same thing happens on Linux OSX and Windows.
The soylentnews experiment has been a dismal failure.
I would have installed Pandora except for the insane number of permissions it needs. There are a number of apps I don't mind allowing access for, when they aren't requesting phone identity and network access and contact access... There is no need for ads to know who I know.
Windows UAC didn't kill the Windows software ecosystem, everyone who isn't an idiot will survive.
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.
Although this widget requires access to Wi-Fi (to turn it on and off), it does not need any network or storage access.
Yeah, sort of like that, except the discussion is about how developers could handle users having the ability to edit permissions (like they will with this firmware build).
Basically, I'm guessing that most users won't touch them, but the ones that do will drive some positive change in getting developers to request narrower rights.
Nerd rage is the funniest rage.
I have an app on the market. Usually I have no problems supporting users on custom roms, since my app uses the standard Android libs wherever possible.
However, a few days ago I had a user complain that a new update started crashing on his device. Upon further inspection it turned out that his Android 2.2 custom rom was declaring itself as Android 2.3, and my app was crashing when it tried to call a method which was introduced in 2.3.
This to me is what's scariest about these custom roms. They can turn into support nightmares for app developers.
People complain a lot about fragmentation, but my app runs on everything from 1.5 to the most recent devices available and I never had any problem with a specific device. The few really weird issues up to now have, not very surprisingly, happened on custom roms.
As a fictitious example, a notepad may need to write on the SD card to save files and a network connection to pull ads. It should NOT need to read my GPS or network location
It would need your coarse location to know which ads to show, so that it doesn't show ads for a barber shop in Fort Worth, Texas, to residents of Fort Wayne, Indiana.
1 volt is the same all over the world
Users expect some sort of translation between voltages and "full" or "empty". Case in point: I have never seen a car whose dashboard displays remaining gasoline in litres or gallons.
I will just stick to SCUMMVM games.
As I understand it, most ScummVM games are paid. Without a copy of Maniac Mansion for MS-DOS or Atari ST, for example, you can't play Maniac Mansion in ScummVM. Most copies of Maniac Mansion that I see on eBay are the censored version for the NES. Maniac Mansion for NES almost works in ScummVM if you skip the cut scenes, but you'll need a front-loading NES console with a soldered-in CopyNES board to copy the cartridge to your PC.
If a developers aren't checking to make sure argc is greater than zero and argv[0] isn't NULL, they shouldn't be shipping production code. "Checking absolutely everywhere" should be standard programming practice, because the one time something isn't checked is the one time it will fail.
Nathan's blog
Buy a device on which to test
Practically everybody that is going to be writing mobile applications is going to have a cell phone.
My current cell phone is an Audiovox 8610 from Virgin Mobile USA, which doesn't run Android, and the phone you recommended (Nexus S) costs $549.99. Can you recommend anything cheaper? Virgin Mobile USA carries the Samsung Intercept and LG Optimus V; are those any good?
On my N900, BatteryGraph keeps an SQLite database for charting past performance.
Nathan's blog
This is completely different. It'd be more like having to check libc is installed every time a program is executed.
If all else fails, immortality can always be assured by spectacular error.
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.
I'd like to see the possibilities go one better: Lying.
Imagine a sort of "chroot" for application data: a contained environment, controlled by the actual root environment, in which exists a set of files sufficiently complete to allow the enclosed process(es) to do their thing as though they were the rulers of all they survey; but without actually giving them that power. When creating a chroot, you can either populate it with a relatively complete clone of the real root, or a specially crafted one for a specific purpose.
Being able to granularly confirm/deny individual requests by an application is a good start; but it means a significant risk that an application with break(or chose to take its ball and go home) if denied certain permissions. However, if one could define multiple(presumably hierarchically namespaced, just for neatness' sake) "data chroots" to which one could grant access(all of which would look like data roots, to the application with access) this could be avoided. Such data chroots could be constructed whole cloth, simply by manual or automatically installed definition files, or by "filters" applied to real data.
Got an application that wants your contacts for no good reason? "Grant it access" to a ficticious one consisting of generic but plausible contacts. Social Yelpcoupon 2.0ster wants your precise location data? Give it access to a filtered data chroot that only allows for city-level precision; but is based off the real location data, so that you get offers relevant to your general area.
Obviously, team google would never, in a million years, endorse such a scheme; but it would be architecturally workable enough, and give an extra weapon to those fighting pushy apps.
Comment removed based on user account deletion
Comment removed based on user account deletion
Please just stop with the gasoline / car analogy.
I concede. However, the question remains about offering haircuts in Portland, Oregon, to users in Portland, Maine.
So... developers are bad coders, and therefore we should give them free reign over our privacy?
Yes. ... no, I jest. IAASD (I am a software developer)
Seriously though, it depends on the developer -- to my dismay, some of the developers I work with put minimal effort into error-checking (even simple function return values). ...and whenever the software breaks during operational use, that usually means that I have to go back in and fix it and make it the way it originally should have been...sometimes as an emergency patch. I'm not perfect either, and I'll occasionally overlook a couple checks, but at least I try to put the effort into it. If there were to be a permission-query API as GGP had suggested, it would definitely make things easier.
That being said, I do think it's a good idea for end users to control their privacy as much as they can, so I would support user-configurable permissions.
As other comments have stated, there are currently apps available (AdFree Android, DroidWall, etc...) for root users to control some of this. This is one of the reasons that I've rooted my Motorola Droid. But then again, from what I understand, manufacturers are continually making it increasingly hard to root your phone.
I own my device, I control what it does, and how it does it. NO exceptions.
The developer of the application owns copyright in the application, the developer controls who is allowed to copy it from Google's servers, and how it may be used. NO exceptions. The application's description on the Market states that your use of the application is subject to the terms of service, available at a given URL and shown when you first start the program. These terms include a prohibition on circumventing the advertisement display. Agree or uninstall.
Requirements
**NEEDS ROOT**
Works on Android 2.0 and above.
Tested on various devices and firmwares, but not tested on Android 3.0 and 3.1 devices.
Current Features
1. Block unwanted send SMS / call phone operation
2. Block unwanted access to phone location, contacts, SMS/MMS conversation database, IMEI/IMSI/ICCID/phone number.
3. Integrated low-level firewall, no netfilter/iptables required, works on pre-froyo devices
Market Link
https://market.android.com/details?id=com.lbe.security
Maybe I'm off base on this, but if I am please correct me... It's like if Linux didn't have file system permissions the way it does now.. let's say you could write anywhere without any restrictions, and then suddenly there's an update that locked down the file system with permissions the way they are currently. Since the existing applications would try to write to where ever they would normally write, they'd hit errors.. and since the applications weren't written to handle those errors correctly, I'm guessing they would crash or hang.
Well, I think the closer analog would be starting to use SELinux after leaving it turned off for a long time.
If the SELinux profiles are properly written, and the software hasn't changed drastically since the profile was written, then it generally just works (at least with targeted mode). But if not, then you'll get all sorts of SELinux errors in the logs and the application will fail to function properly.
Wolde you bothe eate your cake, and have your cake?
Actually, I'm a software developer, too. I was just pointing out that the AC couldn't have it both ways. If developers were doing the right thing, then an API that allowed them to check for disallowed permissions on startup wouldn't be a particular hardship. On the other hand, if a developer's incompetent, then the last thing we should do is allow them any and all permissions they ask for.
PHEM - party like it's 1997-2003!
Agreed :)
It should NOT need to read my [...] network location
TheCRAIGGERS wrote:
You could use the coarse location, based off of cell towers
So you appear to agree with me but not c.r.o.c.o.
Or you could just not attempt to provide location-aware ads; many people get by with just advertising websites that offer services you may want.
A lot of websites that offer services are location-aware as well. An example of such a website is Netflix.com; ads for Netflix should not be shown outside the United States and Canada because the movie studios themselves are location-aware.
Copyright is about copying, not use.
How does an Android application get onto your device? Your device copies it from Google's server.
or I can't get a copy in the first place
This is what I meant. If you disagree, don't download the application in the first place.
A EULA is not a valid contract
How is a license agreement invalid if the terms are made available for viewing prior to the download?