or Connect
AppleInsider › Forums › Mobile › iPhone › Inside iOS 5: privacy change kills app developers' access to UDID
New Posts  All Forums:Forum Nav:

Inside iOS 5: privacy change kills app developers' access to UDID

post #1 of 37
Thread Starter 
One of the new features of Apple's upcoming iOS 5 is the removal of a feature many app developers, particularly ad networks, regularly access to track use of their apps by mobile customers.

According to a report by Tech Crunch The upcoming release of iOS 5 will deprecate developers' app access to "uniqueIdentifier," the universally unique serial number embedded in each iPhone and iPad sold.

This UDID works like a networked computer's MAC address, serving as a unique hardware identifier that remains the same regardless of the user or app currently running. A security review last year showed that 68% of top iPhone apps transmit unencrypted UDIDs that can be used to track user behaviors unique to a device, while another 18 percent transmit encrypted data that may include the UDID.

The change should effectively end a controversial privacy issue that relates to how third party developers and ad networks track users, without their knowledge, consent, or in some cases without any ability to block such data collection.

This summer, Apple was sued by a man in New York over iPhone location data tracking issue, with Apples inability to provide a method to delete or restrict access to a devices UDID being one of the main points of the lawsuit.

The UDID

Every mobile device has a unique serial number that identifies it to the mobile network. For iOS devices, this number is accessible by users from iTunes or through the Settings app on the device itself.

Developers can distribute a custom app provisioned for use on specific phones identified by their UDID, and also register this number with Apple to verify the installation of beta versions of iOS.

Third party apps can currently read users' UDID after being installed on the device, allowing the app to record what device is using it without the user needing to login with a uniquely identifying account number. Third party ad networks access this number to track the use of mobile devices, similar to how web browser cookies can store information unique to a given user.

Unlike cookies however, a device's UDID can be read by any app, allowing ad networks to coordinate their data across apps with a globally unique serial number that doesn't change and can't be deleted.

Use cookies, accounts, iCloud, GameCenter instead

By removing app access to this number, Apple will pinch off the ability of third party ad networks to track users' behaviors across the various apps they are installed within. Apple recommends that developers "create a unique identifier specific to your app" instead, a process that would work much more like web cookies.

By forcing each app to maintain its own per-user tracking cooking, iOS 5 will prevent analytics firms from being able to effectively track users unique to a device, or to cross-reference behavioral data collected from multiple apps.

It will also make it impossible for developers to track whether a user has stopped using their app and then started up again, unless the user voluntarily opts to log in with an identifiable account. Thus, simply deleting and reinstalling the app will clear any unique tracking numbers a developer or ad network has on record, allowing users to erase their tracks in the mobile world just as they can by deleting browser cookies.

The change will occur alongside the appearance of iCloud, which will allow apps that the user approves to share a unique key across devices using iCloud's new Documents and Data feature. For example, a developer can use iCloud to customize the appearance or state of their app across the users' devices by sharing key value data in the cloud.

Apple's GameCenter also allows third party apps to associate state within a game with a specific user when that user chooses to login via their Apple ID. This allows a user to move between devices while retaining the same scores and achievements on a user account level.

Developers have noted that the inability to track users by a hardware address could complicate beta testing and make it harder to ban abusive users from a service, unless the developer resorts to using a personal account system. Apple has warned developers that they should not rely on the UDID for device level tracking of their users.

Apple is scheduled to launch iOS 5 to the public this fall. The company just released iOS 5 Beta 6, build 9A5302b, to developers.
post #2 of 37
Reaction as a user? SWEET!

Now, Apple don't go using it to track us in unsavory ways yourself.
post #3 of 37
Good. Developers and ad companies should not be able to track my behavior using the UDID when I'm using iOS devices.
post #4 of 37
Deprecated ≠ killed. It just means it will be killed in a future update, but developers can continue to use it for the foreseeable future, and are encouraged to find a different solution.
post #5 of 37
Quote:
Originally Posted by mbarriault View Post

Deprecated ≠ killed. It just means it will be killed in a future update, but developers can continue to use it for the foreseeable future, and are encouraged to find a different solution.

