
Apple phasing out developer access to the UDID in iOS 5 - canistr
http://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-udid/
======
pkaler
UDID has been deprecated because iOS 5 supports a general purpose credential
store. Instead of reading a UDID, an App drops an identifier. Very similar to
how a web app would drop a cookie.

The token can be shared across Apps using oAuth. This is how Twitter
integration works.

So, for Apps that use Flurry, Flurry would drop an identifier into the
credential store. Then Apps would access this identifier using an oAuth token
and token secret.

If you have access to the iOS 5 docs take a look at ACAccount, ACAccountStore,
ACAccountCredential.

~~~
Zev
While that may functionally be a replacement for UDIDs, that is not the
intended purpose for those classes. They're supposed to do a lot more.

------
ansy
Now Apple just needs to do something about the address book and we're good. I
don't particularly like any random app having silent, unrestricted access to
my entire address book. It's only a matter of time before we find out some
super popular free app has been sucking down contact lists and I don't trust
the Apple review process to protect users.

There should be a "this app is trying to access your address book"
notification and per app permissions in Settings just like Locations and Push
Notifications.

~~~
nostromo
> It's only a matter of time before we find out some super popular free app
> has been sucking down contact lists

I believe that moment already came and went when people discovered the sync
feature on the iPhone Facebook App sent all of your friends' phone numbers to
Facebook. (<https://www.facebook.com/friends/edit/?sk=phonebook>)

For the record, finding this didn't particularly bother me and I did approve
it -- however unwittingly. (I thought I was just pulling info from facebook,
not sending info back.)

~~~
ansy
Facebook has a responsibility to do the right thing or lose a lot. It has
executives, investors, and assets which are all exposed to lawsuits and
criminal investigation.

A dude in Thailand that makes a free "Angry Birds Cheats" app does not have a
lot to lose. In fact he could probably get away with putting something up on
the app store with a stolen identity. The app could suck down millions of
people's address books with real names, real birthdays, real phone numbers,
real addresses, a network graph, and maybe more completely silently. You know
the network activity indicator doesn't even activate unless it's flipped on
and off programmatically? Best case scenario Apple finds out, takes the app
down, and tells the Thai police to go find the guy? Good luck with that. Worst
case scenario nobody even notices and the app disappears after sinking off the
charts.

There is zero consumer protection against the latter and quite frankly the
former shouldn't be an issue to begin with either. Facebook was getting away
with it without getting caught. How many of those other high throughput apps
that aren't from Facebook receive the same scrutiny from the public and
researchers?

~~~
tjoff
"Facebook has a responsibility to do the right thing or loose a lot. It has
executives, investors, and assets which are all exposed to lawsuits and
criminal investigation."

Couldn't care less. The fact that they did this without being clear and honest
about it is more than enough to completely obliterate any trust they might
inherit for having much to loose. Especially since this alone should be more
than enough for them to "loose a lot".

There is absolutely zero consumer protection against facebook as well.

And then you take into account that people most likely have had secret phone
numbers in their contact list, what facebook did/do should be a criminal
offence, especially considering they are a large corporation and exploits the
inherited trust from that.

------
saurik
The UDID is a SHA1 of a few other identifiers, such as the MAC and Serial #.
What Apple should just do is include the base Application bundle prefix
(whatever the thing is that is used to give applications shared keychain
access) into the mix as a per-application-suite salt.

~~~
Aqua_Geek
I completely agree. You should file an enhancement request.

There are so few legitimate reasons to have access to the UDID in the first
place - I was surprised Apple even allowed it. An app- or app suite-specific
identifier, though, could be very useful (and would work perfectly as a
replacement for a number of the cases about which people are complaining).

------
sanj
There are legitimate reasons to ask for a phone UDID -- namely tying together
information from multiple applications. GameCenter does this, but only for a
specific subset of games.

Is someone going to come up with another fingerprinting mechanism?

The obvious approach is to use the MAC address:

[http://stackoverflow.com/questions/677530/how-can-i-
programm...](http://stackoverflow.com/questions/677530/how-can-i-
programmatically-get-the-mac-address-of-an-iphone)

~~~
spearo77
If you have a suite of apps (free/paid) or that work together in a meaningful
way, you can use a unique pasteboard to persist shared information.

If you did that for advertising reasons, I'm sure Apple would reject/revoke
the apps once they found out about it.

~~~
sanj
Would that persist across resets?

~~~
spearo77
The pasteboards are persistent across power-cycling.

They may even survive restoring from backup (say after upgrading iOS or moving
to another device), but I haven't tested that.

------
ethank
I think that this is mostly to force people toward AppleID/iCloud as a
universal method of authentication, as well as a reaction to the Germany and
South Korea lawsuits over location data.

It makes sense that Apple wants iCloud to be the defacto method of cross-
device and application authentication.

In my time doing iPhone apps in the music business, I had many ideas of how to
use the UDID for aggregated statistics and data, none of them entirely holy
from a "own your data" perspective.

So mixed: as a product developer, the UDID was handy to have. As a consumer, I
would rather my AppleID (something I can change/cancel) be tied to it.

~~~
kennywinker
Sounds good. Show me how to use iCould/AppleID as authentication in my app.

Oh, wait... you can't?

Mostly kidding. Deprecating the UDID seems like a good thing, as the #1 use
was advertising. It'll be annoying for developers, but not that bad... you
just assign a UUID on first run. No big deal.

~~~
gte910h
If you're talking about the NDA, yes, that's true. But Yes, go read the iCloud
docs, I think this is the point of this as well.

------
pilif
When we were writing an iPhone client for our web application, we were
considering using the UDID as part of the authentication dialog with the
server to allow for easy removal of devices if they get lost and to never have
to re-prompt the user for their password.

In the end though, we decided against the UDID and just generated a random
"installation id". This works much better in all regards:

1) when the user updates their device by applying an old backup to the new
device, the app would continue to work exactly as before.

