Re: [Tails-ux] Encrypted Storage

Delete this message

Reply to this message
Author: sajolida
Date:  
To: Tails user experience & user interface design
Subject: Re: [Tails-ux] Encrypted Storage
Lunar:
> tchou:
>> Just to say it again, to make it clear that I disagree with one tiny point :
>> - I think that most of the time wrong "password" are *passphrase* typo
>> (and kind of long)
>> - In the case, my point is that i think it's better to keep the wrong
>> passphrase and make it possible to read it (with the "show passphrase"
>> button) and fix the typo. We can add a "clear" button too.
>
> Let me rephrase to make sure we understand one another: you are saying
> that most of the time errors in passphrase are just typo. For that
> reason, you advocate that we should not erase the whole field in case of
> errors because it gives a chance to correct the typo and proceed with
> login.
>
> [Please correct me if I got it wrong.]
>
> I agree on the first assumption. I do typos in my passphrases all the
> time.
>
> But then? I don't want to take the chance to have my passphrases learned
> by bystanders looking at my screen. Once I made a mistake, I can't learn
> where is the typo by looking at identical black circles. So starting
> again from the beginning is the only option.
>
> If someone is confident that they are safe having the passphrase
> displayed on screen, they can always click the “Show passphrase” button
> before entering the passphrase and fix typos while they are typing it.
>
> Not clearing a wrong passphrase would make the greeter behave
> differently from all software on the Tails desktop from the quick look I
> had at it.
>
> Sadly, I haven't been able to find this question mentioned in GNOME HIG.
> Maybe that's worth opening a bug there?


I tend to agree with Lunar on this.

I've never seen a password interface behaving like this and I suspect
this to look like a fancy idea that ends up being a bad one (first of
all because it's unusual). So honestly, I don't think it's worth "trying
to fix" password entry fields this way; or at least I fail to see why
our particular context is different from every other password field I've
see in production so far.

We can probably find hints about password entry fields in other HIG
(Mac, Microsoft) and probably UX research in the academic literature.
But I won't volunteer to do that or spend too much energy on this issue.