I would imagine there are plenty of ways to get a unique ID for a phone, by fingerprinting the system or saving a cookie, so Apple providing an ID in the API is not really an issue. These are the issues:
tl;dr version: it shouldn't be possible to pull out somebody's account information based solely on the UDID.
It's simply wrong to authenticate people based solely on UDID anyways - what if the same user have one iPhone 3GS, one iPhone 4, and an iPad 2? In that case you'd need another authentication mechanism to make sure the three devices belong to the same user. The UDID is good only for telling the devices apart. So if you gave me Jane's iPad's UDID, I shouldn't really do anything unless I've made sure you're Jane in the first place.
Yes, that's what happened to me. I sold my iPhone 3G to my friend ( obviously, I had wiped it before handing it over to him).
Now, I had Fruit Ninja installed, and I had signed up for openFient.. and approved the facebook connect.
Imagine my surprise when a day later - my friend installed Fruit Ninja - so not only did it log me in, it also published to my facebook wall as me. Ended up revoking permissions - something which I should have done, but forgot to do so.
The OpenFeint model is to use device-level accounts so you don't need to make people sign-up to the service. If they choose to create an email based account with a password, then they can tie their various devices together.
It wouldn't surprise me if something similar were happening on Android. To minimise issues like this, I use DroidWall on my rooted G1 to prevent apps connecting to servers on the net if I don't think they have a good reason to.
FTA, keep in mind that issue is not whether there are unique identifiers of any sort on phones. Any of the IMEI, SIM, or UUID (or equivalent) on a phone can uniquely identify you. This is a fact of life.
However, the real issue is whether your phone can share such information _without your explicit permission_. This is _not possible on the Android_.
You need to have android.permission.READ_PHONE_STATE permissions in order to get the unique identifier, hence users, before installing an application, will be able to determine whether their particular application is capable of doing so.
FFS, that's what "Read phone state" means? I've been installing apps that request that as I thought it meant it let them not interrupt my calls, or closer nicer when a call comes in, or something along those lines. It seemed a bit odd, but I had no idea it exposed yet another unique ID.
Android needs a system-wide setting that simply returns a null ID (or app+hardware specific ID, so it's useless for tracking) to all apps, regardless of specific app permissions.
Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like.
----- SNIP -------
But those should be two separate permissions. One for checking if the user is on a call and a different one for reading the UDID, IMSI or IMEI.
I wrote a streaming media app and I request that permission so I can mute audio when a call comes in.
I don't need or want users' other personal details, muting audio on a call is just what good apps do. I hate how shady my app looks on the market when it's listed as requesting permission to get a user's IMEI and subscriber info.
Notice that the pattern becomes problematic when you include facebook in the picture, because that's where people give away their real data. I don't think it's an issue with UDIDs - they are an essential component with minimal privacy implications in itself. The problem is mostly with facebook's weak privacy tactics. There is no privacy setting that can hide your fb uid, and indeed, facebook has been very lax about giving it away to just about anyone.
1. OpenFeint needs to lock down their DB
2. Phones are great for spying on people