[cap-talk] Security considerations for cookies

[Toby Murray]

On 23 February 2010 19:16, Sandro Magi <naasking at higherlogics.com> wrote:

> On 23/02/2010 3:58 AM, Toby Murray wrote:>> I agree, but gmail already
> sports a solution: require the user to pick a
> >> custom theme, colour scheme, or a unique icon for his webmail interface,
> >
> > I use the standard default for all. I'm sure the vast majority of
> > users do likewise. I'm not convinced that this would offer any real
> > protection, therefore.
>
> Hence why I said the user would be required to pick one, and the order
> of selections presented would always be randomized.
>
>
Sorry, I thought you were implying that GMail already implements this.

I'm still not convinced that even I would be protected by this system
however.
Were I presented with the wrong scheme, I might well just assume Google was
buggy.

You're asking users to make a mental judgement ("I might be under attack")
which they are loathe to do. Who wants to believe they might be under attack
when it's much easier to believe GMail is buggy?

Just as secure systems need to be designed so that "the most secure way for
this system to be used, is also the easiest and most natural way to use it"
they also need to be designed so that "the mental model for the user to
adopt that yields the interactions with the system that keep the user most
secure, is also the easiest and most natural for them to adopt", with "easy"
there interpreted to include "requires the user to make the least number of
uncomfortable assumptions, or adopt the least number of beliefs that lead to
uncomfortable conclusions".

Only real fear makes people adopt uncomfortable beliefs (c.f. terrorism
hype). Without proper fear, people naturally choose beliefs and assumptions
that produce less discomfort (c.f. climate change denial).

It follows that any system that requires the user to consciously acknowledge
the fact that they might be under attack, in order for it to be secure, is
sub optimal.

Cheers

Toby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100223/06cda0c2/attachment.html