Application Concept: resqr
I have ideas. Lots of ideas. Some days, ideas flow out of me like…
Well, let’s just skip that analogy.
I have more ideas than I know what to do with. From time to time, I’ll toss an idea out, in case they inspire somebody or strike someone’s fancy. By definition, if I’m posting it just as an idea, I’m probably not planning on attacking it any time soon…but you never know.
Clay Shirky, in Here Comes Everybody, relates a tale of an Egyptian activist who was arrested, but managed to post news of his arrest on Twitter. This led other activists to protest the arrest and eventually led to his release.
This is not the only time this has occurred, and one can imagine that it will become more prevalent over time.
However, this has a potentially fatal flaw: it assumes that the person is able to use his or her phone. Eventually, phones will be confiscated (and probably crushed under a boot heel) immediately upon arrest. Even when that does not occur, it may not be practical for the person to use a phone (e.g., handcuffed).
While political protesters represent a high-profile scenario, there are other cases where somebody might be arrested or abducted and be unable to tweet for help. Social workers visiting rough areas of town routinely fear for their safety. Legal immigrants in areas beset by illegal immigrants may feel concerned that laws aimed at cracking down on illegal immigration may affect them as well. And so on.
One way to address this is to reverse the trigger. Rather than having to take positive action to alert people of a problem, let’s use an (unfortunately-named) “dead-man’s switch” instead. If you don’t — or, perhaps, can’t — take action after such-and-so period of time, we assume the worst and start letting people know.
This works well in cases where the potential victim either knows of specific periods of high risk (e.g., attending a pro-democracy rally) or is fairly constantly at high risk.
That’s what resqr
is about.
A resqr
user would set up a profile with a roster of contacts/services organized into an “alert tree”. Close confidants may be in the highest-priority group, on down to public sites like Twitter being at the bottom priority.
Then, the resqr
user would set up a “watch”, with a deadline and a pair of PINs. One PIN disarms the watch, the other proactively activates the watch (a “panic” value). Once armed, the watch would start notifying the groups in the alert tree in pre-determined sequence, if the watch is not disarmed by the deadline, or if the “panic” PIN is used.
To work in a wide range of environments, reqsr
would:
-
Need to use a server to do the actual watch countdown and alerting. If we assume an Android device, for example, was to handle it, it would fail in the face of a boot heel.
-
Need to have many possible servers to choose from, lest access to one master server be blockaded (see Pakistan and Facebook).
-
Make sure that the UI of the regular PIN and “panic” PIN are identical on the device, at least until all groups in the alert tree have been notified, or until the victim is able to use the regular PIN to disarm it. That will prevent anyone savvy in the ways of
resqr
from forcing the victim to disarm the watch.
I am sure there are plenty of other details that would need to be worked out. I’m envisioning an open source server component, with a Web front end for setup and various clients for PIN usage (Web, Android, SMS, etc.).
If you have any questions about resqr
or wish to brainstorm further on it, drop me a line (mmurphy {at} commonsware.com).