2) if the user wipes and sells their phone, the next user wouldn't
automatically get access to the webapp if removing the device from the app was
forgotten.

3) when something goes wrong and users try to reinstall the app, the user
experience will be pristine, the server wouldn't know who you are.

4) the sometimes privacy sensitive UDID is never transmitted over a network.

5) it's not using deprecated APIs :-)

~~~
xsmasher
What happens if two installs get the same random ID? Doesn't the new user log
in as the old one?

Getting the UDID+installID and then saving that into a file/preference would
work, or installID and username.

~~~
beder
I'm doing this too, and we're using a 128-bit random GUID, which has an
unfathomably small chance of being a duplicate.

------
trotsky
I wonder if google will feel any pressure from this decision to at least
separate out the "phone state" and "phone identity" permissions. Given their
advertising focus it seems unlikely that they'd remove it entirely, but at
least make app developers be up front about what they're requesting. It's too
easy to blame that permission on needing to pause/mute etc. during a phone
call currently.

~~~
plusbryan
One thing that Google did well when building their platform is integrating
permissions into the install process. Like Facebook's OAuth permissions, users
understand how to interact with this. Don't care about ads tracking you but
want more features that rely on tracking? [x] Allow tracking.

If Apple took a page from their book, they wouldn't need to take such drastic
action, but instead let developers decide if users want the features that
require those permissions.

~~~
comex
There is no "allow tracking" button: the user gets a list of required
permissions and either installs the application, granting all of them, or
doesn't.

------
sirn
There was this one time when I restore my iPhone without using backup, one
application restored all my favorite items without me ever input anything into
the application. There's no mention of this "feature" in their product page as
far as I found find. While it's useful, it's rather scary that this could be
done completely without user acknowledgement.

IMHO, removing UDID access is good, though I would prefers if they introduce
something similar to Location Service and let me whitelist which app to allow
reading UDID.

------
notphilatall
It's a shame, because UDID-based user blocking has been quite effective for a
lot of apps and communities. I suppose users could authenticate via iCloud,
and Apple has an interest in users doing this, but it's a bummer for UX.

~~~
blasdel
That's ingenious — per-device permabanning!

------
jazzychad
I guess this will be a great new feature for Parse to offer iOS devs.

------
tptacek
This is a good thing; you wouldn't know it because you don't install a lot of
enterprise iPhone apps, but UDID "abuse" (ie, broken security systems that
pretend the UDID is something akin to cryptographically strong) is one of the
top 10 security things that go wrong with iPhone apps.

I'm not sure I can think of anything the UDID does that you can't do better
yourself.

------
laconian
Good stuff. Let me as the user dictate the terms for how I am identified.

------
bnycum
We are using the UDID as an extra precaution in an app currently. The user
logs in with username, password and UDID. If the device is stolen the UDID for
that user's device can be easily removed. We are dealing with sensitive data
that needs a killswitch when things do go wrong. Guess we will have to come up
with a new approach.

~~~
nitrogen
You could just store a randomly-generated authentication token on each device
and allow the user to revoke any/all authentication tokens after entering
their username/password in the app or on a website, if that's not what you're
doing already.

