Add Identity text fields in Admin interface

[ninavizz]

Description

In the Qubes Workstation Client, journalists will have first-initial/last-initial square "ID Badges" to represent themselves and each other, in message threads and task logs. Example, just below.

In order to support this, the existing Admin interface needs to have capabilities to support those ID badges with data.

Screenshots of the most obvious solution to this, are below. Per the convo thread below this comment, alternative options could ideally be considered and tested prior to an implementation.

• FN/LN fields should not be required, as they'll only deliver value on the Workstation Client
• Both name fields should be longer than the existing username field, to accommodate for lengthy English hyphenated names and lengthy first and last names in non-Western alphabets/cultures.
• When onboarding a newsroom to the Workstation Client product, it should be made clear that adding FN/LN entries for all journalists (even if just as single initials) is recommended.
• In attached mockups, a subtle few tweaks were also made to the list of users in the Admin list. Sorry, I had to. Only done to facilitate legibility w/ existing assets and type styles.
  • Left-align all fields
  • Increased linespacing (or top/bottom row/table padding)
  • Add a pale grey horizontal line between entries.
    • This will help make the list more readable with multiple empty FN/LN entries.
  • Reduce type size and make grey, the timestamp entries. Another legibility tweak.
  • Move the "Edit" column to be the first on the left, and the "Delete" column to be the last on the right.

User Research Evidence

