CyanogenMod Adds Support For Revoking And Faking App Permissions on Android
androidpolice.com
androidpolice.com
Of course there's absolutely no evidence that any of these things are true, though I'll grant that they're valid concerns, to some extent.
It still pushes the notion that, despite being an open-source platform, Android isn't really "ours". It belongs to Google and the wireless carriers, and our ability to run our own version of a supposedly-open mobile OS is entirely at their whim.
I absolutely love CM and have been running it on my N1 for close to a year now, but it just sounds like they're too afraid of backlash to add features that could (with some refinement) really protect users.
The whole faking data thing works quite well - every app we tried with our implementation basically worked as intended (i.e. if you prevent the app from accessing the internet, everything still works apart from functionality which explicitly depends on accessing the internet), which is a nice consequence of apps being written for mobile devices where access can't be taken for granted.
TaintDroid is pretty awesome as well: http://www.appanalysis.org/
Some apps have some crazy requests that need explaining!
Does the iphone have any such granularity control for permissions? (official or unofficial)
http://www.whispersys.com/whispermonitor.html
it requires changes to the framework though, so it's only available in their own "whispercore" rom:
But what I really want is the marketplaces to allow direct apk downloads because I always want to examine the file first on an emulator.
@ck2 is performing as thorough of a verification as possible without source code access. If I were a malicious app developer, however, I might program my app to wait a week before transmitting any user data.
1) Adult-rated apps need an explicit approval after the password before they will even install. Also applies to updates.
2) On first launch, apps that want to use badges or notifications or notification sounds have to ask for approval, although it is a generic approval of all three and doesn't discuss what they would be fore.
3) Before an app can use location services (current device location), it has to explicitly ask.
1) This is pointless. If you want to block adult-apps, go ahead and do it in Parental Permissions. Especially since a lot of apps are adult because they do web stuff generically.
2) This is pointless, in my opinion, since you can't tell what they plan on doing with the alerts.
3) This works OK, although it is generally triggered after you request something location related so it feels redundant. Like, why is it asking me again, didn't I just click the location button? Does the average user understand that the prompt is coming from the OS rather than the app?
There's no easy way to add this to AOSP core in one swoop without making exceptions for legacy applications, to the point that no one would use it anyway.
I'd love to see this system evolve somehow to make permissions more granular, but it's going to be a breaking change and it's certainly not going to be implemented this way where fake data was returned. Not sure why people are shocked it works this way. I've tried to explain the breaking and problems that would occur from trying to implement this. Of course, a couple months ago when I tried to explain this, everyone here told me it was "simple" and that I just didn't understand. Oh well.
How would that not make an application crash? Additionally, returning fake data has it's own problems including at the very least integrity.
There was a discussion on Android-Developers about this (as a core OS feature), in which (I think) Dianne Hackborn (one of the Android developers) came out strongly against the idea of allowing users to choose which permissions to allow/disallow for an individual application. (Edit: I think this is what I was remembering: http://groups.google.com/group/android-developers/browse_thr...)
I think it's a good feature to have in some cases. Some applications, for example, the Yelp application, request features I'd rather not give, but I'd still like to use the application in general. It's not that I feel the applications are openly hostile - I would never trust the permissions library in that case, but I have no desire to give my contacts list to the Yelp app. This is just one example - I'm sure a lot of people would try to disable Internet on apps that use Internet solely to show ads, for example.
http://freshcomics.us/support/privacy-location-information/
In my role as a developer, I'd support a way that I could specify these details in a more standard & concise way and allow the user to enable & disable permissions as needed without having to make an all-or-nothing decision whether to install the app.
As a user, I'd appreciate it even more. :-)
In The Business, we call this "piracy". Unless, of course, the developer is an altruist who did not intend to monetize their app, but accidentally dropped in an ad window.
Like web browser ad blockers, I expect that developers will ignore this UNLESS it begins to eat into their general user base. Then will come the code libraries that try to guess whether the permissions are accurate or not (e.g. timeout on internet connectivity downtime).
Or fewer free apps, I suppose. Either solution fits the new game theory equilibrium. My money is on "Google is not going to martyr their ad-supported app developers by rolling this into their Android OS builds", with a distant second to "faux-permissions detection libraries".
If you cannot sell your product, well, maybe it is not worth running after profit. If you do not feel like sharing it for free, maybe someone else will.
I do not consider anything with advertisements (or "submit your mail adresse to get the download link") to be free. The ad publisher is getting my attention, personal data or whatever, it is not free of drawbacks for me.
Disabling parts of an application can hardly be considered piracy.
You say that you don't "consider anything with advertisements (or "submit your mail adresse to get the download link") to be free", so you consider your agreeing to these things to be your payment for the software/service/whatever, right? If so, by not viewing the ads, giving your email, etc, you're not paying the price for the product and are thus pirating it.
You use a service that charges your credit card when you use it, but you realize that you can block the call to the server that does the charging and use it just fine. Is that acceptable? It's technologically equivalent to ad blocking in reverse and blocks payment; the only difference is that the currency is USD or EUR rather than eyeballs.
So is disabling the nag screen in a shareware app piracy? What about removing the time limit from a 30 day trial?
It's a totally fair point. What's the difference between downloading a free app and blocking the ads versus pirating an app outright?
What is the kindest euphemism for people who lie about their product?
I think it would be nice if Google indicated in the market which apps are ad-supported, but I don't think it changes the fundamentals.
There are no EULA agreements that people agree to when downloading free apps.
Furthermore, when an app is 'ad-supported' it is not clear at all what agreement you have implicitly engaged in. Have you agreed to allow ads to collect data that you enter into the app itself? Is the author only receiving funds if you click on the ads? Are you morally obligated to click on the ads then? If not, how is my decision to never click on ads any different than blocking them outright? How much data from the app to the marketers is being collected? If I plan a trip with your app, are sponsoring companies receiving this information as well? Are ads simply keyword identified or are they using a profile?
Without transparency about how the ads provide funding (which actually violates Google ad words TOS) I don't see how this is a simple black and white situation. I believe most people operate on the assumption that the ads are "you click, I get paid". As a result, most people view ad supported applications as a variation of donationware. If you don't want donations to be optional, don't use this method.
You raise some really excellent points about privacy and ads that I totally agree with. But if you don't want ads in your ad-supported app, I think the only fair thing to do is not use it. In the same sense the it's only fair to pay for shareware that you routinely use, even if there's no DRM and you're not legally or functionally obligated to do so.
"Piracy" is a political term used generically to mean "people not doing what I want who should be made to obey me by force of law." It may refer to actually harmful illegal acts (bootlegging) or things that are simply not preferable for somebody's business model (watching legally obtained content on an "unauthorized" device).
It's not that I consider the word itself a troll-bait, but the misuse of it. Like other commenters already noted, there are other terms that apply to what you're complaining about. Claiming that people are "pirating" an ad-supported application seems to me like a misuse of an already widely-misused word.
On the other hand, if you're arguing that ad-supported applications should not be considered or labeled or marketed as "free", then all I can say is that dragging piracy into the discussion is not the way to support that argument. The flaw, in this case, would be in confusing the cause with effect, just like saying "It's not free because you're stealing it!"
I agree that it is entirely possible for the user see no ads in the Lite version anyway, perhaps because they actually don't have an internet connection. Similarly, it is entirely possible for Paypal to make some mistake and fail to credit my account properly for a purchase of the Pro version. My advertisers might by paying by click-through rather than views, in which case I am operating on a statistical basis and not making any money off of many of my users. Those details do not change the ethics and do not cancel out the wrongness of pirating.
(@chc suggests that I should say "morally wrong" instead of "pirating". I think that sounds kinda ad hominem, so I've stuck with "pirating".)
circumvented the trust I placed in the OS (to make the internet available for ad delivery whenever feasible)
That's not something you can or should be able to "trust" the OS to do. It's not your hardware. If you don't want "pirates" running your app, then have it refuse to run unless it can download ads. Don't pretend you have any right to dictate whether the user is allowed to disable Internet access.
There's a reason why even you, in your comment, used the word "monetize" instead of outright "sell". Mind that I'm not arguing about the dictionary definition of the word, but about the intent behind its usage.
If I went into your application and disabled or circumvented some sort of mandatory payment mechanism, I would be pirating it. If, however, I decide that I do not want to give your application permission to access Internet and your application does not object to this, then I'm just exercising my rights.
Likewise, web browser ad blockers are just my way of exercising my rights to filter the content I don't want to see, which is analogous to restricting access to certain sites on my kid's computer or, heck, changing the channel briefly while the ads are on TV.
You are allowed to decide not to give my application permission to access the internet; the Android Market actually forces you to review the permissions my app requests before allowing installation. The piracy here is that the Cyanogen mod pretends to give internet access, but lies to my application (by lying to the app and pretending that the internet is just unavailable for the moment.)
As for the "piracy" argument, the line is, as always, blurry. I guess that I could agree to calling it "piracy" if your app somehow verifies whether you have access to a resource on a server and shuts down if you don't, thus preventing me from using your app if I don't "pay" by displaying ads. The fact that I dislike that practice doesn't mean that circumventing it should not be called piracy.
The "permissions" that a user gives to the device say that the app has permission to use the Internet. The permission does not make the Internet magically 100% available. It may well never be available. All you're getting is permission to use the Internet if the Internet happens to exist.
Anyway, I know you're trolling, and that's fine. Because your opinion doesn't matter: it's my phone, my internet connection, and my open-source firmware. Your software is an invited guest. If you don't want your app to run on my phone, don't let it get on my phone. Once you've done that, it's mine to take with me into tunnels (virtual or otherwise) whenever the fuck I want, and there's not a thing in the world you can do to stop me. My house, my rules, so fuck you. Hahahaha!
I doubt that this will be as big of an issue among general consumers.
Also, why is it a bad thing for users to disable internet access on increasingly limited data plans? I know of many people who use ABP on computers with slow connections. I doubt many developers are hurting because users on slow connections aren't seeing ads on their apps.