UDID
Latest
Mac 101: Finding your Mac's UUID
Most Apple owners are familiar with the UDID, aka serial number, for their iOS device, but did you know that your Mac has a similar hardware UUID too? In this post, I will show you where to find it, so you can use it in beta testing. If you ever volunteer to test a beta Mac app, you will likely need to provide the developer with this hardware UUID. This alphanumeric value is used by the developer to provision an Adhoc version of the software specifically for your Mac. Finding your UUID is not too difficult once you figure out where it is located in OS X. To find you UUID, you must start with the Apple icon in the top left corner of your Mac menu bar. Click on the Apple and then select "About This Mac," as shown above. This will pull up the basic details about your Mac hardware, including its processor, memory and startup disk. Click on "More Info..." to view the detailed system information. This system information box provides additional details on your Mac, but you have to dig one step further to find your UUID. Click on "System Report" button, highlighted above in blue, and then "Hardware" at the top of the screen. Look in the right-hand pane and you will find your hardware UUID towards the bottom of the list as shown below. Once you locate the UUID, you can select it and copy it to the clipboard.
DevJuice: Apple will no longer accept apps that use UDID calls starting May 1
Apple has posted a warning on their developer news site that they will no longer accept apps that reference the unique device identifier, starting May 1. It writes, "Starting May 1, the App Store will no longer accept new apps or app updates that access UDIDs. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6." This move follows almost a year after Apple began enforcing the initial deprecation. In related news, Apple will no longer accept pre-Retina apps starting on May 1. All App Store apps must be built to support iOS devices with Retina displays as well as the iPhone 4" family.
Apple sets a May 1st cutoff for new apps that use UDIDs, don't support iPhone 5 and Retina screens
Apple has been weaning app developers away from UDID and its privacy concerns for more than a year, but it looks like the company's about to put its foot down -- and up the hardware support requirements in the process. As of May 1st, the company will stop accepting new app submissions that demand a UDID to single out individual devices; creators will have to use the ad and vendor identifiers that came with iOS 6. They'll also have to develop apps for Retina displays as a matter of course, including the taller iPhone 5 screen. We can't imagine that the news will please those who have a need for legacy UDID support, or can't easily update a long-serving app for Retina screens, but Apple clearly feels it's time to move on.
Hacker sentenced to 41 months for exploiting AT&T iPad security flaw
Hacker Andrew "Weev" Auernheimer was found guilty last year of spoofing iPad user IDs to gain access to an AT&T email database, and he's now been sentenced to 41 months in prison. The time was chalked up to one count of identity fraud and one count of conspiracy to access a computer without authorization. In addition to the nearly three and a half years behind bars, Auernheimer also faces another three years of supervised release, and restitution payments of $73,000 to AT&T. Prosecutors in the case were asking for a four-year sentence, and reports say that they used both a Reddit Ask Me Anything post that Auernheimer did as well as quotes from the Encyclopedia Dramatica wiki. Auernheimer did give a statement before the sentencing, where he both read out a John Keats poem, and said that he was "going to jail for doing arithmetic." Auernheimer has promised that he will appeal the sentencing, so this may not be the last we've heard of "Weev" just yet.
Apple: iPhone tracking lawsuit doesn't demonstrate harm
Remember when a group of plaintiffs decided to sue Apple, alleging that the company was allowing free apps from the App Store to gather geographical location information without their consent? Well, Bloomberg reports that Apple was in US District Court in California on Wednesday, asking Judge Lucy Koh to deny a request from plaintiffs' counsel to have the case turned into a class-action suit. Apple says that the plaintiffs haven't proven that any tracking that did take place actually resulted in harm to them. The lawyers for the plaintiffs have also dropped their claims to damages, which Apple views as proof that they're only trying for class-action status in order to recover legal fees. The lawsuit revolved around the ability of apps to have access to an iOS device's unique device identifier (UDID), allowing ad agencies to capture usage data across apps. Apple now restricts UDID access by app and is actually rejecting some apps that still use the code. [via Apple Insider]
Apple rejecting iOS apps for "cookie tracking"
Apple is moving developers towards adopting the company's own iOS 6 tracking technology and not their homegrown methods. One of these alternative techniques is cookie tracking and, according to a report in TechCrunch, Apple may be rejecting apps that use this method. To understand how we got to the point where Apple is rejecting apps that use tracking cookies, we need to take a step back to iOS 5 and earlier. In previous versions of iOS, developers used a device's UDID to track users. The UDID is a 40-character unique identifier assigned to each iOS device that developers used to track game progress, check subscription status and monitor ads. Apple phased out UDID tracking in iOS 5 and added support in iOS 6 for its own tracking methods, advertisingID and identifierForVendor. Some apps are circumventing these approved APIs by using tracking cookies that work on mobile devices almost like they do on the desktop. Craig Palli, VP of Business Development at mobile app marketing firm Fiksu, explained to TechCrunch that, "Within local storage, an app developer can drop a token -- an ID, if you will -- and then retrieve it later. In this regard, it works like a cookie, so the industry frequently uses it and talks about it like it's a cookie." Palli claims the number of apps being rejected for using this tracking method has increased over the past few weeks. He hypothesizes that Apple is gently nudging developers towards its own tracking technology. You can read more about this form of tracking and Apple's app rejection in the TechCrunch article.
David Schuetz cracked the case of stolen iPhone UDIDs
Earlier this week, Blue Toad publishing confirmed that it, and not the FBI, was the source of 1 million UDIDs leaked by hacker group AntiSec. The company was tipped off by mobile security expert David Schuetz of Intrepidus Group, who spent days poring through the data and discovered references to Blue Toad and its employees. It's an impressive piece of work by Scheutz, who details how he discovered the Blue Toad link in a lengthy blog post on Intrepidus Group's website. His story is well worth the read when you have a few minutes to spare. [Via Apple 2.0]
Blue Toad publishing claims itself as source of leaked UDID database
According to a report in NBC news, a small publishing company is the source of Apple UDIDs leaked by hacker group AntiSec. AntiSec and Anonymous claimed the UDIDs were stolen from an FBI employee's laptop, but the governmental agency denied that it was the source the leak. Paul DeHart, CEO of Blue Toad publishing company, told NBC News that his company compared the leaked Anonymous database with its own database and found a 98 percent correlation between the two datasets. DeHart did not provide details, but said forensic analysis by his company showed the data a had been stolen within the past two weeks.
Apple denies giving FBI any iOS device UDIDs, raises questions over AntiSec claims
Hacking group AntiSec (connected to Anonymous and LulzSec) made some bold claims Tuesday that it had obtained the unique device identifiers (UDIDs) of 12 million iOS devices from an FBI laptop, setting more than a few people on edge. The FBI has already denied that anything was stolen, but Apple has gone one step further to argue that it had no involvement. Spokeswoman Natalie Kerris tells AllThingsD that Apple hasn't given UDIDs to the FBI "or any organization" -- suggesting that either AntiSec or the FBI isn't telling the whole story of what data emerged and where. Even if there are real UDIDs floating around, Kerris adds that they don't necessarily pose much danger. She notes that programming hooks in iOS 6 will provide an alternative to UDID for device-specific data, and that apps will eventually be forbidden from using the older identifiers altogether. While the truth in the situation is hard to pin down, the technical reality doesn't leave much risk that our iPads and iPhones will be compromised. At least, not after this month.
FBI and Apple separately deny being source of leaked iPhone UDIDs
Yesterday, hacker group AntiSec released 1 million UDIDs from a pool of 12 million that it allegedly obtained from an FBI-issued laptop. The group used this high-profile leak to accuse the FBI of spying on the American public. Late on Tuesday, the FBI responded to AllThingsD with its own statement that says it was not the source of the leak. The FBI is aware of published reports alleging that an FBI laptop was compromised and private data regarding Apple UDIDs was exposed. At this time there is no evidence indicating that an FBI laptop was compromised or that the FBI either sought or obtained this data. The FBI re-iterated this statement on its Twitter account with a strong denial that says, "We never had [the] info in question. Bottom Line: TOTALLY FALSE." Apple also chimed in and said it did not give the UDIDs to the FBI or anyone else. Apple spokesperson Natalie Kerri told AllThingsD that, "The FBI has not requested this information from Apple, nor have we provided it to the FBI or any organization. Additionally, with iOS 6 we introduced a new set of APIs meant to replace the use of the UDID and will soon be banning the use of UDID."
Daily Update for September 4, 2012
It's the TUAW Daily Update, your source for Apple news in a convenient audio format. You'll get all the top Apple stories of the day in three to five minutes for a quick review of what's happening in the Apple world. You can listen to today's Apple stories by clicking the inline player (requires Flash) or the non-Flash link below. To subscribe to the podcast for daily listening through iTunes, click here. No Flash? Click here to listen. Subscribe via RSS
Hackers reportedly leak 1M iOS UDIDs (updated)
Update: The New York Times reports that F.B.I has released a statement saying there's no indication that an FBI laptop was compromised or that the FBI sought out the data to begin with. Hacker group AntiSec claims to have 12 million iPhone and iPad UDIDs it obtained during an attack on an FBI agent's compromised notebook, according to a report in The Next Web. It made 1 million of the stolen UDIDs publicly available in a file posted on Pastebin. The UDID is a unique 40-digit code assigned to each iOS device and is often used by developers to distribute beta apps to an iOS device. Besides the UDID, some records in the FBI database also contained names, addresses, mobile phone numbers and other identifying information. The group stripped out most of the personal information from the 1 million leaked records, but left the Apple Device ID, Apple Push Notification Service DevToken, Device Name and Device Type, so users can search for their device. You can find the UDID of your iOS device using these directions and then search for your UDID in the leaked records using this tool at The Next Web. [Via AppleInsider]
Apple cracks down on site selling iOS 6 betas
MacStories has a follow-up to a Wired report that details the practice of selling access to Apple beta software. The Wired article profiles several websites that'll add your UDID to a developer account so you can download and activate iOS betas on your device. Each site charges a small fee, usually under US$10, for this service. According to the MacStories report, Apple responded to this Wired report by sending DMCA notices to these sites and their hosting providers. As a result, sites like activatemyios.com and iosudidregistrations.com are being shut down one by one. You can read more about this take down, including the response of one website owner, in the MacStories article. As of the writing of this post, there is no indication that Apple is targeting users who have purchased an activation.
Apple alternative to UDID may come soon, track app use without pesky privacy issues
Apple has already provided a few clues as to what it's going to put on the plate for developers at WWDC. One change that's unlikely to be touted at the keynote, or even the entire conference, could prove to be the most important for app writers: an alternative to the UDID (Unique Device Identifier) that Apple started phasing out a year ago. If Wall Street Journal tipsters are right, the hardware-specific ID will be replaced with tagging independent of any one iPad or iPhone, such as a number sequence. The system as it's teased would let developers track user behavior and improve their apps without spooking users worried that Apple, or someone else, might snoop over their shoulders by linking a UDID to the owner. It sure sounds like a remedy to mounting privacy concerns to us, although an unveiling supposedly due within the "coming weeks" raises the possibility that the new ID won't show its face until after the programming hordes have already left San Francisco.
On the UDID ban: Tracking devices, users and advertisers
Over the past few weeks, several ad networks have announced "UDID-independent" conversion tracking tools. As Apple's UDID ban has gone into effect, mobile advertising has had to find other ways to track device users. The problem with this is, of course, that they're still tracking. Apple's SDK supports lots of ways to retrieve hardware data that's not limited to UDID, and it's easy enough to re-build the same UDID that Apple's APIs no longer support. What's uncomfortable about this transition away from UDID tracking to other forms of user identification is how hard these firms are scrambling to keep tracking users. In a nutshell, companies want to track because it's of value to advertisers, not because it's of value to users. iPhone owners are giving up some of their privacy, and for what? The ad companies are not creating coherent user experiences (UX) across time and device; they're just targeting ads. Ad networks might reply that a clear audience demographic allows for more effective (and profitable) advertising on mobile, which in turn supports a more diverse and dynamic population of ad-supported free apps. Certainly the App Store's free lineup reflects a degree of ad-driven revenue that would be missed if it evaporated. Of course, TUAW is an ad-supported site. We have to personally acknowledge the role of tracking cookies and other advertising technologies in supporting what we do. Mobile, however, feels different. It's more personal, it's location-aware, and it's less transparent to the end user. What we're not seeing is transparency and explicit opt-outs. On-device tracking is done completely silently in applications. You can't open up a device's "cookies" to see who is tracking you, and what information is being shared. That's fundamentally different from the desktop browser experience. It's a bit surprising we haven't seen a user-facing control panel for this. Whether provided device-side or as a webpage you can visit from your device, apps and advertising networks aren't allowing users to willingly opt-out from (or, even better, choose to opt-in to) this tracking. As one developer shared with TUAW, "[O]ne of the differences about website tracking is that you're actively requesting something from an external entity. If I walk into the grocery store and the guy behind the counter remembers me, there's no surprise. App tracking is often more like if I pull my milk out of the fridge to pour a bowl of cereal and the fridge autonomously contacts the grocery store to tell them what kind of cereal I'm eating." Often app developers say they track only to provide a more coherent launch-to-launch experience. But Apple has long since addressed the UX question of hardware tracking. iCloud allows apps to help customers build that coherent experience. You can lay down one device and pick up whatever you were doing on another. Not all applications support this integration yet, but the tech is there and working. Applications can coordinate bookmarks, data, game progress, and more. That's not what these ad networks are doing and it's not what a lot of devs are doing either. They're tracking customers for marketing purposes. All these tools we're seeing, and all these press releases, are essentially an end-run around Apple's attempts to guard consumer privacy. It's treating paying customers as the "other side" in an adversarial relationship, as if they were nothing more than commodities -- and, as far as ad networks are concerned, users are the product. Unfortunately, Apple has yet to come out with a clear statement of expectations even as it has tweaked its own ad solution to be more appealing to buyers. We have yet to see developers form a coalition saying, "Here is our pledge of professional conduct." Over the years, Apple has demonstrated how to profit by putting the customer first. Maybe it's time for the iOS developer community to do the same.
Confirmation of Apple rejecting an app for accessing UDID
Paul Haddad of Tapbots confirmed that Apple is rejecting apps which send out UDIDs. The developer posted a rejection notice for version 2.2 of its popular twitter client Tweetbot. The notice says that Tweetbot was rejected because the "app does not obtain user consent before collecting their personal data" and points to the UDID as the culprit. Tapbots says it was using the UDID for its push notification service and has disabled the code in the most recent version of Tweetbot that it submitted to the iOS App Store. Haddad advised other developers who rely on the UDID, "If you are an app developer and depend on UDID for any functionality it's time to migrate away from it, sooner or later Apple will catch you."
DevJuice: Apple begins unique identifier crackdown
The Verge writes that Apple has apparently begun to crack down on apps submitted using the now deprecated UDID (unique device identifier) APIs that allow developers to track individual devices. The programmer interface used to return an alphanumeric string unique to each deployed device. It was built out of a hash of the unit's serial number and other internal details. Apps that use the uniqueIdentifier API will automatically be rejected as this policy rolls out to its full complement of review teams. Instead, developers are directed to create unique identifiers specific to applications. Those identifiers can then be stored securely in the device keychain and retrieved regardless of application uninstalls/reinstalls. Although some developers have turned to using other approaches to track devices (for example, using the unit's MAC address), it's clear that Apple does not approve of any device-specific user tracking. For now, in-store apps that use UDIDs do not seem in danger of being yanked. The policy seems to apply to all new and updated apps, however. This may be the knell of doom for my Ad Hoc Helper app. Not sure where I'm going to go with that. If you have suggestions, drop a note or leave a comment.
iMessages reportedly still sent to stolen iPhones (Updated)
Update: Daring Fireball pointed to this recommendation from Jesse Hollington: set a SIM PIN code, which will prevent your phone from registering with the cellular network after a reset or a SIM swap until/unless the PIN is entered. Be extremely careful, however, as the iPhone settings UI can be confusing and you may get locked out if the phone thinks you're entering an existing PIN incorrectly. Macworld now recommends a three-step deactivation process, including calling your carrier to make sure your phone SIM is turned off. Update 2: Our colleague Michael Jones reports that there are situations where the 'stickiness' of location services can work in your favor: "My wife's iPhone 3GS was stolen in mid-September. By the time the iPhone 4S was released, there had been no sign of the 3GS and so we went ahead and replaced the phone, figuring that there would be no way to locate the old phone once it was deactivated. A couple of days before Thanksgiving, however, I received an email from Find My iPhone that the 3GS had been located, and briefly reported its location at a grocery store that does not have any open Wi-Fi networks in the area. A few days later, I received another alert as the thief had again turned the phone on at a different location, and the police were able to recover the phone." A troubling issue with iMessages being sent to stolen iPhones has been reported by Ars Technica. According to the article, the issue was brought up by Ars reader David Hovis whose wife's iPhone was recently stolen. She replaced her phone, changed her Apple ID password and moved on. While she was enjoying her new iPhone, the stolen handset was sold to an unsuspecting third-party who was using the phone on their wireless account. Incredibly, the stolen phone, which she deactivated with her carrier and remote wiped, was still sending and receiving iMessages on her behalf. She is only one example. If you search MacRumors or Apple's support forum, you will find several more examples. Part of the problem may reside with Apple's authentication system for iMessage. According to a thread at Ask Different, Apple stores the device ID (UDID) and the Apple ID or mobile number for each device that uses iMessage. An iMessage is apparently sent to Apple's servers, which look at the destination email address or phone number of an incoming message. The server looks in its database for the UDID that's associated with the recipient's phone number or Apple ID. The server then uses this information to redirect the message to the correct phone. It's possible, in the case above, that the UDID of a stolen phone remains in Apple's database and is not replaced by the UDID of the new phone. A message sent to the phone number of the person whose phone was stolen would go to the UDID of the stolen phone and not the new phone. The owner of the stolen phone can then respond back. I've experienced a similar issue with FaceTime on the iPhone 4. I activated my phone and setup FaceTime on one phone number and then switched it to another phone number about a month later. The UDID remained attached to the original phone number and was not automatically updated by Apple. When I tried to make a FaceTime call, the recipient would see my old number. If they tried to FaceTime me with my new number, it wouldn't work. People could only contact me by FaceTime calling my old number. I was able to force Apple to update my UDID in its system by resetting my phone using iTunes according to Apple's instructions. The iMessage issue appears to be similar to the FaceTime issue noted above, but it's not identical. While FaceTime can be corrected by erasing your phone, the iMessages issue is not corrected by a similar remote wipe procedure. I'm not sure why a remote wipe wouldn't fix the iMessage issue; maybe there's a difference between a remote wipe and an iTunes reset or Apple's servers are configured slightly different for the two services. Regardless, the iMessage issue is a serious one that Apple hopefully will address.
Dev Juice: Help me generate unique identifiers
Dear Dev Juice, Can you help me generate a unique identifier for my iOS apps? I don't want to rely on using UDIDs anymore. I'd say why but then you'd have to shoot me. Watm-ever Dear Watm-ever That sounds dire. Let's avoid the violence and focus on the Core Foundation. Here you go. If you're not using ARC, then you'll need to autorelease uuidString rather than bridging. You'll probably want to store your new ids into the keychain to allow them to persist. Happy developing. Update: Readers ask if this approach will persist between application reinstalls. Yes, as I originally posted, it will if you use the keychain. It will not persist with system re-installs if the keychain is wiped and not restored from a backup. Can you use the MAC address, yes -- but it looks as if Apple wants you to stay away from device-specific information.
iOS 5 deprecates UDID as identifier for developers, but it's not the end of the world
Reading the headlines today, you'll see the usual exaggeration of half-understood factoids bubble out from today's iOS 5 beta 6 release. Thank goodness for that NDA, huh? As reported by our sister site TechCrunch, Apple is deprecating the use of UDIDs as unique identifiers for developers, thereby severing one of the most common ties between physical devices and the apps that need to know which specific iOS gadget they're on. It's the end of the world as we know it! Well, no, actually. Let's get to the real story here, brought to you by feedback from some iOS developers with real-world knowledge of what the implications of this change will be. First off, let's clear up what it means for Apple to 'deprecate' this identifier. A deprecated function or software component is not yanked out immediately; it's simply been flagged by the developer of the platform (or app, command line tool, what have you) as something that will be going away in the future, eventually. While the feature remains in place for the sake of backwards compatibility, deprecation is a clear sign to all the programmers in town that they will have to move away from using this feature in the long run. To the average person, this deprecation of developer access to UDIDs means little more than one step towards better privacy. UDIDs are far from the only way a developer could ensure "your" iPhone is, in fact, your iPhone. Using the identifier has always been a relatively easy way for developers to do this, however, and so many used it, some abused it, and the average user was never the wiser. From the beginning, Apple has always uniquely identified its devices via UDIDs or other means, and the iPhone is no exception. There is a class called "UIDdevice" which describes the things on the iPhone, i.e., the features unique to that device. Until today, developers could have access to a users' UDIDs, and they've used them as identifiers for a lot of gaming, user info persistence and subscription systems (including some of our favorite apps). The downside of UDIDs in the past is because they're related to devices and not accounts, sometimes it's hard to have the device identifiers talk to each other. Some developers have grabbed or scraped these without user permission for marketing and other less than reputable purposes -- hence the privacy concern behind broadcasting UDIDs to third-party developers. The utility of developers having access to the UDID is far lower than the potential for abusing it. The UIdevice class does things like telling you the battery state, system name, OS version, phone model, and so forth -- it identifies the device and the features on it. It's been helpful in terms of letting developers determine which devices run certain features better -- knowing the difference in performance between an iPhone 3G and an iPhone 4 is certainly important, especially to game developers -- but other than that, there's not much utility there. So why isn't losing access to the UDID a big deal, at all? Any developer can always roll their own unique identifier. Apple provides a way to randomly generate one, so you never really had to use the UDID. People have been using UDIDs for various reasons -- not all of them good -- and there's not a lot of positives to UDID use other than ad-hoc app distribution (i.e., for beta testing). Apple's deprecation of UDID access is something that's been expected for some time. MacStories' take on it aligns with our own; privacy concerns over UDID sharing have been in the news for a long time, so it's not a shocker that Apple's now contemplating denying third-party access to them. From a user's perspective, this is a Good Thing. From a scrupulous developer's position, this may complicate your life for a while, but that's all. Unscrupulous developers who've been abusing UDIDs for marketing or other purposes are the ones that will get hit hardest by this change, but as far as I'm concerned, they can wither up and die with no tears shed. Some have speculated that iCloud account information might be substituted for UDIDs, but developers don't really have access to user account information from iCloud -- and they shouldn't. That would be an even bigger security hole than UDIDs. Apple seems to be taking a "none of your business" approach to user IDs where developers are concerned. We speculate that's the motivation behind removing the UDID API. Meanwhile, try not to buy into widespread reports of dogs and cats living together/mass hysteria, because it's just not that big of a deal in the long run.
