On 7/15/2014 10:22 AM, Ned Freed wrote:
2. References to changes in MUA appear to be pointing to assumptions
about efficacy of what is displayed to users. Such assumptions are
empirically incorrect, and mostly serve to demonstrate why the IETF is
the wrong place for discussion about UI/UX/UCD and human usability
issues. Really, the disconnect between that one assumption and what is
actually known about email user behavior is fundamental.
I've been letting this set of assertions float by unchallenged for a long
time,
in part because the effort needed to change dogmatic beliefs is considerable,
and in part because like most dogma, there's a kernel of truth buried inside.
This seems like as good a time as any to stop doing that. So: This is little
more than pernicious nonsense.
Incurring the considerable expense, in people and opportunity cost, by
pursuing a global standards effort that proves ineffective is a
particularly pernicious path, especially with respect to a
security-related topic like phishing.
So, when offering my dogma on this topic, I usually make a point of
tossing in some lingo as a touchstone to the expertise of the topic; I
usually also offer an example of a poor design assumption. My usual
reference for the latter is that discussions here tend to be predicated
on the assumption that presenting users with more information is always
a good thing.
All of this is by way of indicating that it's not actually dogma. On
the average, the point is missed, as seems to have been here. (See below.)
But since it's all just dogma, I should stop listening to the folks that
work in the HCI and Usability disciplines, like any conference on the
topic and discourses by folk such the Nielsen Norman Group, such as:
User Education Is Not the Answer to Security Problems
http://www.nngroup.com/articles/security-and-user-education/
(The 'Norman' is Don Norman. I certainly hope than anyone claiming
knowledge in this space knows his name and how it is relevant to this
discussion. Nielsen is no slouch either...)
or at CUPS:
http://cups.cs.cmu.edu/
such as their discussion of:
Teaching Usable Privacy and Security: A guide for instructors
http://cups.cs.cmu.edu/course-guide/#cm-interaction
As for dogma, does this mean that:
a) As a community, the IETF /does/ have solid technical competence in
user-related security design? Given that the state of the art --
nevermind the state of the deployed industry -- is notably poor in
usable security, perhaps the IETF has been hiding insights in this
space? Perhaps someone can provide the basis for a claim that the IETF,
as a community, does have the competence to specify details of end-user
experience?
b) Relying on recipients to make informed security decisions based on
vetted From: fields really is the answer to stop phishing.
Typically, when a proposal is made to do something that will be useful,
the burden is on the proponent to substantiate a claim of efficacy.
Perhaps I missed it, but that affirmation seems to be missing here.
First, this is essentially a strawman. We're not talking about dictating UI
design here. What we're talking about are the semantics and general handling
requirements for some of the most basic protocol elements in email.
And here we have what is a pretty typical demonstration of missing the
point about the topic. UI design is the details of the user interface
design; where things go on the screen, for example.
By contrast, UX is the broader flow of user/computer semantics for an
application or service.
Sorry, but every time someone makes a reference to presenting
information to users, they are dictating UX and relying on its efficacy
for security enforcement.
Nobody is saying that we should start specifying what has to be diplayed to
users, let alone how.
The notes from Viktor and Scott (and most -- but not all -- people who
are DMARC advocates) is that users will make useful security decisions,
if the right information is presented to them.
Assertions of what should be presented to users is /exactly/ the
predicate to this sub-thread. That's why I've pointedly advised that,
instead, the target should be the receiving abuse filtering engine.
d/
ps. Perhaps folk can get back to offering comments on the draft DMARC
charter?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net