Here's an example of an app that could be exploited, Apple could catch grief, and it would not even be their fault:
Evernote competitor comes along with a "free" iPhone app. Apple even features app on App Store. Secretly, they are looking at what people enter and it is eventually discovered they use that data in some nefarious way.
Now, the smarter among us realize Apple did not do anything wrong. But, hey, Microsoft never wrote a virus and that fact did nothing for them in the court of public opinion.
This site lists 22 of them, but it's from 2010. I assume they have added more since then. The only one I can see that isn't really something I need to be warned about ahead of time is the Control Vibrator of the device.
"For its part, Path issued an apology and gave users the option to opt out,?"
The classy way to do it would be on an "opt in" basis.
I agree... but these companies, Apple included, don't want to give the user an "opt in" approach to allowing a user's data sent because no one will opt in. I surely would not opt in. I use Little Snitch on my iMac and it's amazing how much applications call home without the user ever knowing it. Most calling home has nothing to do with a program's functionality.
We users need to take back control of our data. I don't know if there is a program like Little Snitch for iOS devices, but if there is, it would be my first purchase.
Wed the 15th of feb. Terrorists were able to use an iPhone to access user data and forge more than 5,567,234.1 checks and spend more than 100 times the amount of users hacked (sarcasm).
Apple is being put into the cross hairs here. Its like saying that the letter I int he font of the iOS is to close to representing a penis and Apple knew that. So Apple is a company that supports porn on their iDevices. This is such a stupid issue. Apple has taken measures to insure security. Why would they want to make our data known to every one in the world. This makes Apple look stupid and the type of company that takes advantage of other people who take their technology for granted. Oh wait we are lovers of Apple tech. SO does that mean we are mindless automatons? NO!!
That's what Android does now. It won't ask again unless the permissions change. Even better, it won't allow an automatic updating of any app where the permissions have changed since you installed it. You have to update manually and agree that you've noted and accept the permission changes.
I've seen an Android phone list a set of permissions at the time you install the application, and the user's only recourse is to choose to grant it all the permissions at once, or else choose not to install the application at all. Once you actually install the app, all the listed permissions are granted, and the App is free to use them whenever and however it wants. Maybe I haven't explored Android enough to have seen anything more than that, but so far that's all I've experienced.
That's not what I want to see.
I want the application to install normally, and then you get the notification (and accompanying the request for permission) at run-time, literally at the instant the application actually tries to use any of your protected data. At that time, you can choose to allow the App to continue doing what it's doing (and you can choose to let it proceed just this once, or else give it blanket permission to always be allowed to do that thing), or you can choose to tell the App that it has no choice but to back out of whatever it had been trying to do, and fallback gracefully to some alternate course of action which doesn't violate your preferences.
I've seen an Android phone list a set of permissions at the time you install the application, and the user's only recourse is to choose to grant it all the permissions at once, or else choose not to install the application at all. Once you actually install the app, all the listed permissions are granted, and the App is free to use them whenever and however it wants. Maybe I haven't explored Android enough to have seen anything more than that, but so far that's all I've experienced.
That's not what I want to see.
I want the application to install normally, and then you get the notification (and accompanying the request for permission) at run-time, literally at the instant the application actually tries to use any of your protected data. At that time, you can choose to allow the App to continue doing what it's doing (and you can choose to let it proceed just this once, or else give it blanket permission to always be allowed to do that thing), or you can choose to tell the App that it has no choice but to back out of whatever it had been trying to do, and fallback gracefully to some alternate course of action which doesn't violate your preferences.
Why would you want to purchase and install an application, begin using it at some point, THEN find out it wants to send your calendar or contacts or location information? What is the advantage to that? The obvious downside to your method is you now may need to uninstall the app after finding it may not meet your own privacy standards, as well as probably losing the money you spent on it.
Unless I'm missing something your suggestion doesn't seem sensical.
Why would you want to purchase and install an application, begin using it at some point, THEN find out it wants to send your calendar or contacts or location information? What is the advantage to that? The obvious downside to your method is you now may need to uninstall the app after finding it may not meet your own privacy standards, as well as probably losing the money you spent on it.
Unless I'm missing something your suggestion doesn't seem sensical.
Nope... you don't need to uninstall it once it tries to access your calendar. You tell it that it can keep on doing everything it had been doing before it tried to access your calendar, but that the calendar itself is off-limits (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access.
Of course, a list of rights at install time may be useful in order to help you decide whether or not to purchase it in the first place. But that should only be the beginning of the permission system, not its ultimate end.
Nope... you don't need to uninstall it once it tries to access your calendar. You tell it that it needs to keep on going even though it doesn't have access to your calendar.
Well I suppose that if you're willing to continue using an app that doesn't need to grab your calendar data yet wants to anyway instead of finding a more honest app, then your method is plainly ideal. At least the possibly dishonest app developer gets a little income, only fair for his hard work.
EDIT: I noticed the addition you made to your post after I had responded.
"... (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access."
That makes even less sense IMO since a red flag is apparently flying if you feel you need to fake a calendar just to use the app.
EDIT: I noticed the addition you made to your post after I had responded.
"... (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access."
That makes even less sense IMO since a red flag is apparently flying if you feel you need to fake a calendar just to use the app.
I added that on to deal with lazy App developers, who don't to take into consideration the fact it it is possible for any API call to fail, and who therefore forget to check for errors (such as sandbox violations), and therefore don't include any code to handle such failures gracefully when they occur. Apps written by such lazy App developers would have the potential to crash if they don't get something back -- so we may as well give them something which doesn't do any harm.
If you are clueless you might think that. Exactly what you did.
Um. . . you apparently missed the numerous comments in the thread that permissions are actually a good idea, along with the fact that Apple is already beginning to use them, location permission last year, and now adding contacts permission in an update coming sometime. I suspect calendar permissions might be the next one.
I added that on to deal with lazy App developers, who don't to take into consideration the fact it it is possible for any API call to fail, and who therefore forget to check for errors (such as sandbox violations), and therefore don't include any code to handle such failures gracefully when they occur. Apps written by such lazy App developers would have the potential to crash if they don't get something back -- so we may as well give them something which doesn't do any harm.
How do you tell the difference between a lazy developer and a dishonest one?
I'm sorry, but I still don't think holding off on being notified about services being accessed until you're already using the app is such a great idea. Once you've had time to sit and think it thru thoroughly I believe you'll come to the same conclusion.
How do you tell the difference between a lazy developer and a dishonest one?
I don't follow. In either case, if an app tries to access my calendar and I don't want to show it to them, the result would be the same: they don't get access.
The non-lazy, but dishonest, App developer would catch the error, and either cleanly abort the operation to bring the app back to its normal idle state, or else show some sort of feedback to the user explaining why it is unable to continue doing whatever it was trying to do. It would be up to the customer to decide whether or not granting access to the calendar actually has any legitimate role in continuing to carry out that action.
The lazy, but benign, App developer, would naively continue using the dummy data, blissfully unaware of the fact that, by all rights, the App should have crashed when they accessed a reference without checking first to see if it's null.
You know, an API call set an error code, and still return dummy data. It's not necessarily just a case of one or the other.
When you give me a use case where this idea falls apart, I will re-evaluate it.
I already did.
You buy an app and install it. Later after opening it up you find that the crossword app you purchased wants to upload your location along with your contacts. NO WAY you say, but the developer at least has your money now if Apple were to choose to notify you of permissions only after you bought and paid for an app. What about that makes sense to you?
Um. . . you apparently missed the numerous comments in the thread that permissions are actually a good idea, along with the fact that Apple is already beginning to use them, location permission last year, and now adding contacts permission in an update coming sometime. I suspect calendar permissions might be the next one.
Some poor bastard installs a 'live wallpaper app' it presents a list of permission that it requires in between some legit required permissions for type of app is some that it has no need, like access to contacs or sms or calls. Poor bastard will miss this "small" detail and just do "next, next, ok, ok" 99.5% of the time.
Yeah it's great "security". Apple on the other hand gets it. You will see an icon that tells you hey your app is using you contacs and since apps have to be tested and approved by Apple there is very small chance some app sneaks around this and if it does Apple will just kill it, dev will see a middle finger and will never be allowed to the store again.
Comments
Evernote competitor comes along with a "free" iPhone app. Apple even features app on App Store. Secretly, they are looking at what people enter and it is eventually discovered they use that data in some nefarious way.
Now, the smarter among us realize Apple did not do anything wrong. But, hey, Microsoft never wrote a virus and that fact did nothing for them in the court of public opinion.
This site lists 22 of them, but it's from 2010. I assume they have added more since then. The only one I can see that isn't really something I need to be warned about ahead of time is the Control Vibrator of the device.
Ah, I see. For instance you're counting the various reasons for the System Tools permission as separate items. Heck that's 8 of them eight there.
"For its part, Path issued an apology and gave users the option to opt out,?"
The classy way to do it would be on an "opt in" basis.
I agree... but these companies, Apple included, don't want to give the user an "opt in" approach to allowing a user's data sent because no one will opt in. I surely would not opt in. I use Little Snitch on my iMac and it's amazing how much applications call home without the user ever knowing it. Most calling home has nothing to do with a program's functionality.
We users need to take back control of our data. I don't know if there is a program like Little Snitch for iOS devices, but if there is, it would be my first purchase.
Apple is being put into the cross hairs here. Its like saying that the letter I int he font of the iOS is to close to representing a penis and Apple knew that. So Apple is a company that supports porn on their iDevices. This is such a stupid issue. Apple has taken measures to insure security. Why would they want to make our data known to every one in the world. This makes Apple look stupid and the type of company that takes advantage of other people who take their technology for granted. Oh wait we are lovers of Apple tech. SO does that mean we are mindless automatons? NO!!
Ohhh... that's only 2 weeks away.
Ah, I see. For instance you're counting the various reasons for the System Tools permission as separate items. Heck that's 8 of them eight there.
I am because those can be listed, hence that Android's list of permissions are to unwieldily to be useful for the average user.
That's what Android does now. It won't ask again unless the permissions change. Even better, it won't allow an automatic updating of any app where the permissions have changed since you installed it. You have to update manually and agree that you've noted and accept the permission changes.
I've seen an Android phone list a set of permissions at the time you install the application, and the user's only recourse is to choose to grant it all the permissions at once, or else choose not to install the application at all. Once you actually install the app, all the listed permissions are granted, and the App is free to use them whenever and however it wants. Maybe I haven't explored Android enough to have seen anything more than that, but so far that's all I've experienced.
That's not what I want to see.
I want the application to install normally, and then you get the notification (and accompanying the request for permission) at run-time, literally at the instant the application actually tries to use any of your protected data. At that time, you can choose to allow the App to continue doing what it's doing (and you can choose to let it proceed just this once, or else give it blanket permission to always be allowed to do that thing), or you can choose to tell the App that it has no choice but to back out of whatever it had been trying to do, and fallback gracefully to some alternate course of action which doesn't violate your preferences.
I've seen an Android phone list a set of permissions at the time you install the application, and the user's only recourse is to choose to grant it all the permissions at once, or else choose not to install the application at all. Once you actually install the app, all the listed permissions are granted, and the App is free to use them whenever and however it wants. Maybe I haven't explored Android enough to have seen anything more than that, but so far that's all I've experienced.
That's not what I want to see.
I want the application to install normally, and then you get the notification (and accompanying the request for permission) at run-time, literally at the instant the application actually tries to use any of your protected data. At that time, you can choose to allow the App to continue doing what it's doing (and you can choose to let it proceed just this once, or else give it blanket permission to always be allowed to do that thing), or you can choose to tell the App that it has no choice but to back out of whatever it had been trying to do, and fallback gracefully to some alternate course of action which doesn't violate your preferences.
Why would you want to purchase and install an application, begin using it at some point, THEN find out it wants to send your calendar or contacts or location information?
Unless I'm missing something your suggestion doesn't seem sensical.
Why would you want to purchase and install an application, begin using it at some point, THEN find out it wants to send your calendar or contacts or location information?
Unless I'm missing something your suggestion doesn't seem sensical.
Nope... you don't need to uninstall it once it tries to access your calendar. You tell it that it can keep on doing everything it had been doing before it tried to access your calendar, but that the calendar itself is off-limits (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access.
Of course, a list of rights at install time may be useful in order to help you decide whether or not to purchase it in the first place. But that should only be the beginning of the permission system, not its ultimate end.
Nope... you don't need to uninstall it once it tries to access your calendar. You tell it that it needs to keep on going even though it doesn't have access to your calendar.
Well I suppose that if you're willing to continue using an app that doesn't need to grab your calendar data yet wants to anyway instead of finding a more honest app, then your method is plainly ideal. At least the possibly dishonest app developer gets a little income, only fair for his hard work.
EDIT: I noticed the addition you made to your post after I had responded.
"... (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access."
That makes even less sense IMO since a red flag is apparently flying if you feel you need to fake a calendar just to use the app.
Getting ever closer to Android's permission-based app model. . .
If you are clueless you might think that. Exactly what you did.
EDIT: I noticed the addition you made to your post after I had responded.
"... (or else, if it needs to get something back to prevent crashing, it may get back a dummy calendar with no data in it), except for the unique situations where you may decide to change your mind and give it temporary access."
That makes even less sense IMO since a red flag is apparently flying if you feel you need to fake a calendar just to use the app.
I added that on to deal with lazy App developers, who don't to take into consideration the fact it it is possible for any API call to fail, and who therefore forget to check for errors (such as sandbox violations), and therefore don't include any code to handle such failures gracefully when they occur. Apps written by such lazy App developers would have the potential to crash if they don't get something back -- so we may as well give them something which doesn't do any harm.
If you are clueless you might think that. Exactly what you did.
Um. . . you apparently missed the numerous comments in the thread that permissions are actually a good idea, along with the fact that Apple is already beginning to use them, location permission last year, and now adding contacts permission in an update coming sometime. I suspect calendar permissions might be the next one.
I added that on to deal with lazy App developers, who don't to take into consideration the fact it it is possible for any API call to fail, and who therefore forget to check for errors (such as sandbox violations), and therefore don't include any code to handle such failures gracefully when they occur. Apps written by such lazy App developers would have the potential to crash if they don't get something back -- so we may as well give them something which doesn't do any harm.
How do you tell the difference between a lazy developer and a dishonest one?
I'm sorry, but I still don't think holding off on being notified about services being accessed until you're already using the app is such a great idea. Once you've had time to sit and think it thru thoroughly I believe you'll come to the same conclusion.
How do you tell the difference between a lazy developer and a dishonest one?
I don't follow. In either case, if an app tries to access my calendar and I don't want to show it to them, the result would be the same: they don't get access.
The non-lazy, but dishonest, App developer would catch the error, and either cleanly abort the operation to bring the app back to its normal idle state, or else show some sort of feedback to the user explaining why it is unable to continue doing whatever it was trying to do. It would be up to the customer to decide whether or not granting access to the calendar actually has any legitimate role in continuing to carry out that action.
The lazy, but benign, App developer, would naively continue using the dummy data, blissfully unaware of the fact that, by all rights, the App should have crashed when they accessed a reference without checking first to see if it's null.
You really should take the time to think your suggestion thru.
You know, an API call set an error code, and still return dummy data. It's not necessarily just a case of one or the other.
When you give me a use case where this idea falls apart, I will re-evaluate it.
You know, an API call set an error code, and still return dummy data. It's not necessarily just a case of one or the other.
When you give me a use case where this idea falls apart, I will re-evaluate it.
You buy an app and install it. Later after opening it up you find that the crossword app you purchased wants to upload your location along with your contacts. NO WAY you say, but the developer at least has your money now if Apple were to choose to notify you of permissions only after you bought and paid for an app. What about that makes sense to you?
Um. . . you apparently missed the numerous comments in the thread that permissions are actually a good idea, along with the fact that Apple is already beginning to use them, location permission last year, and now adding contacts permission in an update coming sometime. I suspect calendar permissions might be the next one.
Some poor bastard installs a 'live wallpaper app' it presents a list of permission that it requires in between some legit required permissions for type of app is some that it has no need, like access to contacs or sms or calls. Poor bastard will miss this "small" detail and just do "next, next, ok, ok" 99.5% of the time.
Yeah it's great "security". Apple on the other hand gets it. You will see an icon that tells you hey your app is using you contacs and since apps have to be tested and approved by Apple there is very small chance some app sneaks around this and if it does Apple will just kill it, dev will see a middle finger and will never be allowed to the store again.