yeh change the title apple insider you look very silly. It's just deprecated meaning it can still be used for OS 5, and might never be killed.
post #6 of 37
Quote:
Originally Posted by mbarriault View Post

Deprecated ≠ killed. It just means it will be killed in a future update, but developers can continue to use it for the foreseeable future, and are encouraged to find a different solution.

Well it still means they have "killed it" in the sense that apps using it won't be approved from this point forward. Pretty much the same thing.
post #7 of 37
Great job Apple!

Naysayers will say what they will, but Apple continues to be one of the best at protecting their users' privacy. I have no doubt they have MASSIVE amounts of personal data at their disposal internally, (and yes, that's bothersome), but they are doing a better job of keeping it private from 3rd parties than any of the other big players. In general, they're also doing a decent job of letting you use as much of their products/features AS POSSIBLE without requiring personal, trackable information.
No Matte == No Sale :-(
Reply
No Matte == No Sale :-(
Reply
post #8 of 37
That last part reminds me, what is the deal with requiring an AppleID just to use an iPodTouch to control your AirportExpress-controlled music system?

I have tons of CD-ripped music, and a standalone AirportExpress connected to the stereo. I occasionally connect to the Express from my laptop to play music, but I'd love to be able to play music from the iPodTouch on it. But I'm not going to set up AppleID crap on those devices to do so. This is a fully internal setup, and neither of the devices connects to the internet. Anyone aware of any good (hopefully easy) solutions?

(sorry, I guess this is somewhat off-topic, so if someone wants to move it to a better thread or new topic, that's perfectly fine with me, I don't see a way to move or properly delete a post myself)
No Matte == No Sale :-(
Reply
No Matte == No Sale :-(
Reply
post #9 of 37
Quote:
Originally Posted by Prof. Peabody View Post

Well it still means they have "killed it" in the sense that apps using it won't be approved from this point forward. Pretty much the same thing.

They didn't say that. They just removed the API in iOS 5.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #10 of 37
Quote:
Originally Posted by asdasd View Post

They didn't say that. They just removed the API in iOS 5.

It's my understanding that an app that uses a deprecated API wouldn't be approved though so it's the same thing isn't it? Every app that is updated and every new app will be refused if it uses that API.
post #11 of 37
"pinch-off"? Great word choice, Daniel.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #12 of 37
Quote:
Originally Posted by Prof. Peabody View Post

Well it still means they have "killed it" in the sense that apps using it won't be approved from this point forward. Pretty much the same thing.

Not exactly, because approved apps that are already using it will be able to continue to do so.

Of course, that was necessary because otherwise it would destroy the functioning of many existing apps, which rely on this feature. Its a good bet that iOS 6 will actually kill access to the UDID, giving developers about a year's time to create their own unique identifier network.

Edit: On hindsight, I think I pretty much said the same thing as you, but in more words…well, brevity is for losers ;-)
post #13 of 37
Quote:
Originally Posted by Cpsro View Post

Reaction as a user? SWEET!

Now, Apple don't go using it to track us in unsavory ways yourself.

Because they have done it so much in the past?
post #14 of 37
Quote:
Originally Posted by Chris_CA View Post

Because they have done it so much in the past?

They've only done it if you buy tinfoil hat conspiracy theories that reject the evidence.
post #15 of 37
Quote:
Originally Posted by Prof. Peabody View Post

It's my understanding that an app that uses a deprecated API wouldn't be approved though so it's the same thing isn't it? Every app that is updated and every new app will be refused if it uses that API.

dunno who told you that but it's wrong.
post #16 of 37
The more privacy people have the better. Now why don't they create a feature in Safari that prevents all web beacons? I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users. As the US government and other governments constantly spy on us, we need more privacy not less. Even ISPs have been shown to track the habits of their customers.
post #17 of 37
This is a nice move on Apple's part, and helps differentiate iOS from Android. Google is moving in exactly the opposite direction, with requiring real names and tying that to everything you do on the device. And because Google is essentially an advertising company whose customers are advertisers and whose product is you, it will help differentiate iOS and make people realize that "Don't Be Evil" is more marketing than reality.
post #18 of 37
Quote:
Originally Posted by Smallwheels View Post

I think all computers should not even have MAC addresses.

You must not know how Networking works.
post #19 of 37
Quote:
Originally Posted by indiekiduk View Post

dunno who told you that but it's wrong.

Whatever. I think I'm right and I'm not going to take your word for it without some kind of proof.

If an app is automatically rejected for using private or unofficial API's (fact) and if Apple clearly indicates that they want you to use only the official API's (fact) and then they personally deprecate the API and tell you that you should be using something else, I'm pretty sure that apps that still use the UDID are going to be rejected from the app store admission process. I mean why wouldn't they? Maybe they will let some apps update for a while without kicking them out because it takes a while to work out an alternative, but new apps would likely be rejected.

Anyway this whole thread is just an example of why people don't like developers. What a colossal waste of time arguing over the exact meaning of the word "killed." It's always going to be somewhat subjective and it's not like "killed" is some official programming term that means something specific anyway.

Every other site is reporting this story is using the word "killed" to describe the situation. Any normal person can see that Apple just "killed" the use of UDID's. If developers want to whine and argue over the exact meaning of the word or wait until Apple actually forces them to change or leave the store, all I can say is that I'm absolutely certain that no one really cares.
post #20 of 37
Quote:
Originally Posted by Prof. Peabody View Post

Whatever. I think I'm right and I'm not going to take your word for it without some kind of proof.

If an app is automatically rejected for using private or unofficial API's (fact) and if Apple clearly indicates that they want you to use only the official API's (fact) and then they personally deprecate the API and tell you that you should be using something else, I'm pretty sure that apps that still use the UDID are going to be rejected from the app store admission process. I mean why wouldn't they? Maybe they will let some apps update for a while without kicking them out because it takes a while to work out an alternative, but new apps would likely be rejected.

Anyway this whole thread is just an example of why people don't like developers. What a colossal waste of time arguing over the exact meaning of the word "killed." It's always going to be somewhat subjective and it's not like "killed" is some official programming term that means something specific anyway.

Every other site is reporting this story is using the word "killed" to describe the situation. Any normal person can see that Apple just "killed" the use of UDID's. If developers want to whine and argue over the exact meaning of the word or wait until Apple actually forces them to change or leave the store, all I can say is that I'm absolutely certain that no one really cares.

That's the problem. Apple actually didn't "kill" the use of UDID's for iOS 5, they're just deprecated. They will be killed in a future version of iOS, allowing devs time to adapt. This time is important for both users and developers. AppleInsider and every other site, put simply, are taking a story and exaggerating it, which is a form of journalism most people disapprove of.
post #21 of 37
Quote:
Originally Posted by mbarriault View Post

That's the problem. Apple actually didn't "kill" the use of UDID's for iOS 5, they're just deprecated. They will be killed in a future version of iOS, allowing devs time to adapt.

Unless Apple refuses to accept apps in iOS 5 that use the UDID framework.

Then they're killed and people are completely right in what they're saying.

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply
post #22 of 37
I used UDID to add a level of security to a fairly well known app. Creating our own ID would not suffice for the problems faced.
I no longer work for the company, but I'm pretty sure this is gonna cause one hell of a headache as UDID was the only solution.

This was a popular legitimate use for UDID.
post #23 of 37
FWIW, the API to access the UDID no longer exists in iOS 5. That means, if you build an app against the iOS 5 SDK, you can't use it (perhaps you 'can', in the sense that it has become a private API and the hooks are still there inside the OS)

I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
post #24 of 37
Quote:
Originally Posted by ranReloaded View Post

FWIW, the API to access the UDID no longer exists in iOS 5. That means, if you build an app against the iOS 5 SDK, you can't use it (perhaps you 'can', in the sense that it has become a private API and the hooks are still there inside the OS)

I wonder what happens when you build against iOS 5, but set a 'Deployment Target' of 4.3 or less (which DO have the UDID API).

In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.

I think so.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #25 of 37
Quote:
Originally Posted by Prof. Peabody View Post

Whatever. I think I'm right and I'm not going to take your word for it without some kind of proof.

If an app is automatically rejected for using private or unofficial API's (fact) and if Apple clearly indicates that they want you to use only the official API's (fact) and then they personally deprecate the API and tell you that you should be using something else, I'm pretty sure that apps that still use the UDID are going to be rejected from the app store admission process. I mean why wouldn't they? Maybe they will let some apps update for a while without kicking them out because it takes a while to work out an alternative, but new apps would likely be rejected.

Anyway this whole thread is just an example of why people don't like developers. What a colossal waste of time arguing over the exact meaning of the word "killed." It's always going to be somewhat subjective and it's not like "killed" is some official programming term that means something specific anyway.

Every other site is reporting this story is using the word "killed" to describe the situation. Any normal person can see that Apple just "killed" the use of UDID's. If developers want to whine and argue over the exact meaning of the word or wait until Apple actually forces them to change or leave the store, all I can say is that I'm absolutely certain that no one really cares.

You are wrong. And do people "not like developers", or does Professor Peabody not like being contradicted by experts?

Let me explain terms.

1) An api is deprecated when it generates a warning on compile that it will be going away, or private, some time in the future. It is still a public API.
2) An api is hidden or private when it moves from the public to the private headers of a framework ( or has always been private). Still usable, but you have to hack it to compile. On OS X this would allow you to build using private APIs and sell (outside the Mac Store) - however these apis are not guaranteed to continue to work so you would likely break going from OS to OS. On iOS it would be rejected at the app store, the only way in.
3) An app is rejected from the app store when it contravenes Apple's policies.

