Am Dienstag 06 August 2019 18:25:38 schrieb Daniel Kahn Gillmor:
I agree that this should be clarified one way or the other.
From my reading it is clear from the whole document.
I agree that the phrasing can be improved at the place you were pointing out.
If the contents is highly sensitive, the user will decide to not send.
Otherwise the user will not care, not paying attention to the display and
send anyway (not caring if it is encrypted or not).
I'd love to see some studies about the usability of such a warning.
The idea is not to have a "warning", but to show the state next to reach
recipient and in addition combined in vicinity close to the send action
element. The user can pay attention to it, but is not hassled by it either.
(It would be fun and very useful to have more usability studies, but this
seems unrealistic as we yet do not know how to get a solid funding for
important parts of the core infrastructure like the keyserver implementation.
OpenPGP implementations and the software and infrastructure for a good user
experience are underfunded and have been underfunded for many years.)
how many fine gradations of "valid" is the user able to distinguish between
in an actionable way?
Many, I believe, because:
This is more close to how people model talking about diffent things
in "real life". If you happen to say something sensitive who will check whom
you are talking to and where. You would not say something bad about your
school with the teacher on the next table for example.
fwiw, i agree that more explicit and opinionated guidance for
implementers would be useful here too. I would be pretty sad if that
guidance was to specify some sort of "you should be worried, but
probably you can't do anything differently to address that worry" alarm.
Alarm fatigue is a real and well-studied thing:
https://en.wikipedia.org/wiki/Alarm_fatigue
It shall be modelled not like an alarm, but as a normal situation
as there are many reasons why a trust can be reduced. The issue is, that if
you are really sending something sensitive you'll double check, most of the
time you won't pay much attention.
The idea with the current WKD is to solve the main use case first and
well. And simple to implement. Other use cases can be considered
afterwards.
Here we have a concrete use case for an important vendor of
OpenPGP-related software, who has found that WKD didn't align with their
standard practice until an outside party brought it to their attention.
Which use case and which vendor?
(So far I was not aware of a use case in this conversation. The only vendor I
was aware of was Gpg4win which would be us.)
Getting other active pubkeys or old pubkeys can be handled by the public
keyserver network. (On gnupg-devel@ I've pointed out how an improved
keyserver implementation can handle necessary data privacy requirements,
be de-central, transport third-party signatures, including searchable
non-email ones, and defend against spamming and flooding attacks.
Regards,
Bernhard
--
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp