CyanogenMod Adds Support For Revoking And Faking App Permissions on Android(androidpolice.com)
androidpolice.com
CyanogenMod Adds Support For Revoking And Faking App Permissions on Android
http://www.androidpolice.com/2011/05/22/cyanogenmod-adds-support-for-revoking-and-faking-app-permissions/
8 comments
Well I don't think CM is necessarily "ours" if you are referring to users. I would bet that every major CM contributor has their own apps in the market, so obviously they're interests lie much more on the vendor side than the user's. That's why you see here more interest in accurate data collection than in privacy.
Well, the problem isn't that Android isn't 'ours', you can still do whatever you want with it. The problem is that the hardware you buy is never really your, thereby making it more difficult to install custom android onto.
Indeed, what a shame. Well, I hope some other ROM will integrate it then.
I did something quite similiar last summer - we got it published (http://www.cl.cam.ac.uk/~arb33/papers/BeresfordAREtAl-MockDr...) but we never looked at getting it into CM. I guess they're more receptive to the idea than I expected them to be!
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.
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.
I find it interesting (but not all that surprising) that so many people developed a similar concept. The research professor I was working with this past year actually published a similar system: http://www.csc.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf
That does look pretty similiar to what we did. I've emailed Plamen about it - hopefully we can integrate all this stuff to give CM users full control over what apps do with their personal data :)
TaintDroid is pretty awesome as well: http://www.appanalysis.org/
TaintDroid is pretty awesome as well: http://www.appanalysis.org/
This alone makes my android device feel 100x safer and now I can finally start trying more apps. Google should implement this in the core asap (as well as a firewall).
Some apps have some crazy requests that need explaining!
Does the iphone have any such granularity control for permissions? (official or unofficial)
Some apps have some crazy requests that need explaining!
Does the iphone have any such granularity control for permissions? (official or unofficial)
It would be interesting to add logging shims to the APIs along with a GUI by which semi-technical users could audit apps' behaviors. Why does Game XYZ need to access the internet? To download new levels or for some evil purpose? A listing of domains it hit would be a telling sign.
whispermonitor adds a littlesnitch-like gui to android to show and filter network connections:
http://www.whispersys.com/whispermonitor.html
it requires changes to the framework though, so it's only available in their own "whispercore" rom:
http://www.whispersys.com/whispercore.html
http://www.whispersys.com/whispermonitor.html
it requires changes to the framework though, so it's only available in their own "whispercore" rom:
http://www.whispersys.com/whispercore.html
Google should implement basically everything that is on CM. They should just hire the freaking team already.
I would also like to see that developers were required to state why each permission is needed and present this to the user at install time.
But users might actually read the developers' explanations, in which case they would need to be true. If no 3rd-party verifies the permissions explanations before the app is released, then the only value is as a legal agreement between the developer and end-users. I would expect that to devolve into a 30-page EULA per app ... which has already happened, for many apps.
@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.
@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.
As a developer I've often wished for this. You can stick it in the app description but it'd be nicer if it was on the permission screen. Marking permissions optional would be helpful too.
I've seen some apps in the android marketplaces that do have descriptions which attempt to explain the permissions. I've also seen apps that have a "lite" version with much fewer permissions needed.
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.
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.
iPhone has the basic password to install things, and then beyond that:
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) 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.
And, beyond those facts, my opinions:
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?
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?
We've been over this a hundred times. Adding this sort of functionality would break potentially all existing apps. Has anyone bothered trying a nightly? I actually run them and this feature is near useless. Take away most of these permissions and apps crash and burn. It was in the API to begin with that the permissions would not be there, that's not how the manifest-declared permission system in Android was meant to work.
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.
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.
I don't understand how this makes apps crash and burn. Can you explain how does Angry Birds crashes and/or burns when it can't access the internet? Can you explain how a fart app will be broken when it returns a fake contact list?
It depends how the program was created. Programmers have to make assumptions, if one of these is broken, and the programmer hasn't 'handled' it, then the program will either crash or show bugs. Programmers do cut a lot of corners, where they feel assumptions are safe, and assuming the the permissions will be there is one of them.
I'd post logcats but I've already flashed new nightlies without the patch. The manifest method of requesting permissions in Android is a guarantee. Applications don't test for the availability or presence of permissions for things that they declare in their manifests. Because they have no reason to have to test for them. When they're not granted and the system retunrs an error or exception... it's not caught because it should, according to the API, never ever happen.
How would that not make an application crash? Additionally, returning fake data has it's own problems including at the very least integrity.
How would that not make an application crash? Additionally, returning fake data has it's own problems including at the very least integrity.
Instead of failing it should return fake data, the app never need know.
I've wanted something like this to be part of the OS, although it causes a bunch of hassles in BlackBerry (from a developer's perspective).
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.
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.
I would love it if this was combined with the UX of NoScript so that I could greenfield my perms and allow them selectively, granularly, and optionally permanently. At any rate, hopefully this is the beginning of the end of the PII giveaway.
I remember that interaction. It seems like a feature that will work really well 95% of the time and give confusing errors the other 5% of the time -- a good trade-off for techies, but would result in many confused users if it were a core OS feature ("I just thought I'd see what it did...").
This is super-neato, but what I am really waiting for is a way to fake device capabilities in the market, so I can finally use the RememberTheMilk app on my rooted gTablet!
alter your build.prop file
Don't the apps just fall over when they try to perform a revoked operation? I doubt they'd expect it
As an Android app developer, I'd totally support this as part of the native platform. While I haven't gotten an e-mail from a paranoid user asking why Fresh Comics needs their location data, I've gone ahead and done a small writeup on why my app needs the location permission, why I need that data, and what I do with it afterwards:
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. :-)
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. :-)
I can understand why fine-grained permission selection would be an onus to developers without really providing much of a benefit for the average user, but I would love seeing brief explanations under each permission ("needs internet because: downloads ads", "needs to read messages because: analyzes text").
@everybody: "This way we can disable Internet access on apps and games that are just downloading ads."
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".
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".
I agree that blocking ads means less money for developers who hope to monetize their apps that way. What I strongly disagree with is calling it "piracy". I find that statement to be borderline trolling.
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.
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.
I use "monetize" as a superset of "sell", in that "sell" is usually taken to imply a direct payment by the end user, whereas "monetize" also provides for indirect payments like ad views.
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.)
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.)
It's not lying. The Internet is unavailable to your app, and it tells your app that. Now, it may be unavailable because the user said, "make the Internet unavailable" instead of being unavailable because the phone is inside a tunnel... but the end result is the same. An action the user took caused your app to be unable to contact the Internet. If this is a problem, pop a dialog saying, "hey, get out of that tunnel if you want to play my game."
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!
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!
Maybe I misunderstood the post, but I believe that you can't fake internet access permission. The way I read it is that the data you were supposed to be able to fake was stuff like phone serial number.
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.
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.
Imagine you were visiting a free art exhibition and someone was constantly shouting "BUY THIS PURSE BUY IT NOW!" into your ears. Probably a bad analogy but maybe you get my mindset.
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.
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.
Let me play devil's advocate here for a moment.
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.
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.
Ha, good catch. My argument crumbles to dust.
Yeah, not a great analogy.
So is disabling the nag screen in a shareware app piracy? What about removing the time limit from a 30 day trial?
So is disabling the nag screen in a shareware app piracy? What about removing the time limit from a 30 day trial?
It's unfortunate that people are voting you down just because they disagree with your opinion.
It's a totally fair point. What's the difference between downloading a free app and blocking the ads versus pirating an app outright?
It's a totally fair point. What's the difference between downloading a free app and blocking the ads versus pirating an app outright?
I don't know about others who downvoted the comment, but I know I didn't do so because I disagree, but because I believe that it's deliberately flawed and inflammatory. See my reply to the downvoted comment to find my explanation of why I believe that.
Is the word "piracy" considered troll-bait now? I thought that was the kindest available euphemism for "taking a not-free thing for free".
If there's actually a concrete claim you want to make, something more precise like "copyright infringement" or "violating the license agreement" is probably better. If you aren't accusing them of anything in particular but wish to express disapproval, it would be best just to call it "morally wrong" — though I don't think that would make for a very productive discussion.
"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).
"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).
That's precisely the crux of the problem. Is your app marketed as "free"? If it is, how can I pirate it?
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!"
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!"
The cause-effect relationship is exactly the point. IRL, I am an app developer. When I deliver a new app, I have two ways to monetize my development time: I can either charge money for the app (and call it the "Pro" version), or I can put ads in the app (and call it "Lite"). If someone ends up with a copy of the app that they did not pay money for (Pro) and does not show my ads (Lite), that is pirating. Whether you stole a copy of the "Pro" version or circumvented the trust I placed in the OS (to make the internet available for ad delivery whenever feasible) does not change the fact that you have broken our (admittedly loose) agreement and stolen my software from me.
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".)
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".)
By this logic, muting TV commercials is also piracy.
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.
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.
If you are distributing your app in the App Market, than your app is listed as "free".
What is the kindest euphemism for people who lie about their product?
What is the kindest euphemism for people who lie about their product?
Isn't that a bit like arguing that it's OK to pirate Photoshop because it costs too much?
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.
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.
Not even remotely. Photoshop has a well defined sticker price. It is well established (at this point) that in order to get a legitimate copy of Photoshop, you have to pay said sticker price.
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.
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.
I'm not a lawyer and I'm not really talking about the law.
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.
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.
It's an arms race. Smart developers will pre-load adds if this becomes a widely adopted practice. That way, users who have blocked internet access or happen to be out of coverage will still see ads.
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.
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.
already possible with droidwall.
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.