As it happens, with regards to 3, there is a policy to ban private api, but not deprecated api.

unfortunately, this report is using the term deprecated in ( possibly) a non technical way. It is possible that the API has been made private. It may however, just generate a compile warning in the public header, meaning it is going to go away sometime. Possibly in iOS 6. Since I dont have the latest SDK I dont know.

That said there is, now, no restriction on any app submitting using the iOS 4.3 SDK continuing to use the UDID API. Thats because Apple's policy ( see 3) have not changed, and the API is available on iOS 4.x. They may change their policy, but at the moment - as it now stands - apps can submit for iOS 4.x, which is what they are all doing, with this API intact. Since it is intact in iOS 4.x. and developers are building for iOS 4.x only at the moment, no app is being killed at the moment. If the API is merely deprecated ( generating a warning) then apps for iOS 5 would not be deprecated either.

As devs are not going to build exclusively for iOS 5 for a while, then this is also moot. Now, Apple may change their policy at the app store, but it would be that change of policy which would ban existing apps built against 4.x from using the UDID api, not the change to a header file in iOS 5.0,

( and that would be a very strange policy, as the UDID API is a formal API from Apple, declared in headers. An API is a promise to work, and a promise that the work is "legal". Banning apps built against iOS 4.x from using an Apple approved API for iOS 4.x would be weird indeed).

