iOS developers: Say goodbye to UDIDs • Hacker News Board

Re: iOS developers: Say goodbye to UDIDs

#41

Post by ryanpetrich » Fri, Mar 22, 2013, 2:10 PM UTC

jayfuerstenberg wrote: post #15

tstyle wrote: post #13

Earlier quoted context omitted.

I've been using this library for my projects: https://github.com/gekitz/UIDevice-with-UniqueIdentifier-for... MAC Address based solutions are still okay right?

Access to MAC addresses will likely never go away. Also, if you don't need to identify devices per se, you can fallback on a generated GUID which you persist via NSUserDefaults. It'll identify the user for the lifespan of that app install on the device.

I suspect access to MAC addresses will go away at some point—it has the same privacy concerns as UDID.

Re: iOS developers: Say goodbye to UDIDs

#42

Post by tqc » Fri, Mar 22, 2013, 2:42 PM UTC

buddydvd wrote: post #33

tqc wrote: post #29

Earlier quoted context omitted.

Never noticed that as I don't have any in app purchases that actually cost me anything. This usage would seem to be more because the ID is available rather than because it is needed though. The bit about non-public APIs on that page is interesting though - if there is a genuinely necessary use case for device IDs it may not be affected.

The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.

True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.

Re: iOS developers: Say goodbye to UDIDs

#43

Post by buddydvd » Fri, Mar 22, 2013, 3:42 PM UTC

tqc wrote: post #42

buddydvd wrote: post #33

Earlier quoted context omitted.

The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.

True, but that is only one solution and a flawed one, as device ID can legitimately change - no developer needs to know whether I am using the phone I bought today or the one I bought a year ago.

Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.

Re: iOS developers: Say goodbye to UDIDs

#44

Post by fnayr » Fri, Mar 22, 2013, 7:11 PM UTC

wsc981 wrote: post #39

fnayr wrote: post #34

Earlier quoted context omitted.

Whoa! Thanks for this! I would edit my original comment if it let me. Still it is a hack that Apple could start disallowing at any time.

I don't think the lipo tool will ever be regarded as hack. It's pretty much required when supporting multiple architectures / instruction sets. At some point there will likely be a ARMv8 architecture (if it doesn't exist yet). Also many libraries make use of lipo to create convenient static binaries that can be used both in the simulator as well as on the device.

Well what I mean is I believe Apple will start rejecting apps at the review stage if they see its built with armv6. (Of course it's just my guess).

Re: iOS developers: Say goodbye to UDIDs

#45

Post by gurkendoktor » Sat, Mar 23, 2013, 4:26 AM UTC

pooriaazimi wrote: post #40

gurkendoktor wrote: post #31

Earlier quoted context omitted.

The first two solutions are iOS6+ only, and the UDID never worked on iOS6. People who can live with cutting off iOS5 don't have a problem by definition. Ubiquity container: Does anyone use and track this? How many % of people have iCloud enabled for third-party apps? (Just asking because I turn this off on all devices; I don't have any app that uses this, so all I am disabling is abuse)

What kind of abuse? I'm (genuinely) curious, and being the paranoid OCD that I am, I'd very much like to know these things :)

Some apps push data into the cloud without asking/having an option. For me this was Screens VNC, which synced semi-confidential information across my two computers without asking (all my bookmarks, except for the SSH/VNC passwords).

Arguably the external IP, SSH port, SSH username, internal IP and internal username of my client's confidential computer are only "security by obscurity", but I'd still rather have everything on my hard drive only by default.