
Apple Has Started Rejecting Apps That Access UDIDs Amid Privacy Concerns - dwynings
http://techcrunch.com/2012/03/24/apple-udids/
======
Xuzz
Sadly, this all could have been avoided with one simple change four years ago:
rather than having the UDID match the specific device, have it be hash of the
app's "keychain identifier" (usually set at the company level, enabling cross-
product identification) and the real UDID. Then, it doesn't matter if an app
finds out the UDID it can access: it's specific to that app or company anyway,
and can't be abused as it currently is.

But as the UDID was implemented poorly (and immediately overused for
everything, including from server-side account keying, which Apple can't just
break), they have to essentially remove it now.

~~~
stcredzero
So, are you saying that now, we >can't< use the hash(UDID+keychain_id)?

EDIT: On 2nd thought, isn't hash(UDID+keychain_id) almost as bad as just
squirting UDID over the network anyhow?

~~~
Xuzz
I'm talking about Apple, not about developers. If Apple had returned
SHA1(KeychainID + UDID) instead of just UDID when the SDK was released, then
apps would never have seen the "real" UDID, and we wouldn't have this issue
now. However, since Apple did not do that and they can't change the UDID now
(for a variety of reasons, including various abuses of it by developers), it's
too late for them to fix it now with such a simple change.

~~~
shangrila
They certainly could still add a new API which does something along the lines
of what you describe while still deprecating the UDID API. The only real catch
is that they'd had have to do it in such a way as to make it difficult to
figure out the un-hashed UDID from the value they give you. It's certainly
possible to do that, though. For example, instead of hashing the UDID along
with the keychain identifier, they could hash it along some other app-specific
or vendor-specific info which only Apple knows and is not shared with
developers.

~~~
tomjen3
If a company can reverse engineer sha512 that easily, we got bigger problems
that leaking device numbers.

~~~
maukdaddy
And that company sure as hell isn't wasting time developing iOS apps.

------
uuilly
Yikes. We have a version awaiting review that migrates us off udids. We need
the udid for one last login before they get an oauth token. Perhaps we will
get lucky and apple won't test a migration bc fresh installs don't use it.
This really sucks, we were following the rules and they changed the schedule.

~~~
SquareWheel
That's unfortunate, I hope things work out for you.

To other developers, this is an inherent risk of working under somebody else's
rules. Open platforms like the web are in constant flux, but won't reject you
for political/monetary reasons.

~~~
stcredzero
_To other developers, this is an inherent risk of working under somebody
else's rules._

Yes, but the alternative might be something like a cesspool of everybody
squirting out their UDID either in plaintext or using encryption with an
easily findable key in the app -- resulting in lots of counterfeiting of UDIDs
and potentially lots of bad things enabled by that.

~~~
SquareWheel
You're right, there are pros and cons to both approaches. The web isn't
perfect.

Personally what I'd like to see is a system like webintents.org taking off. I
way of linking sites through services, not just hyperlinks.

------
epistasis
This is a very good thing. The tech industry has taken privacy far too
lightly, and it has the _potential_ to be a really big deal. If a random
person off the street knew what Facebook and ad networks knew about them in
terms of income, product usage, et al, they'd most likely be extremely creeped
out. This needs to be nipped in the bud before it has the potential to affect
the entire industry.

------
SeoxyS
This has one major implication: killing ad networks. Or, more specifically,
killing ad targeting and CPA.

Advertising is not going away. Let's face it, people are just not willing to
pay when it comes to the type of games that are popular on the iPhone. That's
in large part a result of the race-to-the-bottom environment Apple created
with App Store. Advertising is what makes this economy work.

Whether it's ultimately a good thing or not to kill advertising is a debate
I'm not going into (tho, I'd personally err on the side of it being a good
thing long term). But, good ad targeting and CPA has the effect of improving
the ad experience for everybody: making more money, and seeing more relevant
ads.

