[messaging] Fingerprint usability study (experiment design)

David Leon Gil coruus at gmail.com
Thu Jun 19 16:22:12 PDT 2014

On Tuesday, June 17, 2014, Daniel Kahn Gillmor <dkg at fifthhorseman.net
<javascript:_e(%7B%7D,'cvml','dkg at fifthhorseman.net');>> wrote:

> On 06/16/2014 09:59 AM, David Leon Gil wrote:
> > *Factor C.* Psychological incentive to accept fakes:
> In the real world, the incentive to accept fakes is slightly different
> than either of the above.  In nearly all scenarios [0] where a
> fingerprint is presented and needs to be confirmed or denied, it is *an
> obstacle in the way of doing what you were trying to do*.

Agreed. There is, however, a fairly rich literature showing that, under
many circumstances, experimental subjects want to please whomever is
conducting the experiment. I think that you can therefore come close to
real-world conditions:

E.g., (a non-MT) experiment might be: Subject is told that the study is
about the user interface for playing some game* via ChatSecure; will play
10 games. As part of instructions, are told to verify fingerprint for
games; if fingerprint doesn't verify, won't be able to play. Do a few
sessions, presenting valid fingerprints; then present invalid fingerprint
(before, e.g., session 5).

The idea is to make verifying the fingerprint purely instrumental, as it is
in real life, and an invalid fingerprint an obstacle.

(Some of the SSL warning studies have played with this -- but the designs
get complicated quickly.

*The activity needs to be something modestly engaging.

> That is, if you say "this doesn't match", then you don't get to talk to
> the other person, or you don't get to visit the web site, or you don't
> get to log into the server.
> I'm not sure how you'd model this incentive properly in an experiment.

But you'd agree, surely, that the in-place test is fine?

>         --dkg
> [0] OTR is just about the only exception to this obstacle situation, and
> in practice, many users of OTR simply skip the fingerprint comparison or
> SMP confirmation step entirely (which i think might even be strictly
> worse than accepting an unverified fingerprint once and getting
> TOFU-like alerts upon peer key change).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140619/9d5f7dcc/attachment.html>

More information about the Messaging mailing list