The UX kid just says to (and the Workstation Client will surface collaboration info much less easily, if this capability is not added). "LL" for Lois Lane, and "SY" for Steve Yzerman is an existing messaging-app and email-app paradigm that has been validated in testing as having low cognitive friction, while also being easy to implement (s'long as the columns in data tables already exist, hence this Issue).

User Stories

As the Admin for the Daily Planet, I want to give my SecureDrop journalist users first names and last names. This will help surface cross-team activity clearly and in a fashion that's easy to comprehend, across the super sweet new Qubes Workstation Client. Because the Qubes Workstation is SO awesome and all our newsroom's journalists want to use it, I'd also like the list of all users tidied-up a touch so that it's more legible beyond 3-4 line items (a little ux bird hinted that'd help).

As a Journalist using the Qubes Workstation Client, I want to be able to see my own activity reflected in an easy to recognize fashion. Likewise, I want to be able to see the contributions and activities of my colleagues in a similarly easy to recognize fashion.

[ninavizz]

Workstation mockups (with various design elements in flux) showing examples of aforementioned ID Badges in use, to surface activity 411...

[ninavizz]

Am curious though, if users in more adversarial orgs/countries may feel vulnerable being asked for this info—like it could put them at risk existing in a system, vs a less easy to pin on them username. Def something I'd like to see folks asked about, in forthcoming testing/interview sessions!

[eloquence]

What do you propose as a fallback when no real name is configured (feel free to link to relevant issue)?

[ninavizz]

@eloquence for the Workstation? The first two letters of the username is the most no-brainer thing that comes to mind.

If my speculation around the importance of maintaining plausible deniability is legit (or just because we should because we're so security/risk-focused?), an alternative approach to FN/LN fields would be "How would you like to be called?" as one text field, and then as the second one showing an ID badge and requesting 2 characters be entered for a team to identify that person. Such a screen would require supportive text to properly guide admins from newsrooms like Bloomberg and Meduza (on opposite sides of a risk spectrum), and everyone in between.

Happy to mock-up the latter at some point. Not wanting to get too distracted from immediate tasks with this atm, tho. I'm increasingly liking the idea of the latter, tbh. Optimally, we could offer BOTH methods as options in the Config panel, so the less risk-averse (and more culturally mainstream) newsrooms could get what they're comfortable with, and the more adversarial newsrooms could get something to meet their needs.

[ninavizz]

...we haven't yet created salutory text in the Workstation Client UX ("Hello, Erik!") so the "How would you like to be called?" option may not be necessary. Would be fun to do testing with various options of this, tbh!

[eloquence]

for the Workstation? The first two letters of the username is the most no-brainer thing that comes to mind.

That makes sense to me. Should the username dellsberg become DE, de, or De? I would say de since it most closely approximates the actual username and therefore is most likely to be familiar. (The user name is case-sensitive.)

Regarding the security question: Right now, from the source's point of view, replies are not attributed. We've discussed potentially changing this, but no such change is currently on the backlog. Provided that sources continue to see replies without attribution for now, I think it's unlikely that this type of optional attribution to other journalists poses a security risk.

If/when we cross the line to reply attribution (from the source's point of view) we have to be very clear about a) what the default behavior should be, b) how that reply attribution is communicated to the journalist. Does that make sense?

[ninavizz]

I edited the main comment in the Client Epic Issue to have the username-initialization for now to be DE but I had not thought of the angle you offer—which frankly, is quite a judo-move observation! I woulda never thought of that, hooray collaboration! Will now edit the Client Epic Issue, to reflect de as the styling of choice for dellbserg. :)

Reply Attributions that the Source sees: Yeah, I'd had that filed in the back of my head as a ways-out can of worms yet to touch.

In-App attributions that other Journalists see: So... thinking back to my own work with a far less legal-risk-involved art group, even in our own internal stuff we never used both our first and last names, or initials, together. Should a Workstation laptop fall into the wrong hands, or should a State actor be able to hack into an SD instance, Journalists would then then be "exposed" by name as indictable leak facilitators to target. That may be unreasonably extreme to anticipate, but that could be a back-of-mind concern for journalists (and/or Sources) in especially adversary newsrooms. Thoughts?

[eloquence]

Since it's optional, I think the main question is how we communicate a) the fact that it's optional, b) the fact that only other journalists/admins see it, not sources.

On the page where user names are provisioned, we may want to provide some additional hints to that effect, so that administrators can make an informed decision when provisioning user accounts about whether or not to add a real name.

That said, I'm adding the "security" label and tagging @emkll as any change that relates to a news organization's threat model should get his input.

[ninavizz]

@eloquence I just remembered last night, why initials must be capitalized in ID Badges vs lowercase—because capital letters are all on a consistent rectilinear visual grid, and for l/c letters such as "p" and "f" with "ascenders" and "descenders," visual wonkiness happens. Additionally, letters with descenders simply have nowhere to fit into a compact space.

I personally prefer the legibility benefits of l/c, however—but for automation and usability, I'm afraid they gotta be uppercase. I did a whole study on how this all works when I worked on ID Badges at Yahoo!, a million years ago (ok, 13—but in tech, that's almost a million?). I appreciate your suggestion, though. Does this make sense?

[emkll]

I don't see any security issues by doing this if the response attribution is Journalist-facing only and provided that it's opt-in, since we definitely don't want to surprise existing users (Journalists) with this new behavior. The username + real name solution described above (or a similar username + initials scheme, where initials are opt-in) seems like a sound approach to me: using a new field will ensure it's completely opt-in.

[sssoleileraaa]

Per discussion with @ninavizz:

• First and last name can be None so if only one name is provided, use the first initial of whichever field has a name for the ID badge, e.g. Nina -> n
• If both first and last name are provided, use first initial of the first name paired with the first initial of the last name, e.g. Nina Vizz -> nv
• If no name is provided for either field, the badge will use a default image provided by @ninavizz

[ninavizz]

UPDATE after discussing w/ Allie earlier, I am now thinking the below. Because it elegantly follows probable/anticipated corporate username/email conventions. I also want to be considerate of users such as @heartsucker and @redshiftzero and @eloquence who prefer keeping birth names out of usernames—yet outside of hacker/nerd communities, I don't know how familiar peeps on a team may be with each others' aliases.

Does the below make sense to y'all?

---

Given I'm a journalist and I am logged in
I will always have a username
That username is nalter for the purposes of this spec.
——

When I also have a first name saved to my account nina
And I have a last name saved to my account Alter
Then my ID badge will show in lowercase, the first initial of my first name;
and in lowercase, the first initial of my last name: na

When I have no first name saved to my account null
And I have no last name saved to my account null
Then my ID badge will show in lowercase, the first 2 characters of my username: na

When I have no first name saved to my account null
And I do have a last name saved to my account Alter
Then my ID badge will show the first 2 characters of my username na

When I do have a first name saved to my account nina
And I have no last name saved to my account null
Then my ID badge will show the first 2 characters of my username na

[sssoleileraaa]

I believe the only difference between this and what was discussed 5 days ago (#4251 (comment)) is this:

Nina -> n -> Nina -> ni

As long as we keep the fields nullable to support people who don't have a surname or prefer using a handle, I don't feel strongly about the two-character change.

[ninavizz]

It makes more sense to you in the below scenario to use nion the user's badge instead of na (posting to clarify)? First-initial-lastname being a corporate email/username paradigm, using the first two characters of the username makes more sense to me, if there's not both a first name and last name.

Given I'm a journalist and I am logged in
And my username is nalter
When I do have a first name saved to my account nina
And I have no last name saved to my account null