Admittedly, I'm biased since I'm part of a mobile advertising startup, but I
think Apple fucked up here. Having a way to uniquely identify a device across
apps is very important. I'd suggest creating a unique identifier on device
installation, and formatting the device would reset a new identifier. I know
for a fact that if we were to play by Apple's rules, and this goes through,
we're going to be very hurt by this change.

~~~
demallien
_This has one major implication: killing ad networks. Or, more specifically,
killing ad targeting and CPA._

I for one won't be shedding any tears - as a woman that spends a lot of time
on tech (and hence nominally male) websites, I am decidedly over getting ads
for dating sites telling me how I'll be able to hook up with young women with
no complexes...

Another classic - I hang out on some atheist sites, so _of course_ I'm vitally
interested in some Christian alpha course or what not - after all, I spend
time on sites talking about religion, don't I?

The model is flawed. I find that so called targeted ads are almost entirely
out of phase with my interests, almost comically so. That being the case, I'd
rather not be giving unknown people the ability to more easily monitor my
online behaviour.

~~~
gyardley
This is completely backwards - you're complaining about _untargeted_ ads,
based only on the rough context of the page you're on.

Properly-targeted ads would know you're a) female and b) an atheist and show
appropriate advertising if any was available.

Removing the UDID does nothing to prevent the type of ads you're complaining
about - they work off of context, and context is always available to the ad
server - but it does prevent ad targeting from getting better.

------
nullflux
This seems to me to be something that should have been issued as an OS-level
patch.

Apple could prevent a lot of these issues by using an application-specific
UDID generated by the device. Hash the UDID with a random salt generated from
entropy on the device, and use it only for that app install. Developers then
couldn't track you from install to install, or across their application
ecosystems. Privacy issue averted.

Any existing calls that hundreds of thousands of applications make to
currently get the UDID just return this application-specific one instead.

~~~
Jyaif
They can't patch the OS because some applications rely on the UDID being
constant. For example, some games check if the scores/progress are real by
storing a hash of the scores and the UDID. This allows the dev to check that
the scores/progress file wasn't downloaded from internet.

Changing the UDID would make the application think that the scores were
tampered with.

~~~
gmac
But they could change the kind of UDID returned to apps installed after the OS
update. That seems like a reasonable compromise?

------
jeremyflores
A nifty replacement category: [https://github.com/gekitz/UIDevice-with-
UniqueIdentifier-for...](https://github.com/gekitz/UIDevice-with-
UniqueIdentifier-for-iOS-5). It generates a different token than the UDID, so
you will have to migrate users.

------
aritraghosh007
This company AppsFire is coming up with an alternative standard
[http://techcrunch.com/2011/09/01/appsfire-announces-open-
sou...](http://techcrunch.com/2011/09/01/appsfire-announces-open-source-udid-
replacement-for-ios-openudid/)

------
rbarooah
As pointed out in the article, they warned us about this more than 6 months
ago.

Changing up the timetable isn't great, but there's not much reason for people
to be 'scrambling' to figure out what to do.

------
Sujan
Are there any other sources on this?

This Techcrunch article sounds a lot like hearsay to me, especially the part
about the review teams.

------
Revisor
How does the ability to get the UDID combine with the (recently leaked) silent
ability to access and upload the whole contact directory on iOS?

------
goronbjorn
Does this mean anything for companies that do device management? It seems like
most enterprise apps are logging some kind of device id.

------
msh
But you still need the uuid for push messages, so how are they handling that?

~~~
cmelbye
Push notifications do not use UDID, they use a different device token.

------
pagekalisedown
If you want to switch to using MAC addresses, look up getifaddrs().

~~~
saurik
The fact that this seems to be entirely legitimate entirely undermines the
point of removing the UDID.

~~~
irons
"The point" is to make Congress stop yelling at Apple. Forcing developers to
jury-rig something other than a system API gives them an out, rhetorically.

~~~
saurik
I find the word "jury-rigged" to be a stretch for "get the MAC address". There
is no difference between the BSD API to get the MAC address and the Cocoa API
to get the UDID; maybe to a software historian, but certainly not to a member
of Congress: the level of explanation you are looking at there is "a mechanism
supported by the vendor that returns a unique identifier for the device".

