[messaging] Let's run a usability study (was Useability of public-key fingerprints)
trevp at trevp.net
Wed Mar 12 23:52:41 PDT 2014
On Wed, Mar 12, 2014 at 11:18 PM, Tom Ritter <tom at ritter.vg> wrote:
> On 11 March 2014 00:41, Trevor Perrin <trevp at trevp.net> wrote:
> > Fingerprint Types
> > - Visual and poetry fingerprints seem worth including.
> Does anyone have a preference for type of visual fingerprint? Some of
> the implementations I know of are:
> - Identicons:
> - Monsters: http://www.splitbrain.org/projects/monsterid
> - Wavatars: http://www.shamusyoung.com/twentysidedtale/?p=1462
> - Unicorns (really)
> I think I will go with identicons unless anyone really thinks unicorns
> is better ;)
I think this is the most referenced:
"Hash Visualization: a New Technique to improve Real-World Security"
As far as poetry goes, I think I missed that, couldn't see it in
> archives either. Is there a reference to what poetry fingerprints
> would look like? Is it significantly different from english words?
> > Modulating Speed
> > - For the "Spoken Aloud" test, why not just have pairs of subjects
> > the fingerprints by speaking to each other?
> Is the idea here to make the speed at which fingerprints are read
> variable, but out of the control of the experiement conductor, so it's
> variable in a "simulating the real world" sense?
Yeah, it seems like a more realistic test, since it allows subjects to come
up with clever strategies to communicate things (e.g. a phonetic alphabet),
or stumble over things (accents, getting confused over where they are in
the char sequence, etc.)
> Error Rates
> > - I'm not sure about the '"One Subtle Flaw" case, because the
> > have different notions of "tokens" so this will be hard to compare
> > formats. Also, it doesn't model a realistic attacker.
> I agree it doesn't model a real attacker, but I thought it might help
> us draw conclusions better. Instead of just saying "Most users are
> not fooled by a 2^80 match", perhaps we can say "If users actually
> verify fingerprints, most are not fooled by any unmatching bytes."
> Across the spectrum of unmatching bytes (from all bytes unmatching to
> no bytes unmatching) test points along the spectrum to see if there's
> a dropoff. Granted we're only testing a couple points, but it seemed
> this was a good point on the spectrum.
Maybe, though I still think it's less useful than considering plausible
attacks, so I wouldn't put that test as a high priority.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging