Consistent usage of password/passphrase in docs/code

[heartsucker]

Feature request

Description

The docs and the code should consistently use password or passphrase as much as possible. Currently it seems like a hodgepodge of both. There may be a reason for this, but it seems like this could be consolidated down to just "passphrase" everywhere.

[pierwill]

Making comparable changes to the code base will involve heavy lifting (#2690 (comment))

I'm willing to go thru the codebase on this—see if I can change most of the trivial occurrences of "password." Is this a good plan, or are things likely to break?

[heartsucker]

The only place that this might break is that in models.py we have have two fields of Journalist called pw_salt and pw_hash. Those cannot be changed. But also we have a test suite, so if you do break something, we'll know. Also, it may be possible that the SASS has references to classes called password, so you may need to look there as well as in {journalist,source}_templates/.

[eloquence]

Flagging this as "needs discussion" since we should first agree what to use where before making UI changes. We can discuss in future eng meeting.

[ninavizz]

As I've come to understand this discussion, the PRO of the language passphrase is 2-fold:

• OpSec best practices have us needing to reinforce the use of multi-word passwords... for which "phrase" is semantically correct and "word" is semantically incorrect.
• With SD specifically, Diceware is strongly encouraged
• Both of the above are reflected in training curricula, and in SD docs

Personally, I also find it to be more elegant verbiage than password

Conversely, the word passphrase concerns me because it's use is identical to what users have mentally-modeled as a password; and we recommend password managers and speak to password hygiene, as more common concepts in the public conversation. I also raise an eyebrow of concern that passphrase may feel esoteric or self-important in the same way the paint color name ecru does (vs just calling it off-white).

Some questions I'd like to consider in research efforts:

• Is there value for users in the subtle distinction of calling it a passphrase?
  • Does use of the term passphrase positively contribute to changes in thinking and in user behavior around opsec that is desired?
  • Does use of the term passphrase trigger a cognitive disconnect or create confusion?
  • In their natural environments do users continue to use the term password—while still embracing Diceware, multi-word best practices, etc.?
  • Does our holding to semantic correctness with language create a disconnect from socially trained habits or routines? Would we be better served paving the cowpath of password, in spite of its semantic incorrectness feeling bothersome?
• Might our use of the word passphrase vs what is more common in the public dialog (password) add to a perception of FPF trainer or SD recommendations being tin-foil-hat-y, extreme, or esoteric?
  • Is FPF currently measuring how well or poor taught practices are adopted by newsrooms that engage us?
  • Could we more regularly seek to track this in ongoing user testing or interviews?
• Do SD users or FPF trained journalists adopt Diceware into their complete digital lives?
  • If so, why?
  • If not, why?
  • Regardless, what do they adapt to calling it—a password or a passphrase?
• Is a desire to be semantically correct in our use of language working against the broader goals?

Ok, everyone can stop rolling their eyes, now. Sorry/notsorry. Not out to be a negative nancy, ux kid just has concerns for if/how team intents percolate into user behavior...

[eloquence]

It's important to note that our current usage remains highly inconsistent. For example, the Journalist Interface refers to phrases like market null sherman andes orbit holly ready as passwords throughout, both on the login screen and when creating a new user. The documentation, on the other hand, mostly refers to passphrases in the same context. This is a nice example:

https://docs.securedrop.org/en/release-1.0.0/journalist.html#connecting-to-the-journalist-interface

Note how the documentation instructs the user to enter a passphrase, while the UI refers to it as a password. 🤔 Meanwhile, the client login screen currently calls it a passphrase -- at least there's no third word in active use. :)

My own preference is to use "password" when referring to passwords or password managers, and "passphrase" when referring to passphrases. The terms are not synonymous, and educating users about the difference has value. This is especially true for SecureDrop's passphrases, which have spaces between them, making them very unlike most passwords. I agree we should research further whether the term creates usability impediments before standardizing on it -- we may be able to lightly incorporate this into the next batch of remote tests.

This discussion relates to the ambiguous uses of "codename" (#4096), which should IMO also be simply called passphrases in the case of the source codename.

[ninavizz]

All of this is highly qualitative inquiry in nature, and I feel is best suited to be studied as part of the Workstation Pilot—or, as part of ongoing interview, contextual inquiry, or diary studies.

Remote user research I feel is like A/B testing, in that its value is limited to more quantitative and binary "Did changing that one thing help or hurt?" outcomes. Which is not to discount the incredibly high general value in the remote studies we've been doing with the Source UI... as no research had ever before been endeavored.

I just feel that things like subtle language tweeks or broader concept understandings need to be talked through with users, and habits studied over time, for those learnings to be understood well enough to make product bets against.

But, yeah... all of us could go purple in the face, debating it—yet this is one heckufa ripe QuallyQualQual point of inquiry for users! #learnalltehthings And yeah, I also agree—this would pair nicely with some codename concept-model inquiry, as well.

[rocodes]

Bumping this issue as a priority for discussion--we should ensure that the source story is clear on
what the codename is (it's your private passphrase, not your "alias"), and that it's easy for sources to understand/fits with their mental model of SecureDrop usage.

[eloquence]

(Note: Because this covers both code/UX and documentation, I'm not migrating it to the new securedrop-docs repo.)