------
ludflu
i hope they dont kill TestFlight

~~~
bri3d
TestFlight uses a device enrollment challenge to get your device identifier,
not native code. There's no native code in TestFlight - that's why it's not in
the App Store and hence can't get rejected. It's just a clever use of Apple's
remote provisioning capabilities (originally designed for enterprise
customers).

So this change both can't and won't kill TestFlight - the only way Apple could
kill TestFlight would be to change the way their enterprise provisioning and
OTA installation process works, which they have no incentive to do as the
process requires very explicit user permission, isn't being probed by
lawmakers, and makes them that much more attractive to enterprises.

------
kingnothing
Everything I've seen about push notifications relies on the device id. How do
you do push without having the udid?

~~~
mpakes
Push notifications use a device token that is separate from the UDID. An app
can only get access to the device token if the user enables push notifications
for that app.

------
jballanc
I'm sorry, but this solution is very much cart before the horse. I think many
people have woken up in a world where most of the "free" stuff they enjoy on a
daily basis _necessarily_ requires the ability to identify them on an
individual basis. I fear people will either have to learn to live with
tracking and profiling as a part of everyday life, or they will have to get
comfortable with the idea of paying for more of the stuff they use.

Rejecting apps for accessing UDIDs does nothing to solve the underlying
problem...

~~~
throwaway64
please stop spreading this false dichotomy, advertising existed before every
move you made was tracked, and it was quite profitable. There is zero reason
that such invasive bullshit is a requirement, period.

~~~
superuser2
Before every move you made was tracked, there were only a handful of companies
that could deliver ads to people: a few TV stations, a few radio stations, and
one local paper. The Yellow Pages. Maybe some billboards.

More competition and greater accountability (you can't really measure
conversion rates for TV ads) means advertising services have to be more
effective. Showing people ads for things they actually want is the best way to
go about that.

Facebook et al do not owe you ANYTHING. The anti-tracking crowd seems to feel
it's entitled to services while providing nothing of value in exchange. That's
not how the market works. Your attention alone isn't worth much if a website
can't show you ads you're likely to act on.

I don't like it either, which is why I run AdBlock and pay for things that are
valuable to me - NYTimes, New Yorker, local paper, and phone (nothing
sensitive on GMail so I don't care). As the saying goes, you're not the
customer, you're the product.

~~~
fauigerzigerk
_Before every move you made was tracked, there were only a handful of
companies that could deliver ads to people_

Yes but that had nothing to do with tracking, it was just the nature of the
medium. I would like to agree with your idea of tracking as payment, but I
really can't, because:

a) Most of the time I don't have a choice. There's no option to pay them money
and even if I pay them directly, they may still keep collecting tons of
personal information about me on top of it.

b) It's sneaky. I don't really know what information they have and how they
use it. I just have a couple of completely meaningless words from their
privacy policy.

c) I don't know the price I'm paying.

The last point is the most important one. The value and the risk associated
with a particular piece of information greatly depends on what other
information it is combined with, but I can't control that. The company could
get acquired tomorrow by some ad behemoth that knows a lot of other things
about me, so the price I'm paying could change after the fact. That's not the
way payment works. I have to know the price I'm agreeing to pay before I enter
that contract.

~~~
superuser2
c) Technically you do. It was in the privacy policy (or what was omitted from
the privacy policy), and in the clause that says the privacy policy can change
at any time without notice.

Deceptive, yes. Personally, I'd like to see more sites adopt privacy policies
written like 37signals: <http://37signals.com/privacy>

If you have the option to become better at serving your customers, you do it.
When you interact with a for-profit organization, they are a) extracting
something of value from your or b) subsidizing the service with funds from a
different business area that does.

Fundamentally, if a business owner can do something to more effectively serve
his customers, he does it. If he runs a free service, those customers are
advertisers.

We need to change consumer attitudes so people aren't opposed to paying for
services they find valuable. When the general public is the customer instead
of the product, it will find its voice more effective.