------
llambda
So does this mean things like TestFlight will no longer work?

~~~
justinvoss
I'm sure Apple will still use the UDID for provisioning. This change sounds
like they're removing access to it from the device API.

~~~
sumukh1
Testflight seems to be grabbing UDID's to identify users. You still need to
get UDIDs in your provisioning profiles though. It'll make beta testing harder
since users will have to use itunes to get their UUID. I'd love it if Apple
would let users see their UUID and email it.

~~~
ldar15
They make it so difficult in fact that just yesterday i got a screenshot of a
UDID instead of the text because apple makes it look like you cant cut/paste
the thing. Sooo frustrating.

------
incosta
I have been using UDID to track on how many physical devices my app has been
installed. In part - to see if there is any piracy (a spike in new devices
would certainly mean something is going on).

If Apple removes support for UDID completely, I will have no way to track this
information. Generating unique ids randomly will result in new ID being
created when app is deleted and then reinstalled (something that happens all
the time with iPhone apps). Are there going to be other ways to create unique
ID based on some hardware specs, or Apple will provide a new function call?

------
graiz
I run a company called <http://www.AppBlade.com> and we provide a service to
do OTA (Over the Air) installation. This OTA technique is the Apple
recommended way to do secure wireless installation for enterprises to a
specific hardware device (via UDID.) Anyone with access to the latest betas
can try it and see that yes it still works.

------
spearo77
Remember this is deprecated, and not yet removed. TestFlight and UDID Sender
etc all still work fine on the current betas of iOS5

~~~
jayfuerstenberg
There should be a permissions-based access to it in my opinion. The same way
that your current location is allowed to be viewed by the app.

My app (KEYBOX lite) uses UDID to help thwart cheaters who reinstall the lite
edition and simply reimport their data from an earlier install. I know I'm the
exception and not the rule but if I could ask for the permission to use the
device ID in the lite edition I could still do this.

------
mtogo
Wow, this is really fantastic news. I've always been annoyed at the huge
privacy vulnerability developer access to UDIDs posed.

------
dendory
The main use (as far as benefiting users) for the UID was so that you could
install an app on your iPhone, and without ever using any kind of
username/password it knew who you were and restored all your data. Of course
it also meant ad networks could track you as well. So overall this is a good
change, just kinda weird it comes in so late.

------
tobylane
Is this related to the hardware identifiers? When you sync any mobile Apple
device to a computer it keeps some data, such as phone numbers, IMEI numbers
and what I think is the UDID, which is all the ipod has. We need some
replacement, if only to help the police track stolen ipods.

------
seanalltogether
I can understand the desire to discourage people from tracking the device
itself, but this really has to be used unless Apple decides to provide a way
of identifying the user of the device.

~~~
danilocampos
They have – it's called iCloud.

<http://www.apple.com/icloud/>

------
spearo77
What happens to analytics companies like flurry??

~~~
lawnchair_larry
Hopefully they disappear. But, probably not.

~~~
nhangen
Why would you want them to disappear? I have Flurry installed in my apps to
help me identify usage patterns, and see which types of people use my apps. I
don't think there's anything wrong with that.

------
axiom
This will result in _a lot_ of broken apps in the app store.

~~~
danilocampos
Why?

edit: Seriously, Why? And why the down votes?

The API is deprecated, but so far not removed, there's a lot of lead-time, and
iCloud is going to exist for user identification.

Are there truly that many apps whose assumptions are so brittle and developers
so absent that this change will _break_ them?

(Unless OP meant _business models_ assumed in apps that need to identify
everyone, even if they don't want to. That's valid, if less interesting.)

~~~
coffeedrinker
Because developers have used it ID to store user information on servers, etc.

This allowed a simple way to keep user data without worrying about additional
setup, username, login, etc.

If it is gone (and not merely deprecated) then developers need to get an
update out now that can read the ID and cross reference it to other code.

Otherwise, all settings that might be stored by a user on a server will be
lost if the developer relied solely on using this ID.

~~~
danilocampos
But will it break _lots_ of apps?

Assuming access to the UDID – and absolutely nothing else – is... dumb. What
happens when users change devices, for example? I'm having a hard time
imagining any large number of apps that are _that_ reliant on this one thing.
Even OpenFeint had provisions to handle non-UDID-based account authentication.

~~~
gte910h
Sometimes users have different things on different devices.

Hell the requirements for auto-renewing subscriptions pretty much FORCE you to
track udids.

