Do you think this is a security risk and if not is it a bad UI decision?

Michael Scherer misc at
Sun May 5 20:29:37 UTC 2013

Le dimanche 05 mai 2013 à 11:18 -0600, Chris Murphy a écrit :
> On May 5, 2013, at 1:40 AM, Pierre-Yves Chibon <pingou at> wrote:
> > So if you disagree please provide *reasonable*
> > arguments.
> Those who disagree have already done this ad nauseum.
>  The summary:
> The Neilsen-Norman article cited is an editorial piece. It is out of scope, out of context,
>  not a study, and not a paper.

As I said earlier, I cited the url to say "there is a discussion going
on". And yes, this is as much useful as all others people stating their
opinions in this thread. The fact that this is still being discussed
( as I found post/article/etc in 2010 and 2012 ) show that's indeed a
complex question, and we can all agree on that.

We can also all agree that we have no conclusive data for anything. IE,
we have no data on shoulder surfing ( ie, is it prevalent during os
installation ? ), nor data to show how problematic is the password
masking in term of user experience.

>  It suggests there's a usability consequence for masked passwords, which is an observation in the 
> realm of Thank You Captain Obvious, that doesn't really need a study. It should be ignored.

It may seems obvious but not everybody seems to agree with that
according to this thread. And so, if it doesn't need a study, then why
dismiss it as "not a study" ? 

Being obvious doesn't mean it should be ignored either.

> It's inappropriate for others to state the relative risk level of a user's situation, rather than 
> deferring to the user's ability to self-assess their risk level.

As a distribution project, we are doing this kind of choice almost
daily. This one is just one among the million one that have already been

I would like also add that not everybody is able to correctly
self-assess their risk level. In fact, I would even say that few people
are able due to various psychological bias like loss aversion
( ), or some
others bias related to risk like :
( and maybe others among the list ).

> The implemented change offers no alternatives, to account for elevated risk contexts.
> There are at least two alternative behaviors:
>     a.) Mask by default with two fields, with an unmask option that would gray 
> out the (now superfluous) second field.
>     b.) The entry method used on mobile platforms, delayed masking per character. I
>  argued against this in my earlier email when I brought it up. This isn't a mobile platform. 
> It's higher risk, and probably not as easy to employ as option a.) which is a common cross platform behavior. 

Yes, and is not solving the same issue. Again, on a mobile platform,
there is much more accuracy issues than on a PC, thus needing some

Now since the issue with the current change is "I am forced to type the
password visible and I do not want to do it for some others reasons",
yes, that's a problem ( at least to me, even if I think that's a rare
problem, but still a problem ). 

So what about this alternative proposal (made earlier, upon no one
commented ) :

c.) unmask by default, with a explicit mask option. 

That answer to the need of being able to mask if your environment
requires it, so should at least satisfy part of the people who want

And this permit to people who are more likely to make a error to check
without thinking about doing it. 

That's the reverse of option A, because my hypothesis based on my own
empirical users observations is that people who would need to use this
option are not the ones that will think to do it. For example, I do use
the unmask feature for long passwords given by someone else ( ie wifi ),
since I cannot be sure I typed it correctly. But I would likely not use
it for typing my own password for a account creation since I trust
myself to type it right, like I think most people.

And if people want others ideas, there is some creative one like this
one, adding decoy text :

or adding decoy characters :
( didn't work with firefox, only with epiphany )

( as a side note, I suspect that the whole idea come from this
article  : )

Michael Scherer

More information about the devel mailing list