More accurate alert for insufficient passphrase length (letters -> characters)

[nemanjaglumac]

Status

PENDING REVIEW

What does this PR accomplish?

• Uses "characters" instead of "letters" to describe the minimum passphrase length in the related alert
• Updates the documentation accordingly

Note Although it might seem like nitpicking, the distinction between letters and characters is quite important when it comes to the password complexity.

[getify]

From a user perspective, isn't "letters" more friendly, and plenty accurate enough to communicate what to do? I know they may be typing other symbols that aren't letters, like spaces and hyphens, but do we really think users will be confused with the word "letters" and think it strictly means A-Z?

[nemanjaglumac]

I don't remember ever seeing "letters" being used in the feedback message for the passphrase length validation. No idea if users find it more friendly, though.

But they might be more familiar with seeing the term "characters" (which kind of makes it more friendly?)

Some quick sanity checks:

Google

Microsoft

GitHub

FrontendMasters

[getify]

In fairness, most of those are developer facing products. But... point taken.

I don't feel strongly enough either way, so I wouldn't block the change. I just wanted to double-check the justification for changes.

[getify]

By the way, the length check is a placeholder until we define a better set of checks for "strength" heuristic. I would actually prefer to require a certain minimum number of words (with any whitespace or punctuation separators) more than an overall phrase minimum.

[getify]

Another side note, regarding "sanity check". I often find myself wanting to use exactly this phrase, including just now as I was writing the previous responses. It's very natural and ingrained in my way of describing my thoughts/questions.

However, I've been attempting to be more sensitive to abelist language, and I believe "sanity" (as it reflects general mental health status) is one of those phrases that is seen as misappropriating human conditions to apply to non-human contexts like technical discussion/debate.

I don't want to have anyone who's a contributor or future user ever feel alienated if the choice of wording we use can be filtered to be a little more sensitive to our complex human differences spectrum. I would encourage similar attempts and sensitivity to language like this, avoiding things like "that's crazy" or "this is more sane", just like we should try to avoid things like "are you blind!?", etc.

Not a chastisement or criticism, just a gentle reminder to try to be as welcoming and inclusive as we can. Thanks for understanding! :)

[nemanjaglumac]

Message received - loud and clear! :)

[n8zone]

@getify What are some alternate phrases you'd suggest using instead?

[getify]

@NathanMazzy Depends on context, but...

"clarity check" "context check" "validity check" "verification"

Those are some words/phrases that come to mind.

[nemanjaglumac]

By the way, the length check is a placeholder until we define a better set of checks for "strength" heuristic. I would actually prefer to require a certain minimum number of words (with any whitespace or punctuation separators) more than an overall phrase minimum.

Back to the original topic: In my current job, we are checking against the list of common passwords (that we maintain). Not sure if that sounds like a good idea for additional "fortification" of this feature in the future?

[getify]

@nemanjaglumac I don't think we'd want to embed such a list of passwords/phrases into the app, if for no other reason than that it might increase the code size significantly (depending on the length of course). I also wonder how we'd generate and maintain such a list, seems like it might be quite subjective. Would we generate a big list of phrases from books and movie quotes and stuff like that? Not sure.

Also, a minor concern is, publicly distributing a comprehensive list of what phrases/passwords are NOT allowed means that a brute-force cracker knows whole swaths of the space that they don't need to try. It's different when the disallowed-list is maintained privately on a server as opposed to being included in the main client app code in plain text.

[getify]

I addressed the "letters" vs "characters" thing with some other code changes, so that obviated this PR. But thank you for raising the concern.