SecureUDID 1.1 has been pushed. You can see the latest code here.

Change log & version history

March 30, 2012 – 1.1

  • Greatly improved robustness to backing store corruption/correctness
  • Groundwork for Opt-Out application interface
  • Additional API for Opt-Out query and background identifier derivation
  • Support for unlimited number of installed SecureUDID applications
  • Renamed API to de-emphasize the notion of a salt
  • Improved detection of backup/restore

March 27, 2012 – 1.0

  • Per-Owner dictionary implementation to support Opt-Out functionality
  • Addressed an issue that could result in pasteboard overwriting

March 26, 2012 – 0.9

  • First public release

View More

Today saw the introduction of another UDID solution – this time, ODID by AppRedeem. We recently launched SecureUDID, our open-source solution that we’re using at Crashlytics, and we couldn’t be happier to see more innovation in this space.

Domain-Specific Is The Way to Go
We launched SecureUDID with the concept that device identifiers should be domain-specific and we strongly support solutions going in this direction. At the time of this writing, ODID wasn’t yet available for review.  In reading their announcement, however, we are pleased to hear that AppRedeem also agrees with our belief that any UDID system that yields a single, global per-device identifier is a fundamentally flawed solution.

MAC addresses are not reliable
While quite clever, ODID’s hashed-MAC address technique for generating IDs is concerning. Fundamentally, it’s predicated on the assumption that access to device MAC addresses is reliable and will continue to be permitted (and therefore continue to be available for abuse by others). We evaluated this while designing SecureUDID and we don’t believe this to be a safe assumption at this time. Additionally, on many devices, using MAC addresses will not work at all. For example, China Unicom iPhones shipped before August, 2010 do not have MAC addresses, rendering the technique useless on many devices. SecureUDID does not rely on MAC addresses.

We’re looking forward to working with AppRedeem and the larger community to establish a developer standard for uniquely identifying devices while respecting user privacy.

For more information about SecureUDID and to download and integrate it into your application, visit

View More

Yesterday, we announced the immediate availability of SecureUDID, an open-source project that strives to balance developers’ desires to uniquely identify mobile devices with end-users’ privacy expectations and rights. It was a whirlwind project for us and we wanted to shed some light on how it came together so quickly.

The Spark
I’d been out of town on Saturday and originally missed the news that Apple had begun summarily rejecting apps that access UDIDs. Once I saw it, though, I knew we had to act – while Crashlytics does not rely on UDIDs, it has a feature to collect them if our customers so-desire, so the offending call to [UIDevice currentDevice] uniqueIdentifier] is present in our SDK. I sent a quick note to the team on Sunday at 9am that we needed to have a response plan.

Back in town, I checked in with the team. My co-founder, Wayne, had seen my email and alerted one of our interns, Zach. Wayne wanted to make sure we were prepared and a blog post was ready, so Zach started drafting.

The Insight
Zach’s draft committed us to release a new version of our SDK without the now-offending UDID call on Monday. It was a pretty straightforward response, but caused us to start thinking more deeply about the issue.

While Crashlytics really didn’t depend on UDIDs at all, other companies like ad networks and analytics providers certainly did. And it would be nice to still offer our customers a way to uniquely identify devices – it can be extremely helpful when tracking down edge-case crashes. More discussion, and possibly a solution, was needed. I scheduled a 10am meeting with our iOS team and moved on to other urgent priorities.

The 10am meeting never happened since the team was in the office and plugged in by 8:45am. I had been up, thinking about the challenge since 6am and it sounded like the others had too. We really believed that we had to solve the privacy issue and not just replace the banned UDID with another mechanism like MAC addresses.

Evaluating OpenUDID
Back in October, one of our own, Sam, contributed to the OpenUDID project. At OpenUDID’s request, Crashlytics also agreed to appear in a list of companies that supported OpenUDID. Naturally, it made sense to evaluate whether we could modify OpenUDID to address the privacy issues we identified.

After an internal debate, we determined that modifying OpenUDID would fundamentally not work. OpenUDID is predicated on having a global identifier for the device — basically the same as the now-deprecated Apple UDID. We needed to remove that requirement to address the privacy issues, and making that modification would mean all the developers who used OpenUDID would suddenly get new, random, non-global ID’s. Developers wouldn’t be happy waking up one morning and finding out that the OpenUDIDs they relied on were now broken. We had to write the code from scratch.

One of our key insights was that we could still give 3rd party providers, like advertisers and analytics, the option to track devices across apps, without there being a single, global UDID! By allowing UDIDs within a domain to be accessed from any application, SecureUDID permits a 3rd party framework to reliably access the same UDID on the same device from any app it is installed in, while simultaneously preventing anyone else from accessing it (unless they shared their domain and salt combination). This means if you’re an analytics platform, you can use SecureUDID even if the individual app developer is using SecureUDID or OpenUDID as well.

With a public domain and salt, SecureUDID behaves identically to OpenUDID. With a private domain or salt, it is vastly more respecting of user privacy than any prior solution.

