PanicLib - Proposal¶

The Guardian Project has implemented features related to "panic" or emergency states in a few apps including In the Clear, InformaCam and Courier. There have also been initial concepts and prototypes led by a team at Amnesty International, and a variety of commercial implementations, as well. The output and outcomes of these previous efforts will inform and underly our new round of work. The primary difference being that the scope of the Panic Feature is more focused, targeted at app developers, and aiming beyond implementing just a single application.

In addition to these software efforts, there are a number of commercial hardware capabilities that will be investigated, as components of panic solutions. The first is related to the use of GPS not as a single location tracking mechanism, but through the concept of GeoFencing - the definition of geographic boundaries, that can trick different events to occur on a smartphone. This would enable specific safe or panic zones to be defined, and to have different panic features activated based on moving in and out of these zones. Another new possibility, is the use of paired low-cost wearable hardware, such as a FitBit or NFC tag, that can be used to activate a panic mode, if the smartphone is separated from the wearable hardware. These new concepts specifically address the ability to passively activate panic features, instead of having the user required to be in control of their device.

Foundation Components¶

• InTheClear: existing open-source project with code available for Android, Blackberry and Java phones; supports third-party data app wiping, external storage overwrite/shred and SMS location beaconing

• BigBuffalo Project: secure news reader (“Paik” or Courier) first public implementation of in app panic feature. A simple action bar “warning” icon displays a wipe screen, which the user triggers by swiping their finger down across the entire screen.

• GeoFencing APIs: New features of mobile operating systems, allow for predefined location boundaries to trigger specific capabilities in applications

• NFC Tags and Bluetooth Wearables: The commercial market is full of wearable technology focused on fitness tracking and ambient self quantification. Some of these devices can be used to trigger panic features.

User Stories¶

Choeying has been traveling in Tibet, secretly interviewing families of self immolators, to create a documentary about what is happening. She is using her smartphone as a video camera, and is worried about being caught with all of the videos on her device.

Steve is a human rights researcher traveling to Tibet under the guise of a tourist trekker, in order to get first hand knowledge of the situation on the ground. The organization supporting him wants to keep track of his location, status and whereabouts, and be notified if there are any anomalies in his behavior or activities.

During unrest in a region, it is known that activists are being detained and taken to the local prison for interrogation and torture, or if they are injured, to the local military hospital. Tashi wants his friends and family to know if he ends up in either location, whether he is able to trigger an alert or not.

Timeline & Milestones¶

Quarter 1 (1JAN14)

Ongoing surveying, interviews and data gathering to form complete picture of “What is panic?”
User interface prototyping and
Analysis of existing code, projects and libraries

Quarter 2 (1APR14)
Development of patterns and libraries begins
First public release of pattern library and initial code

Quarter 3 (1JUL14)
Integration of initial panic feature concepts and code into secure messenger and other willing participant apps

Quarter 4 (1OCT14)
Prototyping of GeoFencing and wearable hardware panic triggers

Quarter 5 (1JAN15)
Second public release of pattern library and feature code and libraries.
Open developer, designer event on “App Panic” - mini-conference event/gathering both in person and online

Quarter 6 (1APR15)
Outreach to broader app community; developer support for implementation of Panic

Quarter 7 (1JUL15)

Ongoing community support of Panic Feature resources via mailing list, developer support site, chat, blogs and other social media

Quarter 8 (1OCT15)
Final evaluation, outreach to developers, output and outcome tracking

Outputs¶

• Comprehensive, published definition of panic scenarios, user stories, and design implementation guidelines - “What is ‘Panic’ and how should your app react?”

• Established software patterns and usability guidelines for implementing Panic features into applications, both mobile and desktop

• Mobile software libraries as reference implementation for panic feature support, including:

• Code for properly implementing secure storage that can be quickly and completely wiped (i.e. “throw away the key”)

• Code for overwriting common data store types with random, fake or masking data

• Library for background emergency beaconing, including data, sensor gathering, and built-in default send transports (SMS, Email); plug-in framework for sending via app-specific transports

• Reusable user interface components for panic feature configuration and triggering

• Example code for GeoFencing as panic trigger

• Example code for wearable hardware as panic trigger

• framework for panic listeners and panic senders, and a centralized mechanism for managing, authenticating and triggering

• Reference implementation that demonstrates all features and relevant patterns

• Showcased, released applications that incorporated panic feature libraries

Outcomes¶

• General awareness of Panic as a necessary and understandable feature to implement in software targeting high-risk users

• Panic implemented in this project’s secure messenger app

• 5 third-party apps with implemented or commitment to implement panic feature patterns and/or libraries

• 10-15 published patterns in public repository website of panic feature

Assumptions & Externalities¶

• Smartphones of activists and others in high-risk contexts continue to be targeted as a sign of guilt or a source of tracking data

• Mobile application developers are interested in protecting their users from being persecuted, and data from being used to unjustly incriminate (“do developers really care?”)