or Connect
AppleInsider › Forums › Mobile › iPhone › Apple will update iOS to require user permission for apps to access contact data
New Posts  All Forums:Forum Nav:

Apple will update iOS to require user permission for apps to access contact data - Page 2

post #41 of 92
Quote:
Originally Posted by DrDoppio View Post

Many here will testify that most users will be happy with that model and defend it even when it fails.

I'm not a developer, so I have no first hand knowledge of Apple's app approval process. And as a lazy bum, I've not tried to find any second hand knowledge either.

So, perhaps someone more industrious can help me out. Exactly what is included in Apple's app approval process? Do developers actually submit source code with their apps? Does Apple actually review that code? How would they determine what Path was doing?
post #42 of 92
Quote:
Originally Posted by Ricochet View Post

"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.

Actually Path did exactly that but it was reported incorrectly by a blog and then every tech blog copied that blog ...

That's part of the trouble with so called "tech journalism" today. They all feed on each other and rarely does anyone make a simple phone call to the source to check the facts out.

Path announced they were wiping all previously uploaded data and that the new app version would then ask people if they wanted to "opt in" on the sharing, but it's been reported as the opposite ever since, for the reasons stated above.
post #43 of 92
Quote:
Originally Posted by Curmudgeon View Post

It's a shame that you're demanding Apple treat all of their developers as criminals. Because some act poorly, Apple should punish everybody. What you want is developers with ethics. Perhaps they're rare now.

I lock my car and take the keys with me when I leave it sitting. I certainly don't think that everyone will try to open the door and steal it and know perfectly well that you can break a window instantly. That doesn't mean I don't take this precaution to prevent a crime of opportunity from occuring. I am being as proactive about the security as I can be within reason.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #44 of 92
Quote:
Originally Posted by mstone View Post

Sounds like Vista for iOS

Android is too convoluted, Vista was too numerous, and iOS simply isn't enough to be useful.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #45 of 92
Quote:
Originally Posted by Curmudgeon View Post

It's a shame that you're demanding Apple treat all of their developers as criminals. Because some act poorly, Apple should punish everybody. What you want is developers with ethics. Perhaps they're rare now.

I agree with SolipsismX here.

Ignorance can't be bliss. It's not about wanting developers with ethics, it's about not having to worry about the issue at all, and wondering if Apple did their diligence in vetting an app.
I'm not a pessimist. I'm an optimist, with experience.
Reply
I'm not a pessimist. I'm an optimist, with experience.
Reply
post #46 of 92
when will this iOS update come out ....and......bring with it the battery improvement???? thx Ap
http://www.flickr.com/photos/allanmichael/
iPhone 4S, iPad 3 WiFi, 80gb ipod,5G nano, 3G shuffle, 4 shuffles, '11 MBA 13", macmini 2.26, iMac QC i5 27"
Reply
http://www.flickr.com/photos/allanmichael/
iPhone 4S, iPad 3 WiFi, 80gb ipod,5G nano, 3G shuffle, 4 shuffles, '11 MBA 13", macmini 2.26, iMac QC i5 27"
Reply
post #47 of 92
Quote:
Originally Posted by Curmudgeon View Post

I'm not a developer, so I have no first hand knowledge of Apple's app approval process. And as a lazy bum, I've not tried to find any second hand knowledge either.

So, perhaps someone more industrious can help me out. Exactly what is included in Apple's app approval process? Do developers actually submit source code with their apps? Does Apple actually review that code? How would they determine what Path was doing?


You only submit the completed work, so Apple does not have code.

But that isn't as damning as it sounds. You are calling Apple APIs when you write on iOS and iOS is locked down pretty tight. They could easily determine 1) what you are accessing and 2) if you send it somewhere.
I am sure it isn't perfect though. Nothing ever is.
post #48 of 92
Quote:
Originally Posted by Curmudgeon View Post

