Summary + Objectives¶
The primary objective of the Panic work is: To Increase the awareness, understanding and capability for “Panic” features (data wipe, emergency alert to contacts) to be included in mobile software that targets at-risk users
This work seeks to establish a new level of awareness, understanding and capability for providing specific mobile software features for users who are in a “panic” situations. We define “panic” as at risk of having their mobile device physically compromised or removed from their body, being physically detained themselves, or facing an immediate threat of violence, injury, kidnapping or death. This is not to say we are are building a global “911” system. We seek to explore how software that is explicitly designed for these situations, can provide some amount of assistance to the user, by either protecting their privacy, ensuring that sensitive data is hidden or unrecoverable, or that their support networks are notified of the panic event, and provided with the necessary information to take action.
Previous work on a “Panic Button for activists” that was funded by DRL under the SaferMobile program, sought to build a single, pan-device button that would trigger a comprehensive data wipe on a device for all sensitive data. The button app itself (“InTheClear”) worked as an independent app, that used various permissions to write over and delete data that it could access on the device, that disabled access to remote accounts, and then silently sent SMS location beacon messages in an invisible process. The app, available on Java/feature phones, Blackberry and Android, did its best to provide support for panic situations, and represents a significant and valuable body of work (and source code) upon which to build and study.
The downside of a centralized panic app, is that since the applications generated and storing the data were not themselves designed with “panic” in mind, the concept of hiding, wiping and beaconing were not native to the apps themselves. Since most apps did not store their data in an encrypted format to begin with, it was not possible to completely wipe their data from flash memory in a forensically strong manner. In many cases, the user did not want to permanently wipe data, but only hide it, or an entire app, temporarily from casual inspection.
There was also the slightly humorous, but critical issue, of a user not being able to test a full panic wipe without actually wiping their data. The ability to walk a user through a simulated wipe, showing them what data will be protected, how long it can take, and how the capability will hide them, was a critical step that was missed in the InTheClear implementation.
Ultimately, we feel that their should not just be one “panic button” app, but that every app should include panic as a feature, just as a password or pin lock is a feature, or deleting a message is a feature. The ability to quickly put an application into a safe or locked state that defends the user’s data from unjust intrusion or extraction is a critical new concept for software design for people in high risk situations. In addition, for communication applications, they should include the ability to trigger an emergency distress beacon, utilizing the secured network conduits that app itself provides, and safely allow other authorized apps to trigger that feature as needed.
This document lays out the work, deliverables and costs associated with T2 - Panic. Overall, T2 - Panic will be a 15 month project divided into 6 quarters running from August 2014 to November 2015. At a high level, the project involves research, analysis, prototyping, development, implementation and outreach. Details will be outlined below in Timelines and Milestones.