Crashlytics Presents SecureUDID

by Jeff Seibert, Co-founder

 

 

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 SecureUDID.org.

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 jobs@crashlytics.com.