Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
It's more than just about ads, the ads thing is just one example. It's just not secure to be storing and matching data based on a unique id (previously) available to all apps.
So hypothetically what's to stop App developers from trading the same sort of unique ID's themselves? Is this something prohibited by the Apple Developer
s agreement? Or just risking bad word of mouth about an app secretly beaming your info to a third party?
 
Wouldn't banning app store reviews under any beta OS be easier to assuaging developer concerns?

That's not why they did this.

----------

So hypothetically what's to stop App developers from trading the same sort of unique ID's themselves? Is this something prohibited by the Apple Developer
s agreement? Or just risking bad word of mouth about an app secretly beaming your info to a third party?

Developers won't actually have access to the UDID anymore. That is, unless they use a private API which Apple can detect and reject the app for.
 
1) To finally put an end to incentivized installs through networks like TapJoy and Flurry (they currently are able to track installs by users' UDIDs)
Can you explain how tracking users by UDID allows them to continue incentivizing installations when the apps can't have advertising in them (which was already banned a couple of months ago)?

Do you mean outside of the App they are marketing to users other Apps. whose developers get a cut from piggy backing off of the firs app that was installed?
 
Wirelessly posted (Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9A5288d)

This could be related to the tracking of gps data that got them in hot water a while back.
 
I believe the Pandora app is one app that uses UDID to keep track. Let's say I was logged into pandora on my iPhone and then compeltely wiped the device. I could download and install Pandora and not have to login. Pandora would recognize the UDID and authenticate.

Other applications utilize UDID as a sole means for authentication, in other words your account and info with that app is tied to your device(s) UDIDs.

The UDID is a terrible way to identify a user. There a many reasons for that including the device is:
  • stolen,
  • replaced,
  • sold or
  • given to someone else

Exactly! I've always hated apps that use UDID to identify you. Take Pandora for instance. If I sell/give away my iDevice, and the new owner downloads Pandora, all of a sudden, they are looking at my Pandora playlists, despite my having wiped it to factory state before handing it over to the new owner? That's not desirable behavior at all.

As for games that tie their gaming accounts to UDID, each time I got a new device, I had to jump through so many hoops to get my account moved to the new device, I just stopped playing them.

So I'm really glad Apple is putting a stop to this. It's about time!
 
That's not why they did this.

----------



Developers won't actually have access to the UDID anymore. That is, unless they use a private API which Apple can detect and reject the app for.
Makes sense that they would reject an app that tagged the user's device with a 3rd Party ID system through the app ... Is there a specific prohibition against this or an established prohibition?
 
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5)

Smart move on Apples part!
 
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5)

Smart move on Apples part!

and why is that :rolleyes:
 
My real question is, where would that unscrupulous advertiser be putting the ads that the developer is providing the context for that's so unscrupulous? Obviously they're still going to be identifying users *within* their own apps and serving context-based ads to them there, no? Is this just a matter of who is providing the infrastructure for the in-app ads or is there some larger play that advertisers have been making to get UDIDs for other purposes?

The advertisers and other groups offer multiple apps or get UDIDs from multiple sources on a single phone. That means you can actually start tying together their behavior across the device as a whole rather than inside a single app. This is a sort of 'information leak' that most users aren't even aware of. This UDID makes such a profile easier to build since you can even tell which apps that user opens in what order over the course of a day if you wanted, for how long, and so on.

By forcing each app to produce their own UDID-like hash, it makes it a lot harder to produce this type of profile. Instead of a single ID, you have a half-dozen or more. Then the trick is that you have to figure out which group of IDs actually matches up with an individual. If you can't get past that hurdle, then the information you can glean indirectly is more limited.

EDIT: And the real problem with this style of information leak is that advertisers see this as a good thing. Targeted ads are a holy grail, and so the better profile they can build on people, the more valuable their ads are to the ones buying ad space. Even Google does this type of profile building (Chrome is even built to help them build the profile more easily since you don't need to visit sites using Google ads/services to build it). So if you are the type of person that doesn't like this information leak, moves like this are a benefit since it is one of the few ways to enforce a policy like this is simply deny the information from the app to help tie things together.
 
Last edited:
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5)

If you have to ask...
 
The advertisers and other groups offer multiple apps or get UDIDs from multiple sources on a single phone. That means you can actually start tying together their behavior across the device as a whole rather than inside a single app. This is a sort of 'information leak' that most users aren't even aware of. This UDID makes such a profile easier to build since you can even tell which apps that user opens in what order over the course of a day if you wanted, for how long, and so on.
Hmm so is the "security backlash" on Apple what caused them to shut this down ... I mean, doesn't this information help iAds too? Or does iAds get to see everything regardless 'cause they're the king? :D
 
This is a great idea! Maybe now all the impatient people here who are not developers, will learn to wait for the release like the rest of us.
 
I just registered an account to say FINALLY!!! Damn it was annoying to be trying to install updates/apps and it minimized while I was looking at something.

Btw, /wave MacRumors

Welcome to MacRumors forums :) I hope you enjoy any time you spend here. I love this community, and they've helped me with a ton of things, especially my original concerns a year or so ago when I was switching from windows to OS X. :D
 
