When the team at MotionMobs heard about the new Exposure Notification framework coming from Apple and Google, we knew that it was an opportunity to use our expertise to help manage and eliminate COVID-19.

As direct competitors in the mobile market, it’s not often that Apple and Google work together to combine the power of their platforms for a common benefit to their users. To make sure the technology worked properly for the majority of mobile devices on the market, both iOS and Android had to be supported AND had to work together.

There have been several other attempts at warning people about their potential exposure to the virus by other countries and technology leaders, but each of them had their issues, and none of them could get into the operating systems the same way that Apple and Google could.

The challenge

It’s exciting to be in the small group of developers being allowed to use this new technology. As we started working on the app with UAB, we all wanted to work to get the app built quickly and out to the public to start the process of detecting potential exposures. At the same time, building an app using brand new tools for the first time is always a challenge.

At first, there was not much documentation outside of a PDF documenting the planned classes and methods that the framework would use. As we were beginning work, the framework was still rapidly changing and we had to be flexible to those changes. Adapting to the changes large and small is part of the process for us as developers. As things stabilized prior to the release of the iOS update that included the framework, the documentation got much better.

Throughout the process, Apple has been a tremendous resource for support, and they have even provided an example app with code to reference and borrow from.

Open source problem solving

As we have prepared the Alabama app for launch, we’ve seen other apps launched or prepare for launch in other countries, including Italy, Latvia, and Germany. In some cases, the countries or development teams have made their code open source. By studying their code, we’ve found the answers to a few problems we’ve run into along the way, and seen a few different architectures for the app that we had not considered as we built the project.

Limited API access

In addition to learning about the details of the new framework, managing the various requirements Apple has put on developers has been an interesting process to deal with. For nearly all of iOS development, if a framework is available to developers, it is usable by all developers. With the Exposure Notification framework, though, there are several ways in which Apple is limiting access to this new API. Based on approval from Apple, Exposure Notification apps have been restricted to public health authorities, such as the Alabama Department of Public Health.

Walking through the process to be allowed to use this framework has been enlightening, as it has shown the ways that Apple can restrict certain features or frameworks.

Why the limitations?

There are several benefits to these limitations:

1. By limiting it to public health authorities, the app comes from an entity that has built up some level of trust with the users, and is a reliable manager of public health information. This also removes the possibility of the app to become a product of a corporation or brand.
2. If every city or county had to build their own app, the data would be too granular and sharing data across those boundaries would become incredibly complicated. The possibility of one app for each state is already daunting, let alone for smaller divisions than that.
3. Given the sensitive nature of the data used by these apps, fewer apps are easier to monitor and handle if an app tries to use data outside of the privacy-preserving intents of the framework.

User privacy

From the start, Apple and Google emphasized that this solution would be a privacy preserving method of exposure detection, which the MotionMobs team thought was incredibly important. There is the potential for a lot of personal information to be used or given away by less private techniques to solve this problem and we were excited to be able to avoid that while still being successful in the goal of alerting people who may have been exposed to the virus.

For users to feel comfortable sharing sensitive information about their test results or diagnoses, privacy is vital. The framework handles this in few important ways.

When communicating with other phones, the framework has no concept of who the other phone belongs to. The keys exchanged between devices are random and secure, and change every 10-20 minutes, so there is no way to know which phone generated a given key, even if one phone has been near the other before. The framework views that as just another new key to keep track of for use during the detection process. 

When running the detection process, the app downloads a list of keys submitted by users who have had a positive test result. These are slightly different keys than the phones exchange directly, in that they represent a set of keys for a given period (typically a day). The framework handles the secure correlation of the daily keys downloaded by the app to the keys that were exchanged via the Bluetooth interactions between devices, adding another layer of privacy to the data. These “daily” keys are meant to be unidentifiable, even if you had access to the keys that were exchanged over Bluetooth.

The framework is hard to exploit by anyone trying to cause a large number of false notifications, given the keys have been exchanged between two phones, and the detection process is run on the phone. If the attacker could submit a false report to the supporting database that distributes keys from users who have indicated they had a positive test, they would still have to make sure that the keys they are trying to use in their exploit had been delivered to your device via the framework. Any app that is approved to use this framework is also not allowed to use the GPS in the phone. This prevents location tracking both on the device and in the submissions to the database, and prevents any misuse of location data by any party.

With all of the above, the framework makes it easy for our app to do the job of protecting user privacy. The app doesn’t know who it has exchanged keys with, can’t identify who has submitted test results that it might match with for a possible exposure, and doesn’t know where it is or has been. There have been other techniques used to build exposure notification and contact tracing apps, but many of them rely on breaking some of the fundamental privacy protections described above in an effort to achieve their functionality. Apple and Google have found a balance of success in notifying users of possible exposure while maintaining privacy throughout the process, and have made it easy for us as developers to build the app and get these privacy-preserving features.

Releasing the app

The timeline has been quick, with lots of coordination between MotionMobs and UAB to build out the app and server components needed. Throughout it all, it has been great to get to work with and learn so much about this new framework, and contribute our app development experience to this important effort.

We’re preparing the app, GuideSafe, for release soon, after going through the design, development, review and approval processes for all of those involved. I’m excited to get this app out into the world where it can help people better protect themselves and those around them from COVID-19.

The app became available August 17, 2020 – download the app today on the App Store or Google Play and check out the official website.