I'm not a developer, so I have no first hand knowledge of Apple's app approval process. And as a lazy bum, I've not tried to find any second hand knowledge either.

So, perhaps someone more industrious can help me out. Exactly what is included in Apple's app approval process? Do developers actually submit source code with their apps? Does Apple actually review that code? How would they determine what Path was doing?

Developers do not submit source code. Apple does not review any source code. You submit a binary along with any resources like images in a single package file.

Apple has no way of knowing 100% what an app will do once it's live. There are multiple cases of developers submitting apps that deviated from their advertised functionality later. The flashlight app that had an easter egg that let it become a wifi proxy comes to mind. Apple took the app down as soon as they learned about it, but that shows there's a limitation to what can be verified during the review process.

Apple does have a binary scanner that finds things like unauthorized use of APIs. In theory, they could scan for calls to the address book and reject if the app has no good reason to access those features. But even a binary scanner is very limited in what it can find.
post #49 of 92
Quote:
Originally Posted by Gatorguy View Post

A quarter of them? I can't imagine what the other 21 would be.

I see these listed:
~Services that cost you Money (that a good one to know about, don't you think?)
~Storage - You already showed this one
~Your Personal Information - You showed that one too, and Apple agrees with getting your permission
~Phone call - Yup, that's in your screenshot
~Location - Another I think you should know about, and so does Apple
~Network Communication - In your screenshot and something you better know about.
~System tools - Again in your list
~Hardware controls - Not of much use IMO, unless you're worried why a kid's game wants to turn on the camera.
~Your Accounts ~ Another permission that's not really useful IMO.

Let's see. I count 9

There is a subset of permissions under each of those major sections (i.e services can include "phone calls" or "sms/mms" as two separate permissions). I believe that is where the higher number comes from.
post #50 of 92
Quote:
Originally Posted by techguy911 View Post

Developers do not submit source code. Apple does not review any source code. You submit a binary along with any resources like images in a single package file.

Apple has no way of knowing 100% what an app will do once it's live. There are multiple cases of developers submitting apps that deviated from their advertised functionality later. The flashlight app that had an easter egg that let it become a wifi proxy comes to mind. Apple took the app down as soon as they learned about it, but that shows there's a limitation to what can be verified during the review process.

Apple does have a binary scanner that finds things like unauthorized use of APIs. In theory, they could scan for calls to the address book and reject if the app has no good reason to access those features. But even a binary scanner is very limited in what it can find.

If a developer wanted to hide some nasty stuff it is easy to do by simply putting a date limitation if statement so the function does not activate until a date after when Apple is likely to be reviewing the app. Once the app goes live it wouldn't be very long before the community will discover the hidden functionality and they get the boot. So there is only a very small window of opportunity in which they can take advantage of unsuspecting users.

Not a lot of upside to trying anything shady.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #51 of 92
Quote:
Originally Posted by sexualintellectual View Post

There is a subset of permissions under each of those major sections (i.e services can include "phone calls" or "sms/mms" as two separate permissions). I believe that is where the higher number comes from.

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.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #52 of 92
Quote:
Originally Posted by AppleInsider View Post

Apple on Wednesday announced a future update to iOS will restrict App Store software from accessing a user's address book without their permission.

Good for Apple!

Now THAT is the way to handle problems!
post #53 of 92
iPhone is more likely to run into the same sorts of security issues that Windows had due to popularity. It is more secure then, say, Windows XP. Still, Apple is betting on the app approval process and a locked down API to keep things secure. I just don't see it as being a flawless system. Even now you could suggest it isn't working as apps are doing things with your personal data without your knowledge. People will live with this (thank you Facebook), but I believe this is just the beginning.

I have to believe that iOS will eventually be hit with something major. What happens then is anyone's guess. Simply because I believe something will happen, doesn't mean iOS instantly becomes "Windows Vista". Android is the wild west and is worse. Verizon recommended I have a security program on my Android when I bought it 2 years ago. Only time will tell if Microsoft has gotten security right on Windows Phone.

The only way to be more secure then iOS would be to lock something down to a point of being practically useless. (IE - First gen iPhone....before apps ).

For the time being, iOS might be the best you can do until we start giving hackers and spammers the death penalty instead of jobs.

PS:For the record, even though Windows Vista was an unstable, annoying turd, it was actually more secure than Windows XP if you ran it the way Microsoft intended. Not an endorsement as it really did suck for many reasons.
post #54 of 92
Quote:
Originally Posted by rednival View Post

I have to believe that iOS will eventually be hit with something major. What happens then is anyone's guess.

They've said this about OS X for the past decade. It never happened. My memory's worthless, but I think I recall Mac OS 9 having more viruses/exploits/what have you than OS X has ever had.

Originally posted by Marvin

Even if [the 5.5” iPhone] exists, it doesn’t deserve to.
Reply

Originally posted by Marvin

Even if [the 5.5” iPhone] exists, it doesn’t deserve to.
Reply
post #55 of 92
Quote:
Originally Posted by SolipsismX View Post

It's about bloody time as this issue has been in the media for several minutes now¡

What is really factored into the price is a kind of perpetual sense of disbelief that any company could be as good as Apple is. ~Retrogusto
Reply
What is really factored into the price is a kind of perpetual sense of disbelief that any company could be as good as Apple is. ~Retrogusto
Reply
post #56 of 92
Quote:
Originally Posted by mstone View Post

If a developer wanted to hide some nasty stuff it is easy to do by simply putting a date limitation if statement so the function does not activate until a date after when Apple is likely to be reviewing the app. Once the app goes live it wouldn't be very long before the community will discover the hidden functionality and they get the boot. So there is only a very small window of opportunity in which they can take advantage of unsuspecting users.

Not a lot of upside to trying anything shady.

Depending on what you do with the exploit, that small window might be all the time you need. People have gotten very rich on small windows.

Imagine if used a number of active apps check. Granted, the exploit may never reach activation, but the check would just look like a normal REST/SOAP call to Apple and they would ignore it. If it waited until there were 100,000 active apps to do the dirty work, it could do a lot in a small window of time.
post #57 of 92
Quote:
Originally Posted by rednival View Post

iPhone is more likely to run into the same sorts of security issues that Windows had due to popularity. It is more secure then, say, Windows XP. Still, Apple is betting on the app approval process and a locked down API to keep things secure. I just don't see it as being a flawless system.

Of course it's not flawless but it's a lot more secure than Windows and always will be. It's built into the model. They control what apps are approved and they pull them from the store and even remove them from your device if needed. They sandbox most of the apps.

This is something that desktop apps simply don't yet do. Even Android is safer than Mac OS X in some way (yes I just said that) because Google can pull an app that is overstepping it's reach from any connected device. I hope Apple will initiate more of the iOS App Store controls into the Mac App Store but since they won't be removing the access to 3rd-party apps that you install yourself there is always a chance you can install a trojan. I don't even know what apps have access my Address Book and iCal data on my Mac but I assume they can access all the unencrypted data I have ~/Library if they choose to.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #58 of 92
Quote:
Originally Posted by rednival View Post

If it waited until there were 100,000 active apps to do the dirty work, it could do a lot in a small window of time.

I suppose if they wrote an app that actually was popular enough to gain 100K users. At that point it would make more sense to offer paid version and get on the legit gravy train. I think we can primarily thank the jail breakers for discovering exploits because they have tools to watch packets.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #59 of 92
Quote:
Originally Posted by Tallest Skil View Post

They've said this about OS X for the past decade. It never happened. My memory's worthless, but I think I recall Mac OS 9 having more viruses/exploits/what have you than OS X has ever had.

I think that is because the Mac user is generally a more tech savy customers and a lot of morons own a PC. Generally people that can afford Macs make more money and have some form of higher education.

Everyone is getting an iPhone. Some moron, somewhere, will install something that promises to make them rich.

It is hard to protect your device form the dumb masses.

But I reserve the right to be wrong.
post #60 of 92
Quote:
Originally Posted by SolipsismX View Post

Of course it's not flawless but it's a lot more secure than Windows and always will be. It's built into the model. They control what apps are approved and they pull them from the store and even remove them from your device if needed. They sandbox most of the apps.

This is something that desktop apps simply don't yet do. Even Android is safer than Mac OS X in some way (yes I just said that) because Google can pull an app that is overstepping it's reach from any connected device. I hope Apple will initiate more of the iOS App Store controls into the Mac App Store but since they won't be removing the access to 3rd-party apps that you install yourself there is always a chance you can install a trojan. I don't even know what apps have access my Address Book and iCal data on my Mac but I assume they can access all the unencrypted data I have ~/Library if they choose to.

The part you fail to see is that Windows security issues generally come from exploits. Unintended holes that are discovered by some hacker. Being built the way it is makes it far less likely to happen, on that much we can agree. But it doesn't make it impossible.

And in general I am talking more about spyware-ish like software. Not a trojan or major virus. Those would be virtually impossible to pull off. Same is true of Android - well as long as you are not rooted/jailbroken.
post #61 of 92
Quote:
Originally Posted by mstone View Post

I suppose if they wrote an app that actually was popular enough to gain 100K users. At that point it would make more sense to offer paid version and get on the legit gravy train. I think we can primarily thank the jail breakers for discovering exploits because they have tools to watch packets.

Well, you have a point there. But criminals don't end up in jail because they are smart.
post #62 of 92
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.
post #63 of 92
If any app is found to be in violation of any rules to the disadvantage of the user it should be pulled IMMEDIATELY - no excuses, no bullshit.
post #64 of 92
Quote:
Originally Posted by SolipsismX View Post

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.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #65 of 92
Quote:
Originally Posted by Ricochet View Post

"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.
post #66 of 92
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!!
An Apple man since 1977
Reply
An Apple man since 1977
Reply
post #67 of 92
The Mac sandbox already stops apps from accessing your address book, but app makers aren't forced to use it until March 1.

Ohhh... that's only 2 weeks away.
post #68 of 92
Quote:
Originally Posted by Gatorguy View Post

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.

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply

"The real haunted empire?  It's the New York Times." ~SockRolid

"There is no rule that says the best phones must have the largest screen." ~RoundaboutNow

Reply
post #69 of 92
Quote:
Originally Posted by Gatorguy View Post

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.
post #70 of 92
Quote:
Originally Posted by lfmorrison View Post

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.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #71 of 92
Quote:
Originally Posted by Gatorguy View Post

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.
post #72 of 92
Quote:
Originally Posted by lfmorrison View Post

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.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #73 of 92
Quote:
Originally Posted by Gatorguy View Post

Getting ever closer to Android's permission-based app model. . .

If you are clueless you might think that. Exactly what you did.

Which of us is the fisherman and which the trout?

Reply

Which of us is the fisherman and which the trout?

Reply
post #74 of 92
Quote:
Originally Posted by Gatorguy View Post

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.
post #75 of 92
Quote:
Originally Posted by Povilas View Post

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.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #76 of 92
Quote:
Originally Posted by lfmorrison View Post

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.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #77 of 92
Quote:
Originally Posted by Gatorguy View Post

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.
post #78 of 92
You really should take the time to think your suggestion thru.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #79 of 92
Quote:
Originally Posted by Gatorguy View Post

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.
post #80 of 92
Quote:
Originally Posted by lfmorrison View Post

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?
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
  • Apple will update iOS to require user permission for apps to access contact data
AppleInsider › Forums › Mobile › iPhone › Apple will update iOS to require user permission for apps to access contact data