[guardian-dev] Fwd: What is "Panic" discussion

Hans-Christoph Steiner hans at guardianproject.info
Tue Mar 5 10:34:18 EST 2013


If we're going to take on this project again, I think we need to apply our
frameworks approach here, but maybe perhaps at a higher level than Java
frameworks.  As others  have pointed out, its not really possible to great a
good version of this app that covers all reasonably common uses for it, so we
should instead aim to making it really easy to create targeted versions of it,
things like:

* the Tahrir Square activist version
* the Syrian human rights documenter
* the US lawyer working in countries that might demand spot inspections of
devices,
  like at the border check
* human rights NGO worker

These would all have tailored UI, translations, and defaults.  It could be
shaped as a single app with configurable "profiles" or it could be a
collection of frameworks for each kind of task, like FDE-wipe, filling
contacts with random info, deleting online profiles, etc.  I currently lean
toward the second version since I think we could then easily incorporate some
of these features into other apps.  I could see a full wipe included in
StoryMaker or InformaCam, for example, but not so much in a panic way.

This would also mean that the branding/naming would also be targeted.  The
version that is all about a quick, easy to trigger wipe would be called Panic
Button, while another version that aims for thorough wiping under safe
conditions would called In The Clear.

.hc

On 03/05/2013 09:49 AM, David Oliver wrote:
> Abel thanks for this.
> 
> Folks, my worry is not so much the technology of what we're doing as a
> problem with terminology that "means different things to different people".
> 
> 
> He's my two cents, and even without it I think we need to come to grips
> with how to explain what we have:
> 
> PANIC, to me, means a rapid "fight or flight" type reaction to an immediate
> situation.  There is little time to think and discriminate between choices
> for possible actions - there is only an immediate need to remove the
> danger.
> 
> I understand the reasons a panic might occur relate to a user being in
> possession of a mobile device which one or more external parties - usually
> armed and of official capacity - believe contains "harmful" information.
>  In "panic mode" the user is being chased by those people.
> 
> From this perspective, I don't see "I think the police are on their way to
> my hotel room" as a "panic" situation.  I don't see "I am now headed home
> to the USA from country-with-ugly-regime, and am about to go through the
> security check where they may examine my phone" as a "panic" situation.
> 
> Therefore, I believe the "panic" situation we are trying to address must be
> addressed in a time-period of between 10 and 30 seconds.  What can out
> technologies do in 10-30 seconds?  My guess is they can do A LOT of a
> nature that would mitigate the probability that a first-responder would
> find the harmful information.  But we need to architect that way.
> 
>  Nate has said, and Abel as seconded, that there is true need exists for
> "deep cleansing".  But that sort of effort takes many minutes or even
> hours.  This problem is somewhat mitigated in SOME instances by the
> apparent fact that the authorities will sometimes delay any forensics on
> the device for minutes or hours.  All good!
> 
> So, I'd like to repeat my suggestion/request - and I'm doing so in the name
> of making the terminology consistant and unambiguous: We should architect
> the functions in such a way that "first looks" are mitigated immediately
> while progressively more-deep forensics are mitigated as more minutes are
> available.  This is a sound philosophy, as I see it, for all use-cases -
> because highly-knowledgeable users who know they need their device wiped
> with the highest degree of certainty know that such an activity takes time.
> 
> The people I am really worried about are those people who are quite
> innocent about what's possible in forensically inspecting a device who
> believe - because of the name we use - that their device is forensically
> secure in 10 seconds.
> 
> What can we do to implement this sort of thinking in our app (In The Clear)
> and in that software as a "function", which we need to import into other
> apps)?????
> 
> 
> Dave
> 
> 
> 
> 
> 
> David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
> http://<http://olivercoady.com>
> davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366
> 
> 
> On Tue, Mar 5, 2013 at 9:21 AM, Abel Luck <abel at guardianproject.info> wrote:
> 
>> Nathan of Guardian:
>>> (moving this discussion to guardian-dev)
>>>
>>> On 03/01/2013 03:18 AM, David Oliver wrote:
>>>>
>>>> Nate - is your experience radically different? That is, is "panic"
>>>> indeed defined as a timeframe which can be handled by the current
>>>> software - which appears to me to be roughly 2-30 MINUTES?
>>> I replied to this in the other thread message, but it is important to
>>> consider how these things usually play out, and by these things, I mean
>>> the imminent detention of someone carrying a smartphone full of
>>> sensitive data. In general, even if they only have a few moments to
>>> realize something is going to happen, there is still quite a while
>>> between that happening, and their smartphone being accessed or
>>> inspected. In some cases, even in some of the worst places you can
>>> imagine, I have first hand knowledge that people were allowed to keep
>>> their phones for quite a while before they were taken and inspected. I
>>> am talking *hours* hours before these devices were removed from their
>>> pockets and inspected. OTOH, in more local cases with NYPD arrests,
>>> phones are immediately taken, but unlikely to be
>>> clone/processed/extracted for a few hours.
>>>
>>> 2nd, I also want to make the point that if our target audience is using
>>> full-disk encryption of some sort (such as is built into Android 4.x),
>>> then the wipe process for this is quite fast technically, though the
>>> actual mechanism for doing this on an Android phone takes too many
>>> steps, and can often fail mid-process. For apps with SQLCipher or
>>> IOCipher in them, our hope is to optimize this process, and so the
>>> "insta-nuke" feature we have been designing into our new apps matter
>>> greatly here.
>>>
>>> 3rd, in our work on panic apps, with InTheClear, the feature of wipe was
>>> paired with the "emergency distress beacon" feature that uses ongoing
>>> background SMS alerts containing GPS and cellular tower location to
>>> notify your friends, family, support network that something has happened
>>> to you. This is a whole nother side of panic functionality, that doesn't
>>> really involve anything about forensically sound data-wiping.
>>>
>>
>> +1 to all this. "Panic button" is a term being thrown around that means
>> different things to different groups. For some it is forensically wiped
>> flash memory, for others it is a distress beacon, for yet others it is a
>> deadmans switch that deletes/locks their online presence (twitter,
>> facebook accounts etc).
>>
>> Some of these features are mutually exclusive.
>>
>> Example:
>>
>> On a FDEd phone, the fastest and most secure way to do a wipe, is to
>> overwrite the portion of disk where the LUKS key is stored [1] and do an
>> emergency poweroff. This takes seconds. But, once initiated, the phone
>> can no longer be a distress beacon.
>>
>> This is something I've stressed in my talks with others about a "Panic
>> Button". Different groups have different needs due to their different
>> threat models. I oppose the idea that you can create a Panic Button app
>> that will be generally useful for everyone.
>>
>> ~abel
>>
>>
>>
>> [1]: quick FDE intro: your FDE password unlocks a key on disk which is
>> in turn used to decrypt your disk
>>
> 
> 
> 
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
> 


More information about the Guardian-dev mailing list