I'm not sure why the UDID would eever have been exposed to app developers. It seems the API should offer an ID that was the result of the UDID run through some sort of hash seeded by project or at least developer cert.
It is not. It is the Device Id that is exposed. Assuming the same user is using the device, you can track that user across application, and advertisement companies can get a clear picture of the user's preferences by aggregating the data coming from all apps.
Some apps have legitimate need for the device id though.
I agree with the seeded hash of an UDID. A developer can track one user across handsets, but two different developers can't tell form the hashed uid if it is the same customer.
This solves both the problems of 1. developers having to implement full blown account/login systems if their app is offering subscription services when a simple user id would suffice and 2. not allowing the user to be tracked across services.
Advertising companies also have legitimate needs for tracking exposure to advertising across applications. Frequency caps, for instance -- advertisers buy inventory across multiple applications with the explicit provision that a user won't be shown the same ad creative more than a specified number of times in a given period.
Not having cookies accessible across applications is the true design flaw. No one particularly wants to use the UDID for anything. Everyone would much rather use exactly the same infrastructure used for web advertising.
