Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Stefan Claas]

On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
> On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>>  * in the "distinguishing" model, it's not clear that any of the schemes
>>>    i've seen are actually better for most humans against a dedicated
>>>    attacker who crafts fingerprints to make visual identities that look
>>>    similar.  do you have any studies showing this capability against a
>>>    motivated and technically capable attacker?
>> No, of course i have not. My thoughts as a not so-skilled GnuPG user
>> would be that it helps users detecting (assuming it's bullet-proof)
> what does "bullet-proof" mean, specifically?  I ask this not for
> pedantry's sake, but because clearly stating the problem makes it
> possible to know whether a specific solution is applicable.
For me it means that the idendicons should be visually easy to read
and cryptographically secure. Sorry that i have no better explanation.
>
>> a proper key from a fake key more easily if they have not yet signed
>> (locally) a public key while they already exchanged a couple of
>> emails.  I can speak only of Thunderbird/Enigmail wich i use now. It
>> gives a user the usual "Untrusted Good Signatur" and i have to click
>> also on the Details button to carefully verify the fingerprint from an
>> addional list to see if the key belongs to the person the signature
>> claims. An additional visual fingerprint would make that proccess for
>> me easier, if it's bullet-proof.
> It sounds to me like you're saying that you find the key verification
> and certification steps as implemented by enigmail to be
> difficult-to-use.  You wouldn't be the only person who has that
> impression.
>
> But i don't see how a graphical icon solves that problem.  Isn't it a
> workflow problem, and not a visual-comparison problem?  If there's a
> standard thing (comparison, lookup, verification) you expect to be able
> to do with the tool, the tool should make that thing easy and simple to
> do.
>
> What specifically is the thing that you're trying to do when you click
> "Details" and verify the fingerprint (from what list?)?  Enigmail itself
> can compare fingerprints far better than you or i can, even if there is
> a graphical representation involved :) Maybe there's a different
> question or different interface Enigmail ought to offer in the "Details"
> view entirely?
Well, in the past, before i started using this email combination i
used web based email accounts copy and pasted the message into
a text editor and had no auto key retrival and looked up WWW
key servers to download the required key to verify the sig. I had
not often communications back then. So this was an acceptable
workflow for me.

With the current set-up it's all automatic and my understanding is
that in case i would receive a fake message my set-up would download
the fake key, display it as "Untrusted Good Signature" too, because i
have not yet locally signed the key. Therefore i click details to see the
fingerprint (which i can't memorizy) and look it up again. Maybe, as
casual user who never used this set-up before, i make a fundamentally
mistake in understanding of how the auto retrieve and verify function
works. I mean why is a Details button there to see a fingerprint which
i believe nobody can memorize in the first place? It must serve a purpose,
or not?

>>> I'd generally think that if you're looking for a tool to help people
>>> remember and recognize keys that they've seen before, then a mail user
>>> agent is in a great position to do exactly that: just tell the user
>>> explicitly what they've seen before, how often, etc.  why depend on the
>>> human visual cortex or on human ability for numeric recall?
>> I could imagine that Joe user average may not always look at mail headers
>> very carefully for a little typo in the from: or reply-to: header in his
>> mail client or web-mailer.
> i agree with you that users won't look at mail headers closely, which is
> why the e-mail client (the "mail user agent", or MUA) should be the
> thing to do the comparison, and to make it very clear to the user when
> something is amiss.  But that still doesn't answer the question of what
> the MUA should actually be trying to compare and what results it should
> be highlighting.
>
For me a MUA is passive and happily accepts what he receives, whether it's
correct content or not, so i can't answer that question, sorry.

Regards
Stefan