I love this company. (And I'm not a fanboi of Apple or any other company.)

I get this is a swipe at Google and their spying ways. Apple is quietly building an ecosystem that consumers can trust. And they are doing it without running their mouth about it.

But with that said, I think people like Jobs hate tacky ads and sketchy tracking. It slowly killed Tivo (in addition to other things) and as consumer awareness rises, this is going to be a huge competitive advantage for Apple.

Smart move, and as a consumer, I will happily pay more for hardware, OS updates, apps, and cloud services which protect my privacy today and in the future.
 
Apple is instead asking developers to create unique identifiers specific to their apps in order to tie installations to specific users.

Simple solution for Apple: give apps a UDID which is a combination (ie. hash) of the real UDID and the App ID. Still unique, but non-trackable across apps. Make it a new function and reject apps that use the old code.
 
I get this is a swipe at Google and their spying ways. Apple is quietly building an ecosystem that consumers can trust. And they are doing it without running their mouth about it.
Did you miss this one? http://www.wired.com/gadgetlab/2011/04/apple-iphone-tracking/
But with that said, I think people like Jobs hate tacky ads and sketchy tracking. It slowly killed Tivo (in addition to other things) and as consumer awareness rises, this is going to be a huge competitive advantage for Apple.
Also there's been no word as to whether Apple will stop 1 big advertiser from using the UDID information ... namely themselves http://advertising.apple.com/

But you'll probably just love their ads anyways because those ads come from Apple, right?
 
sounds like Apple is doing this to lock down their own ads, Force game center on more people oh and make cross platform development harder.

This is more about lining their own pockets. Apple has zero interested in protecting the users. It makes it so only Apple has that data and no one else.
 
Bundle ID specific

Why don't they simply return a hash of the UDID concatenated with the apps bundle id?

This yields to device specific identifiers, however bound to an application so ad networks no longer have insights in what applications are being used on a certain device.
 
This is a change that is going to cause a lot of headaches for developers. It would be extremely useful if Apple provided us with an alternative to use. How about a hash of the UDID and app's bundle ID?

Edit: No idea why this is attracting negative votes!
 
Last edited:
So before an unscrupulous developer could, say, tie your UDID to the personal information it pulls from you and then ... what, provide the information to an advertiser using that UDID to serve contextual ads to that user based on the UDID?

My real question is, where would that unscrupulous advertiser be putting the ads that the developer is providing the context for that's so unscrupulous? Obviously they're still going to be identifying users *within* their own apps and serving context-based ads to them there, no? Is this just a matter of who is providing the infrastructure for the in-app ads or is there some larger play that advertisers have been making to get UDIDs for other purposes?

this is a way to make advertising on iOS less profitable for anyone who doesn't use iAD
 
not thrilled

Well, I gather analytics from Flurry in my app. Those analytics are pretty valuable to developers to help guide development. I can tell you what percentage of my users have jailbroken devices, what parts of my app they use most frequently, and even put together some solid numbers on what percentage of users I retain over time. Using Flurry gave me awesome, helpful stats without having to spend a bunch of time creating the system myself. I'm fairly sure Flurry will just do something different to track installs and usage, so I'm not overly concerned, but it will mean having to submit a new version of my app using a new stats library I'm sure.

It's not like losing access to UDID's is going to stop advertising. If anything it probably makes it worse. When you can target ads precisely, you can bombard less and target more, without the ability to target, you pretty much have to carpet bomb. The advertisers will never just concede mobile and go away quietly. There will be ads and they will have your info.
 
Well, I gather analytics from Flurry in my app. Those analytics are pretty valuable to developers to help guide development. I can tell you what percentage of my users have jailbroken devices, what parts of my app they use most frequently, and even put together some solid numbers on what percentage of users I retain over time. Using Flurry gave me awesome, helpful stats without having to spend a bunch of time creating the system myself. I'm fairly sure Flurry will just do something different to track installs and usage, so I'm not overly concerned, but it will mean having to submit a new version of my app using a new stats library I'm sure.
I imagine that within your app this wouldn't be much of a problem. I'm not that familiar with the implementation of Flurry but depending on how it collects that information you could retain 100% functionality in that regard as that information I would think would be visible from within your Apps own little ecosystem.

Definitely hear you about the ad targeting though ... my guess is that Flurry and others are going to perhaps have sign-ins of their own of some nature that will allow them to target through the various non-globally identifiable IDs that the app users get from the third parties who use their services.
 
It's more than just about ads, the ads thing is just one example. It's just not secure to be storing and matching data based on a unique id (previously) available to all apps.

It's kind of a security issue at the user level as well, if another user spoofed your UDID they could gain access to your data if that's how an application was matching data to it's users.

Wow, ads targeting like Mass Effect, or people greeting like Minority Report!

Imagine walking in a mall and at the front gate greeted using our names.. followed by <insert spam junk here> advertising based on the collected data.

"Good evening Mr. Doe, we have some special offers in our store and it sure can make your wife happier like never before.." :eek:

Then, suddenly all the world knows Mr. Doe's problem.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.