guardianproject.info Open in urlscan Pro
162.247.75.177  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Toggle navigation Guardian Project
 * about
   Blog podcast Partners and Funding Press Services Signing Keys Team
 * apps
   Checkey: info on local apps Círculo Haven Location Privacy - BETA ObscuraCam:
   The Privacy Camera Orbot: Proxy with Tor Orfox PixelKnot: Hidden Messages
   ProofMode: Verified Witnessing Ripple: respond when panicking Save Tor
   Browser for Android Tor Browser for Android (Alpha) TorServices (alpha)
 * code
   CacheWord: Passphrase Caching and Management Clean Insights: Privacy
   Preserving Measurement IOCipher: Virtual Encrypted Disks NetCipher: Secured
   Networking PanicKit: system-wide panic responses SQLCipher: Encrypted
   Database TorService: Tor library for Android TrustedIntents: flexible trusted
   interactions between Android apps Wind: Off-Grid Services for Everyday People
   libsqlfs: filesystem on top of SQLite/SQLCipher
 * archive
   Archived Apps CameraV: Secure Verifiable Photo & Video Camera Courier: Secure
   News reader Developer Square FFMPEG: Media Privacy Framework Firefox Mobile:
   Privacy Enhanced Freebird Workshop GnuPG: OpenPGP Encryption Hardware Guide
   InformaCam: Verified Mobile Media KeySync: Syncing Trusted Identities LUKS:
   Disk Encryption Lil' Debi: Mobile Debian Installer OnionKit for Android
   Orbot: Tor for Android Orfox: A Tor Browser for Android Orweb: Private Web
   Browser Ostel: Encrypted Phone Calls Pixelknot: Hidden Messages Tutorials
   Weather Repo
 * contact
   Contact How You Can Work With Us Jobs and Internships Live Chatrooms Toot
   @guardianproject@librem.one Tweet @guardianproject
 * 




PANICKIT: MAKING YOUR WHOLE PHONE RESPOND TO A PANIC BUTTON

--------------------------------------------------------------------------------

 Posted on January 12, 2016  |  Hans-Christoph Steiner

Our mobile devices do so many things for us, making it easy to communicate with
people in all manners while giving us access to all sorts of information
wherever we are. But in times of anxiety and panic, it is difficult to quickly
use them. Will you be too shaky to type in your PIN or lock pattern? Will you
have enough time to find your trusted contacts and send them a message? On top
of that, our mobile devices carry massive amounts of private information in
them: banking details, pictures, all of our messages and call logs.

The kinds of data that we worry about vary widely based on where we are. In many
places in the world, the stuff you are reading or the music you are listening to
can get you arrested, or the people you are communicating with is enough to send
you to jail. We have been adding “panic buttons” to our apps for 5 years now,
and now we want to create an ecosystem of apps to create flexible and
system-wide responses when we are unfortunate enough to require pressing the
personal panic button.

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.

Over the past year, we have developed user experience design patterns, an
Android library, a new panic button app, and example projects to communicate how
a system-wide panic should look. For a quick introduction, check out this video
demonstrating a very simple panic setup of Ripple, a panic button, triggering
Orweb, a private browser:


MAKE YOUR APP RESPOND IN TIMES OF PANIC

The ultimate goal of PanicKit is of course to make apps respond with actions
that help protect the user. This can be as simple as locking the app when it has
a passphrase, or the response can combine a number of actions into a coherent
response: a messaging app locks its data and disguises itself as a game while
sending out the panic message that includes the user’s location. There is a lot
of complexity in all this, especially with many apps involved, so it is
essential to always simplify the experience as much as possible. Thinking about
panic situations is stressful, setting up the panic response should not add to
that stress. Towards that end, it is better to sacrifice some flexibility if
that means solid gains in simplicity.

The first key design pattern is the default, non-destructive response. If all
apps that support PanicKit include sensible defaults, then pressing the panic
button can have a useful response without the user having to setup anything at
all. In order to achieve this, we divide possible responses into two categories:
non-destructive vs destructive. An app that has a PIN lock can be locked without
destroying anything, the user just needs to unlock it. A browser that wipes the
cache can always just download the files again next time the user goes to that
website. If an app only has a default, non-destructive response, then there is
no need to have a configuration interface; it can be represented purely in the
trigger app’s list of responders, where it will be marked “App hides when
triggered”.



