Emergency app functionality with PanicKit

The past few years have seen a flurry of development effort directed at building secure and anonymizing apps for smartphones; one can run Tor on an Android device and has a choice of multiple encrypted messaging solutions. But, until recently, there has been comparatively little work in making mobile devices react in emergency situations—to, say, lock down or wipe the device's storage clean of sensitive information or to sound an alarm that something untoward has happened to the user. Now the Guardian Project has proposed an open-source framework to make "panic button" features available in every Android app.

The Guardian Project is a non-commercial developer of mobile apps with an emphasis on security and privacy. It is perhaps best known for the Android Tor client Orbot and the encrypted messaging app ChatSecure. Those offerings are fairly straightforward fare for anyone wishing to keep their communications private, but some of the project's other work has offered additional features.

In 2012, it developed InTheClear, an Android app that would securely wipe the device's storage when it was activated. The Courier news-reader incorporates a similar emergency-erase feature. So too does the still-in-development CameraV app, which also has a built-in ability to disguise the app's launcher icon. Similar ideas are found elsewhere, such as in the Panic Button app developed by Amnesty International with the goal of providing human rights activists with a "panic button" to clear out their phones in the event that they were arrested or otherwise placed in harm's way.

Now the Guardian Project has developed an Android library that will allow any app to respond to "panic" situations—by locking the app, erasing its data, hiding the launcher icon, or any other appropriate action. Called PanicKit, the system works by having each compatible app accept an ACTION_TRIGGER Intent from a separate "panic button" app. Thus, the user can activate a single panic button and have every configured app respond automatically.

How an app responds to the panic trigger can vary, and could be non-destructive or destructive (or perhaps provide the user with several options). The Guardian Project's blog post recommends that non-destructive responses (such as erasing caches or locking apps) be the default, though it notes that more serious measures may be what the user wants:

The scheme thus enables any interested developer to add "panic button" support to an app, and it allows the user to choose from potentially a multitude of possible "panic button" apps. The Guardian Project has released one such app, Ripple, and PanicKit support has been added to Amnesty International's Panic Button app. In addition, the Guardian Project has released a non-functional demonstration app called FakePanicButton.

Both take essentially the same UI/UX approach: the user can trigger a panic signal by opening the app and tapping an on-screen button. But, as the blog post notes, there are other possible ways one could trigger a panic signal—a "geo-fence" trigger that sends the panic signal if the phone enters a dangerous area, detecting the proximity of a designated Bluetooth or NFC "button," or even a "dead man's switch" that issues the panic signal if the user does not check in regularly.

PanicKit response support is available now in Orweb, InTheClear, Courier, and several other Guardian project apps. In addition, several third-party apps have added PanicKit support or are in the process of doing so, such as the chat client Zom and the Lightning web browser. The responses implemented in these apps vary, from erasing browser history or deleting data to sending pre-defined messages to specific, trusted contacts.

The blog post points out in several places that "panic button" situations are, naturally, times when the user is under considerable stress. Consequently, the project is taking care to work out design patterns and best practices to help avoid mishaps. The Ripple app, for example, takes two steps to send out a panic signal, and provides a five-second window during which the user can easily cancel the operation.

If PanicKit becomes a popular feature, though, there is also the risk that it could become too complex for its own good. Right now, for instance, one can install both Ripple and Panic Button. Since each app on the device must register to accept an Intent, the user can configure some apps to respond to Ripple and others to respond to Panic Button. Throw in geo-fence triggers and dead man's switches, then multiply by configurable options for each panic-response app, and there quickly becomes a lot for the user to configure.

Consequently, the Guardian Project has formed the Panic Initiative as a collaboration space where interested developers can address open questions about system integration, usability, and the like. The PanicKit wiki documents the project's design work and implementation progress so far.

Perhaps most Android users will never have any occasion to need a panic button, and no doubt it is a feature no one looks forward to using. But if it proves popular, PanicKit could ease the minds of users simply by making responding to panic situations an issue that they can think about once in advance, rather than it the heat of the moment.