The story behind creating SecureUDID in 24 hoursPosted by Jeff Seibert on Mar 28, 2012 in Featured, SecureUDID, Technology
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.
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.
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.
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 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!