Many of the most valuable panic responses require doing something that can not
be undone, so we classify these as destructive. Deleting data is exactly what is
needed in a panic situation, but the user must opt-in to enable this kind of
response in order to prevent data from being mistakenly deleted. Sending a
message can also be a very valuable panic response. But sending a message to the
wrong person can cause harm, sending it at the wrong time can destroy people’s
expectations: if you cry wolf too often, then people will stop hearing it.
Disguising an app can also save people a lot of trouble. But if the user does
not know this is going to happen, their experience will be that the app was
deleted. So these are all destructive responses and require the user to enable
them via a panic setup screen.

For apps that offer configurable responses, it is essential to present those
options clearly with as little clutter as possible. The panic setup should be on
a devoted screen, not mixed in with other settings, and takes up the full
screen. Panic is a time of stress, the panic response should strive to avoid
adding any stress on top of that. When an app offers a few options for
responses, then even the devoted screen can quickly get complicated: a list of
possibilities, a text field for a message, and a way to manage the contacts to
send to. It is important that the entire response is easily visible in one
screen so that the user can quickly and easily tell how that app will respond.
The entire panic setup should be on a single screen with as little scrolling as
possible. Large widgets like a message text field should be placed at the
bottom, and be collapsed if not active.

To get started, add the PanicKit library to your build.gradle:
info.guardianproject.panic:panic:0.5, then check out the FakePanicResponder
example app, as well as how it is implemented in real apps:

 * SMSSecure lock as default response
 * NewPipe clear search history as default response
 * Zom with multiple destructive responses and a default lock response


MAKE YOUR OWN PANIC BUTTON APP

One key reason why we took on this project is to spur more innovation in what a
“panic button” can look like. There are currently two solid panic trigger apps
that use PanicKit: PanicButton and Ripple.

There are many ideas for what a panic button can look like, now it is easy to
make one that will actually trigger real things. A custom panic button app only
needs to send the trigger message (technically an ACTION_TRIGGER Intent), which
will make apps lock, hide, delete private data, send a message, etc. Here are
some ideas for panic button apps that we would love to see:

 * a “dead man’s switch” that triggers if the user has not checked in within the
   last hour
 * a “geo-fence” that triggers if the device comes too close to a known
   detention center
 * a sensor monitor that triggers on absence of movement
 * a custom Bluetooth button that looks like a belt buckle, brooch, or other
   innocuous object



An important part of the user experience of the panic button app is how it
represents what the trigger will do. For that, we paid careful attention to the
design of the list of “panic responder” apps. It should quickly and clearly show
which apps are enabled. In our pattern, enabled apps should be sorted to the top
of the list and disabled apps should be greyed out including the app icon. There
should also be a standard switch to both allow the user to enable/disable an app
as well as provide extra feedback on whether an app is enabled or not. That
provides three visual channels that communicate what will respond (top of the
list, in full color, and with the shape of a switch that is turned on). For a
thorough overview of design patterns, see Panic Design Patterns.

Panic responders can have both non-destructive and destructive responses, and
some are only appropriate for a full on panic. If you are just feeling anxious,
and are worried that the situation is getting dangerous, then deleting files is
not appropriate but locking and hiding is. An app could instead be an “anxious
trigger” app, and be limited to only non-destructive responses. A trigger app
can only send one kind of trigger message (the ACTION_TRIGGER Intent), to keep
the inter-app interaction simple. So the anxious trigger app would instead not
offer the “EDIT” option (implemented with an ACTION_CONNECT Intent), and that
limits the responses to the default, non-destructive responses in all the apps
that receive a trigger from the anxious trigger app.

To get started, add the panickit library to your build.gradle
info.guardianproject.panic:panic:0.5, then check out the PanicTrigger class. You
can see how it is implemented in these example apps:

 * Ripple – a real panic button that is simple enough to be an example
 * FakePanicButton – a fake app that is only meant to be an example


MORE WORK AND OPEN QUESTIONS

There is a lot of potential for making our mobile devices help us in anxious and
panicked moments. PanicKit has established that a system-wide panic response can
be simple, approachable, and effective. But there is definitely much work to be
done. There is an organization forming around this work, The Panic Initiative,
that will build upon the work done by Amnesty International, iilab, and our
PanicKit work.

There are of course still many open questions that we are very interested in,
and hope to see more people working on this:

 * Should this be handled on the system level?
 * How the trigger app query the responder for its action without leaking
   private data like contacts or location?
 * How can panic and anxiety be represented graphically, using colors,
   iconography, UI, etc.?

For more discussion and resources, check out the PanicKit wiki.

android  design pattern  panic  panic button  panicbutton  panickit  privacy 
prototype  ripple  security  usability 
 * ← Previous Post
 * Next Post →

 * 
 * 
 * 
 * 
 * 
 * 
 * 

 • © 2009 - 2022  •  Guardian Project

Edit on GitLab