So nothing is banned, or killed yet. Lets use terms exactly rather than what the peanut gallery thinks it is.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #26 of 37
Quote:
Originally Posted by asdasd View Post

In that case you can't use the API as it is not available. The question is can you build against the 4.x SDK and submit using this UDID API , which would run on iOS 5.

I think so.

Since iOS 4.0 came out, each new Xcode version ships with only the latest version of the SDK (Before that, you would have 2.2, 3.0, 3.1 etc and you could choose the target).

Unless you keep backups of previous SDKs and "manually add" them to your Xcode config (I'm not sure about the details of this), it is currently not possible to build against an SDK version lower than the one that shipped with your version of Xcode.

You can still set the 'minimum supported version' (i.e. deployment target ) all the way back to 3.1.x... What happens then, if you use 'deprecated' APIs? (e.g., UITableViewCell's setText My experience is that they get marked as deprecated in the docs and you get a nice, yellow warning in Xcode. Never pushed it so far as AppStore Submission, so can't really tell if Apple will reject it or not.
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
post #27 of 37
one question, willapples own iad network utilize teh UDID? Is this meant as a privacy move of just a way to give their in house ad network a leg up?
You can't quantify how much I don't care -- Bob Kevoian of the Bob and Tom Show.
Reply
You can't quantify how much I don't care -- Bob Kevoian of the Bob and Tom Show.
Reply
post #28 of 37
Quote:
Originally Posted by a_greer View Post

one question, willapples own iad network utilize teh UDID?

If it doesn't now, it won't later.

Quote:
Is this meant as a privacy move of just a way to give their in house ad network a leg up?

No, it's a "This is a private API now, thanks very much," move.

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply
post #29 of 37
Quote:
Originally Posted by Tallest Skil View Post

If it doesn't now, it won't later.



No, it's a "This is a private API now, thanks very much," move.

Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.

And since Apple apps are not restricted from using private API why would they stop?
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #30 of 37
Quote:
Originally Posted by asdasd View Post

Do you have any proof that Apple don't use this API? are you saying that when it was, and is, public in pre iOS 5 builds the normal dev could use it but Apple didn't? Unlikely.

And since Apple apps are not restricted from using private API why would they stop?

Do you have any proof that they will use it? Apple is innocent until proven otherwise.

Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
I've accomplished my childhood's dream: My job consists mainly of playing with toys all day long.
Reply
post #31 of 37
Quote:
Originally Posted by asdasd View Post

Do you have any proof that Apple don't use this API?

Oh, no no, I have no idea myself right now. I'm just saying that if anyone looks into it and finds that iAd doesn't use it right now, then it likely won't be using it in the future because it wouldn't need to be. Apple wouldn't stop using it if they WERE using it now, but if they're not currently using it, I don't see them starting to do so, is all.

Sorry for the confusion.

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply

Originally Posted by asdasd

This is Appleinsider. It's all there for you but we can't do it for you.
Reply
post #32 of 37
Quote:
Originally Posted by ranReloaded View Post

Do you have any proof that they will use it? Apple is innocent until proven otherwise.

Before this turns into a conspiracy theory of how evil big-corporation-Apple is, I would like to take a minute to think of for what on earth they would need your UDID. They have your iTunes account, Apple ID, Credit card, iCloud account... That's much more valuable than the UDID of your "old iPhone 3G-become-kids-ipod-touch".

The API is not now illegal so there is no restriction on Apple using it now, and since Apple apps can use the private API no restriction in the future. They probably use it in IAds but nowhere else, because poeple dont log in once the app is downloaded ( apps using iAds are generally free and may not use iCloud). The idea of the UDID is to sample when the app is used, or where the user goes to in the app ( per run). I think analytic packages like Flurry use it.

In any case I dont think the use of a UDID was all that big a deal, as devs use it not to match information on users with other devs because the individual dev does not have the information from other devs s (Flurry might, however) but for simple purposes of per device heuristics. i think this an over-reaction by Apple.

The general use of the UDID is not an issue, Apple using it mght be ( as a uncompetitive act) but I cant say either way whether they do, or not.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #33 of 37
I had read somewhere that UDID was used by a few devs to limit the number of authorized devices, against the terms of their contract with Apple. Has anyone else heard of this? I tried looking for the reference and can't find it.
post #34 of 37
Quote:
Originally Posted by Booga View Post

This is a nice move on Apple's part, and helps differentiate iOS from Android.

The biggest difference between the two right now IMO: Android requires your specific consent, opt-in, to share your details with any third party. Apple on the other hand requires that you opt-out if you don't want your personal data shared with others outside of Apple. If you don't take the time to visit Apple and change your privacy settings, Apple has the right to share your personal information with others without notice to you.

And while Google is trying to disallow fake names on Google+, Apple asks for your Social Security number, the ideal tracking number to link all your data together from public and private sources. Which is more of a red flag if personal privacy is a primary concern?
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #35 of 37
Quote:
Originally Posted by Smallwheels View Post

I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users.

That would be like ordering a product from a mail-order catalogue and refusing to give them your mailing address.
post #36 of 37
A good solution to this would be for the OS to provide a hash code based on the UDID and your app's signature. Then you couldn't access the UDID to compare with other app vendors because the hash is unique to your device AND app.
post #37 of 37
Quote:
Originally Posted by Smallwheels View Post

The more privacy people have the better. Now why don't they create a feature in Safari that prevents all web beacons? I think all computers should not even have MAC addresses. There needs to be total privacy on the internet for users. As the US government and other governments constantly spy on us, we need more privacy not less. Even ISPs have been shown to track the habits of their customers.

Start a collection, lets launch our own satellites!
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
AppleInsider › Forums › Mobile › iPhone › Inside iOS 5: privacy change kills app developers' access to UDID