To be respectful, we wanted to make sure to reference OpenUDID on the website and whenever we talked to others about it. We also wanted to be developer friendly as well, so we made sure we were compatible with, and did not break, OpenUDID. (We’re happy to say we ended up doing both.)

Our First Crashathon
Next, we had to come up with a name. We quickly decided on SecureUDID. It seemed to convey the spirit of our project so we registered it immediately.

Once the approach was laid out, most of our team spent the rest of the day on Monday working on the project, designing the architecture and writing the code.

Our goal was a clean-room implementation, so we made no use of other code or projects that were out there. This process resulted in an end-product that had diverged from OpenUDID significantly:

  • Our salted-domain technique for establishing multiple SecureUDIDs per device
  • Our reliance on CFUUID rather than -globallyUniqueString to correctly generate IDs
  • Our avoidance of MD5, for obvious reasons.

12 hours later, at 8:29pm on Monday night, Matt, one of our iOS engineers (who also worked on Apple’s iOS team), wrote in our team chat: “BAM – looks like SecureUDID is currently working”. Awesome!

Concurrently, the website was designed and readied for implementation. Since this project had such a tight timeline, one of our web engineers, Joel, stayed hard at work throughout the evening and into the wee hours to make sure the design worked.

It was our first official Crashathon! We were in the office until roughly 1am Tuesday morning, putting the final touches on SecureUDID.

The Launch
The next day, we were fortunate enough to be covered by TechCrunch and BostInnovation, among others.

The feedback from the community has been positive and we’re thrilled to have contributed to solving this problem. Here are just two tweets from the community (Greg Raiz of Raizlabs and Drew Volpe of Locately).

We’re strong advocates of mobile development and will continue to do our best to make useful contributions to the community and ecosystem. I hope you’ll support us along the way! If you would like to be a contributor to the SecureUDID open source project, please feel free to fork the code and submit pull requests!

View More


One of our core values at Crashlytics is to be proactive. We’d rather fix problems we encounter than hack together workarounds or sit, roadblocked, waiting for others to address them.

This weekend, TechCrunch published an article regarding Apple’s recent rejections of applications that access Unique Device Identifiers (UDIDs), referencing a move Apple started making in the last six months to avoid privacy issues. However, they appear to be taking action much quicker than many expected. This has thrown the industry into chaos (and into a desperate search for a solution), as over 68% of applications use and transmit UDIDs.

What’s a UDID?

Apple gives each of its mobile devices a UDID in order to differentiate them. Each UDID consists of a unique series of 40 letters and numbers making it far harder to guess than a typical serial number. We like to think of it like a social security number for your iPhone.  Using this information, developers have been able to analyze and track specific devices in order to make their applications more efficient and personalized. For example, a company can use a UDID to track the number of downloads to a specific device, observe a user’s behavior across multiple applications, and many other use cases. This information has become essential for many developers, but its wide use continually sparks debates over privacy issues. A researcher demonstrated he could even connect UDIDs to Facebook profiles, for example.

From day one, Crashlytics has offered UDID collection as an optional feature. Many of our customers requested that we collect them so they could better respond to support requests, but our service has never depended on them.

Can’t we just use the MAC addresses?

We’re staunch advocates for user privacy (and have gone to extreme lengths to ensure that the data we collect is not personally identifiable), so we got concerned when other vendors started turning to device MAC addresses as their solutions. These suffer from exactly the same privacy concerns as UDIDs. Utilizing MAC addresses is a myopic solution; if such becomes prevalent, Apple will be forced to restrict access to them as well.

What about OpenUDID?

AppsFire unveiled OpenUDID back in September as one of the initial responses to Apple’s deprecation of UDIDs and our very own Sam Robbins was its second contributor. Since then, we’ve spent time outlining what would make a more secure UDID, and the changes required turned out to be significant. Establishing a single identifier per device, like OpenUDID, is fundamentally no different than a MAC address or Apple’s UDID – the privacy concerns are the same. We had no choice but to start from scratch and build SecureUDID with privacy in mind.

Announcing SecureUDID

Today, we are pleased to announce the immediate availability of SecureUDID, an open-source, MIT-licensed, alternative that addresses all major root causes for UDID privacy concerns without relying on any specific device-unique tokens. Specifically, SecureUDIDs have the following attributes:

  1. Developers can still differentiate between devices as if they were still using a UDID, but only within apps they control.
  2. User privacy is protected since developers are fundamentally prevented from accessing the same UDID as another developer. This greatly limits the scope of any potential leaks.
  3. End-users can globally opt-out of SecureUDID collection across all applications and services that use it.

For far more details, a technical breakdown of what we’ve built, and ways to get involved, check out

What’s next?

This is only a start – we couldn’t be more excited to work with the community to deliver a robust, peer-reviewed secure UDID implementation that balances user privacy with the developer desires to count and differentiate devices.

Interesting in working on these and other cutting-edge challenges? We’re hiring! Give us a shout at

View More