Apps are only permitted to share data via group keychains if they have the same bundle seed ID.
This means that a developer can share data between their own apps, but it's not really possible for Ad network code to share data across unrelated apps.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Begins Rejecting Apps for Using the Unique Device Identifier (UDID)
- Thread starter MacRumors
- Start date
- Sort by reaction score
Apps are only permitted to share data via group keychains if they have the same bundle seed ID.
This means that a developer can share data between their own apps, but it's not really possible for Ad network code to share data across unrelated apps.
Is Apple allowing other new apps that use deprecated APIs through? When they deprecate APIs, do they normally give a date after which the no longer acceptable APIs will be cause for rejection?
I'm guessing that there is an automated process that scans your code for calls to deprecated APIs and other red flags. They are probably not treating this differently.
And it doesn't mean your app can't be in the App Store. You just have to address the problem (use of deprecated APIs, for example), and resubmit the app.
Apple is doing this to address privacy concerns. In other words, to avoid lawsuits for violating privacy concerns. Do you want to stand with Apple on the receiving end of such a lawsuit?
Maybe sometimes NOT surviving the device change is what the app wants?
For example, our app uses a single username/password, but it can be installed on multiple devices and you can share data between them, so we need to know which of the devices you're using when starting the app, because you may want to have some data on a device and not on another one.
Also, the method indicated by Apple (calling the generate unique ID API) will not work for us, because it will change if someone uninstalls and reinstalls the application.
It's all a matter of what you have to do, really, so it isn't "the wrong thing to do" every single time.
Well, it wasn't. Now it is.
Wirelessly posted
As a developer and gamer i object to udid being used.
Many games lose settings anyway, when i upgrade to a new device, have it replaced under applecare.
As a gamer i like gamecenter.
A game that does things right is bullet time. (kiloo games)
Well balanced IAP. Use of gamecenter and backup system built into game based off gamecenter login. I can backup and restore data at anytime in any device.
It's quick and easy to backup and restore my data on any device. I never lose game data or purchases through phone upgrades or new purchases such as ipad. I can even delete app, re-install an restore all my game data.
Develop smarter, not the easy way. There are always new ways to handle things.
I don't want udid exposed for those that abuse it just for the few developers who don't.
Edit. I do not work for kiloo, just a well done setup of gamecenter and backups.
macintel4me said:
As a developer and gamer i object to udid being used.
Many games lose settings anyway, when i upgrade to a new device, have it replaced under applecare.
As a gamer i like gamecenter.
A game that does things right is bullet time. (kiloo games)
Well balanced IAP. Use of gamecenter and backup system built into game based off gamecenter login. I can backup and restore data at anytime in any device.
It's quick and easy to backup and restore my data on any device. I never lose game data or purchases through phone upgrades or new purchases such as ipad. I can even delete app, re-install an restore all my game data.
Develop smarter, not the easy way. There are always new ways to handle things.
I don't want udid exposed for those that abuse it just for the few developers who don't.
Edit. I do not work for kiloo, just a well done setup of gamecenter and backups.
Not when the numbers are big enough, you don't. The size of the UUID is sufficiently large that everyone on Earth could have 600 million of them, and there'd only be a 50% chance of a duplication. More data in the Wikipedia entry for UUID. And even if duplicates were realistically possible, it wouldn't be a problem unless they were used for the same purpose.
The UUID is an industry standard. The only people who have a problem with it are the ones who don't know what they're talking about.
I was pointing out what would happen if it was removed completely, something that macintel4me suggested Apple do instead of deprecation:
Isn't user registration provide more information than UDID?
An UDID, by itself, means nothing. User registration always requires email (used in case the user forgets his password).
There is no way for a developer to contact a particular user by UDID alone outside the app. However, emails associated with an app is worth something.
An UDID, by itself, means nothing. User registration always requires email (used in case the user forgets his password).
There is no way for a developer to contact a particular user by UDID alone outside the app. However, emails associated with an app is worth something.
Stolen, anyone?
Too bad APPLE THEMSELVES won't institute a program by which they blacklist iDevices that are stolen, leaving whoever steals a phone is required to jailbreak it and never use iTunes.
When I say stolen I mean stolen - such as I have a bona-fide police report from my local precinct with the serial number, etc., on file.
There is no reason they cannot do it - they simply choose not to do it.
There was a recent article on how phone companies could do the same thing in the US. They don't. I figure when people get roughed up (or someone's daughter or son get mauled for their piece of iCandy), that someone will eventually get mad enough to kneecap one of the execs in these companies that refuse to help shut down the black markets.
Too bad APPLE THEMSELVES won't institute a program by which they blacklist iDevices that are stolen, leaving whoever steals a phone is required to jailbreak it and never use iTunes.
When I say stolen I mean stolen - such as I have a bona-fide police report from my local precinct with the serial number, etc., on file.
There is no reason they cannot do it - they simply choose not to do it.
There was a recent article on how phone companies could do the same thing in the US. They don't. I figure when people get roughed up (or someone's daughter or son get mauled for their piece of iCandy), that someone will eventually get mad enough to kneecap one of the execs in these companies that refuse to help shut down the black markets.
While that's true, the concern is more that the UDID can be used as glue to connect the dots between a user's activities in multiple apps. An ad network or metrics library could tell that one particular device was using multiple apps that implement that library. If one of those apps involved registration, then all those apps (and servers they phone home to) could, in theory, uniquely identify a user and their activities.
We don't know, however, if this is something that's already happening, or if this is more a theoretical concern.
We also don't know if iAd will still be able to access the UDID, which would effectively give it a competitive advantage over third-party ad networks.
Also, it's technically possible for multiple apps to share a unique ID other than the UDID, like an on-the-fly UUID, but there are big caveats. One app could call another via a URL scheme, passing the UUID, but the user would see the app switch animation. App A can also share data with app B via the keychain, but only if they're both signed with the same credentials and share a bundle seed ID this is only practical for apps from a single developer (and, IIRC, the apps would lose the ability to use In-App Purchase and Push Notifications, which require unique bundle identifiers)
--invalidname
Problem is that is that is only in theory and only works if your numbers are truly random. Computers can not do true random. They can only do pseudo random at best.
It is how the number is generated that creates an issue. It is not hard to cause a program to kick out the exact same random number over and over again. No matter how big in size of random numbers you choose to use the major flaw weakness in random numbers is the pseudo random part.
----------
Lets get to the heart of the matter. This is not about so called user privacy. It is more about Apple trying to limit competitors to its own iAd network. Apple sure as hell is collecting and gathering that info to makes its iAds much more targeted and limit others from gathering that critical information.
Thumbs up for this news.
People who want their scores in games recorded can always sign up for an account.
Opt-In is much better than Opt-Out in privacy matters. You can't expect people to constantly opt out of having their data recorded and identified.
People who want their scores in games recorded can always sign up for an account.
Opt-In is much better than Opt-Out in privacy matters. You can't expect people to constantly opt out of having their data recorded and identified.
agree.
----------
That is probably part of it but as a user I don't want what i do being tracked per device so easily. The fact of the matter is UDID is abused or used incorrectly. I'd rather see it go away than remain a risk. Leaving it around for a few developers who use it correctly vs those who blatantly use it without customer knowledge is not a sacrifice i want to make.
My biggest issue is developers using UDID to limit installs on a particular device. Requiring the same device to keep data around because it was tied to UDID sucks. There are better options. It shouldn't matter what device, ipad, iphone I am on as long as I paid for it legitimately with my itunes account. It is particularly frustrating when replacing faulty devices.
Of course there could be much more behind these decisions to tighten things down related to certain privacy investigations being conducted.
Like I said, the UUID an industry standard. It's not something that Apple, or I, or anyone else just pulled out of their butts last week. The UUID passed a rigorous standards review process to be published as RFC 4122, ISO 11578:1996, et. al., and has been in widespread use for years, if not decades. If you really think that nobody else already challenged the randomness and uniqueness of UDIDs and was satisfied (or at least outvoted), and thus if you really think you're smarter than the entire computer science profession, then I can only defer to your obvious genius.
Buy a used device from a master player - inherit their high scores
UDID (Unique Device IDentifier) = works really well for ad networks that want to figure out things about you, doesn't work well at all for legitimate purposes.
UUID = Universally Unique IDentifier = works well for legitimate purposes, but not at all for ad networks.
You seem to be confusing UDID and UUID. They are very different things. UDID = an ID identifying a device. You can't generate a UDID. It's built into the device and can never, ever be changed.
I guess the UID that you mention is either a UDID or a UUID, whatever fits your argumentative purposes better? So what legitimate use of UDID (which Apple wants to ban, and not UUID which Apple recommends to use instead) are you thinking of?
Last edited:
Come to think of it, I think all this would be solved if Apple adopted a permissions system like Android and WP7. That is, tell the user what permissions an app wants before it's installed. The tech savvy ones like us lot can easily weed out the dodgy apps then.
Why doesn't Apple just provide a means to generate an application specific UDID, that would always be the same for a given device and application? This would still gives developer's who need to ID a device but not be able to share it across apps. Instead, as I understand it the method they suggest changes with app uninstall/reinstall, making it clearly inferior to UDID for this purpose.
Get off line
If I want to track you using my product, I will. There is nothing you can do about it.
If I want to track you using my product, I will. There is nothing you can do about it.
I mounted a reasonable defense a few days ago for the iOS developers. Sadly, around the 4th paragraph Safari on my iPad crashed. I didn't have the heart or finger strength to do another rant via iPad. Fortunetally, someone smarter has done a better job than I, so I'll link to their article. Fair warning, MacRumors forum goers are called out in it
App Rejections Are a Lousy Way to Communicate Policy Changes
I'll add a few points that his view doesn't cover.
To lay blanket statements across the entire community that pegs them as "ignorant" or "malicious" is terrible. Fine to be critical and questioning if you want to learn what the developer world is like. But if you don't know anything, watch you mouth. Please
App Rejections Are a Lousy Way to Communicate Policy Changes
I'll add a few points that his view doesn't cover.
- Many iOS developers are single person operations.
- iOS developers probably aren't sitting around twiddling their thumbs looking for something to do. They have to prioritize.
- What happens to an iOS developer that started on the platform 6 months ago and missed the "announcement" ?
To lay blanket statements across the entire community that pegs them as "ignorant" or "malicious" is terrible. Fine to be critical and questioning if you want to learn what the developer world is like. But if you don't know anything, watch you mouth. Please
I think it would be irresponsible for any app developer to not treat customer privacy issues with the utmost urgency. All app developers should have moved as swiftly as possible to replace something that is viewed as a major privacy problem for end users. Any developer didn't is negligent in knowing their business and how to manage it.
This is not any old deprecated function. It was clear what the issue was and that it was serious. Any developer who did not take that information to mean they should act as quickly as possible did a very poor job.
It clearly sends a message to the end user that the developer does not take privacy issues seriously. There are no legitimate excuses. People are right when they peg it on laziness. It was a lazy thing to use to begin with and lazy and negligent not to change it as quickly as possible.
Wow. You don't understand this at all, do you? There is nothing inherently bad about UDID, what matters is how a developer uses it. Apple provided the means to use it, documented how to use it. After a while, Apple decided that they no longer trust developers to use it wisely. However any developer that decided to keep using was risking no privacy on their customers part. There is no inherent security issue here.
I'm smelling lazy and ignorant, but it isn't the developers. You just don't understand the issue at all. Go read up on the issue before you start putting other human beings down.