[OLPC Security] Seamless Lessons & Security (commentary)

Toby Murray toby.murray at comlab.ox.ac.uk
Tue Jul 8 05:57:48 EDT 2008


On Tue, 2008-07-08 at 11:47 +0200, Bert Freudenberg wrote:
> Am 08.07.2008 um 09:11 schrieb Toby Murray:
> 
> > On Tue, 2008-07-08 at 00:27 +0200, Bert Freudenberg wrote:
> >> Am 07.07.2008 um 23:31 schrieb Martin Dengler:
> >>
> >>> On Mon, Jul 07, 2008 at 05:03:58PM -0400, Ivan Krsti�? wrote:
> >>>> On Jul 7, 2008, at 4:50 PM, Hal Murray wrote:
> >>>>> Is that good enough?  I think it would work fine for paranoid
> >>>>> security geeks,
> >>>>> but what about school children?
> >>>>
> >>>> It's good enough because the purpose of the dialog is not to  
> >>>> protect,
> >>>> but to inform.
> >>>
> >>> I respectfully disagree that the dialog/notification can achieve  
> >>> that
> >>> goal.
> >>
> >> The goal is to prevent an activity from automatically launching
> >> another activity without user interaction. A system-provided dialog  
> >> or
> >> menu does that just fine.
> >
> > Isn't that like saying that the goal of airport security is to ensure
> > that noone can board without showing ID.
> >
> > No it's not. The goal of airport security is to ensure that noone can
> > board who is deemed unsafe to allow to fly.
> 
> Right. But Bitfrost is not about airport security.

No but airport security demonstrates that intelligent people can fall
victim to thinking they're providing security when what they're really
providing is security theatre.

The dialog/notification that Ivan cited above is an example of security
theatre.

> > Likewise, the goal here is to
> >
> > 1. prevent an activity from automatically launching another unless the
> > user has designated in some way that they want the other activity
> > launched
> > 2. ensure that the launched activity is not given any authority that
> > the user wouldn't expect it to have
> >
> > #2, like #1, should be inferred from the user's actions.
> 
> 
> #2 is handled by Rainbow. #1 is handled by any unspoofable method  
> requiring explicit user interaction.

It's the form of the user interaction that bothers me. Unless the user's
intent about authority can be inferred from this action, the problem
hasn't been solved. You're just providing security theatre and training
users to click through unintelligible dialogs.

> Maybe you should read up on Bitfrost again. Your fancy information  
> will not get read. In fact, the user might be a kid who cannot read yet.

What fancy information? I'm advocating not providing an
"information"-laden dialog that makes no sense to the user -- whether
they can read or not. I'm advocating the whatever user interaction is
required for the unspoofable method invocation, you better be sure that
it conveys enough information to infer the authority that the user
expects the activity to be granted.

I think we probably agree here and are just talking past each other.

> Feel free to forward to the mailing list if you intended this exchange  
> to be public.

This message is being cc'd to the list. I hadn't realised that the list
doesn't set the reply-to address back to itself rather than the original
sender. My bad.

Cheers

Toby




More information about the Security mailing list