Client workflow equivalent to "Flag for reply" workflow in web UI

[ninavizz]

Problem

When an instance's App server experiences low key entropy (via a DDoS type surge), new source account key pairs are halted. For a journalist to reply to a source submission, it needs a keypair assigned to it to facilitate encryption. Without that keypair, the journalist cannot reply to that Source—though they can still read all submitted materials.

The journalist therefore needs to select which source submissions need to be "flagged for reply," so the server knows to generate a key pair for those accounts the next time activity is detected by those sources (and to trigger the goofy message in the source UI). Alternately, the Journalist should be able to delete the source.

To make this issue extra awesome, there is no knowledge of any user ever encountering this flow—even after 5yrs of SD being in production. As such, inquiries are being made in a parallel research effort—but regardless, light testing of design solution(s) will be sought.

I wish there were a better way to handle DDoS things, tbh. This is a very sucky experience for sources, especially—as right now it remains unclear how or why they should return to see replies.

Considerations

• Explanation of problem in highly technical terms, in today's Journalist Guide.
• Crafting more user-friendly content to explain stuff will at some point be essential
• Exploring iconography to help make this friendly?
• Can note risk-flagging in Snippets area; or, have a filter for them that would include a status indicator?
• Messaging for when the journalist logs in?

Acceptance Critieria

• Clickable prototype
• Zeplin spec
• Any iconography or text assets
• Agreed to solution communicated in parent ticket w/in Workstation Client repo
• Include in Workstation testing punchlist Workstation Beta — User Testing punchlist #35

[ninavizz]

@eloquence how do you want this prioritized abreast my other tickets for this sprint?

[ninavizz]

Instructional Text & Contextual Help Scratchpad

What you need to do
Mark keyless sources; accept or deny? Blah blah blah. Language "flagging" is not right, as this is an action with consequences for Sources—not just marking something for how i will see it.

What happened?
When a source uses your SecureDrop to share information through a new codename, a new encryption key is generated and paired to the new account.

If your SecureDrop experiences a large number of new source submissions all at once, it is possible that could be an attack from a bad actor. When SecureDrop detects this activity it will stop issuing encryption keys for new source accounts. Key generation is then resumed when the suspicions activity surge ends.

What this means
Whenever sources and journalists communicate through SecureDrop, an encryption key is required on each end for shared files or messages to be read. If your SecureDrop recieves a message or a file from a new source but does not pair a key to that source, it is not possible for any of that information to be read. That is a good thing, as it protects

[eloquence]

Let's focus on the sprint commitments for now; Allie and I can do some more research on the current behavior and dump it here, and then you can potentially do a first UX prototype in the next sprint. Does that work for you?

[ninavizz]

Poyfect, thanks! :)

[sssoleileraaa]

Still looking into the currently implementation, but here's some info from way back: freedomofpress/securedrop#150

[ninavizz]

09 May Meeting Notes: Erik/Nina

• Updated understanding of core functionality: FFR = response to low entropy pool status of SD server in a surge, resulting in no keypairs generated for new incoming Sources.
  • For a keypair to then be generated, the Journalist needs to "flag" the Source as legit, and the Source then needs to either sign-in, reload their "Submit" page, or make a new submission.
  • After the above happens, the Journalist may then reply to the Source. Until then, the Reply functionality is disabled in the Journalist UI... but they may still access Source submission stuff for review.
    • Message shown to Sources from Nov 2017 until the 0.13 release, incorrectly summarizes the above. Fixed in SD-PR.
  • For further reading, see this, this, and this bits of nerdery.
  • Is all of the above correct, @eloquence?
• Key design problem: The current single-button w/ 5 words on it in the Journalist Web UI, is universally accepted to be a crummy experience. How could we better resolve this via new affordances and opportunities, in the Client UI? Stretch-goal: Could we then translate verbiage/allusions from what is determined to ship in the Client UI, into the Web UI... to at least re-train mental models?
• Agreed-to modifications and needs:
  • Give Journalists a binary This-Or-That dual-button experience; make it clearer a choice is being made, moreso than the "click this or simply ignore it" single-button experience offers.
  • After brainstorming around how to offer literal button-prompt options that speak to key-paring, it's decided that needlessly convoludes the process—and to avoid.
  • In such a binary experience, "Delete" is the most intuitive counter-action, but the current experience does not delete messages from the server—so it would be innacurate per the current functionality.
  • Fuckit, let's change the server behavior to delete the messages, from the Client. Making such a backwards-compatible update to the Web UI would be more difficult than it's worth, but updated verbiage/button-age in the Web UI would at least be nice.
  • "Ignore" could replace "Delete" in a 1:1 backwards-compatible update to the Web UI

[ninavizz]

14 May: 1st Design Review

» Invision Wireframes «

• In browser window zoom-out so prototype fits into window w/ left and right edges fully visible.
• Use the pink arrows at the top of screens, to navigate.

If you'd like to leave comments on Invision about specific UI elements, feel free to do so—just turn on "Commenting" via the marginally discoverable translucent black tab in the lower-right of your screen, that has a barely-visible toggle control on it.

Shown:

• Screen upon initial Sign-In to users, after an entropy event
• Indication of FFR need in Source List
• "Action Needed" state options for Conversation List
• Button verbiage options
• Button styling and color options
• Verbiage to frame issue to users

Feedback

• Written language
  • "Suspicious Submission" liked by all
  • Allie initially flagged that it's technically inaccurate if multiple submissions have been made; but team agreement that its general ok'ness meets the need well, and is less damning than Suspicious Source.
  • Blurb below buttons, a good first jab; conveys overall concept well in mom/dad-proof plain language.
  • Nina: needs to align with text decided for buttons above it.
• Buttons
  • Text: general preference for Keep/Delete, as "Decline" doesn't directly speak to deletion.
  • Jen, no opinion wrt color/presentation
  • Erik, likes green/red w/ icons
  • Allie: likes Airplane Purple; feels SD blue blends-in too much
  • Nina: likes Grimace Blue and Airplane Purple, but leaning more towards Grimace Blue as Airplane Purple makes the whole UI feel a bit like an Animal Crackers box.
  • Erik: don't forget, users may just "delete" w/ the Source List button, don't have to use binary FFR button
• Convo Pane stuff
  • Erik/Allie prefer 1:1 use of Reply Pane footprint for FFR content/buttons.
    • Nina has issue w/ combined hierarchy and annoying mouse-movement stuff.
      • Erik thinks Nina's mouse-movement annoyance issue is a stretch, and is easily solvable by use of "Delete" button on Source List item.
  • Erik: Why assume users won't want to star a Source who hasn't yet been flagged? Not cool.
    • Also, no user value established to warrant dev effort to remove functionality for this state; even if it were confirmed users would like that.
    • Nina defense: visual hierarchy; keep it clean & focused.
  • General
    • Like use of red bar on Message bubble
    • Jen: FFR Submissions could include files; need to factor that in
• Next Steps
  • Create a "Waiting" screen state, for after a Journalist has acted to keep the Source... but the keypair has yet to be made, and thus they still cannot send a reply.
  • Team really wants footprint retained between FFR stuff and Reply Pane.
  • Keep all functionality on a FFR'd Source, except "Reply".
  • Proceed with Keep/Delete solid rectangle buttons
  • Prototype with a few messages to act upon?

[ninavizz]

Hey gang! I've added a 2nd rev to the existing wireframes.

Pretty siked about how it's shaping up. Some notes...

1. After considering Erik's insight that users can just delete files with the Source List control, I realized it felt somewhat paternalistic to force users to either delete or simply do nothing with that second button—whereas an option not discussed in the meeting, felt like it gives users more agency: to simply turn-off the alert flag in the Source List and to keep the message (so, like, an action for their choice to ignore the suspicious submission). Kind of a compromise of sorts. Which could be over-thinking things, but in the prototype it feels really elegant.

2. The "Ignore" button functions as a toggle, which I also feel can make it work really well for teams (eg: one person disagrees with another person's 'ignore' schtick—why that would happen, we don't know, but I like having the capability when we don't know).

3. I also added a new button verbiage paradigm, with "Key" and "Ignore." It's always my preference to avoid dumbed-down hand-waving around unfamiliar security concepts... and, really, when the user clicks the left button, they are doing more than simply electing to keep or accept something. Which, when the "Waiting" state screen was added to the flow, became evident.

4. Combining all of the above, then, this becomes a rare instance when I feel icons on buttons help to guide mental models via conceptual affordances, vs adding to cognitive-burden or just distracting.

5. I also added a "Yay, accepted!" state to the Source List, to alert journalists to when a Source has accepted the key pair—and they have been cleared to accept a reply. Don't worry Erik, I did not add the word "Yay" to the UI. ;)

As usual, the pink arrows can be your sherpa, but the "Key" and "Ignore" buttons also work.

Thoughts?

» Invision Wireframes «

[eloquence]

Hi @ninavizz, thanks for the revision! Please add this to the agenda for either the UX meeting or the Client Sync, as you see fit (depending on whether you'd like larger cross-team input).

I personally prefer the iteration we discussed yesterday:

• I feel adding the "Ignore" button adds a layer of complexity that we don't need. We'd need to persist this state across sessions, and might even want to track it per-user. (It may be confusing for a second user to log in and find the button already toggled, without any indicator why.) Since the user always has the option not to take an action, I felt the previous "Keep" / "Delete" choice architecture was sufficient.

• While I am 100% with you in looking for ways to help build the user's understanding of what's going on, I am skeptical that the "Key" button combined with the paragraph length text would do it. I think the more likely outcome is that users would be scared and intimidated by that button, because they associate "Key" with the most complex parts of systems like SecureDrop (managing passphrases, GPG keys, etc.). They may think they're not qualified to do whatever this button does, and want to wait for an expert to weigh in.

I feel the previous "Keep" / "Delete" flow achieved user education in a way that more closely matches the user's realities. It asked for the concrete choice upfront, while also offering the explanation of what exactly is happening. It spoke to the user as a journalist, not as a security expert or administrator.

I would generally lean towards avoiding key iconography and language in the UI, because of this intimidation factor -- it suggests that the user themselves will be dealing with keys, which is not the case.

Conceptually, it is also ever so slightly misleading. This action does not generate the key -- it merely gives the go-ahead for keypair generation upon the source's next login. In this sense, the user is not "keying" a source.

That said, I appreciate the thinking that went into this iteration, and happy to discuss as a group :)

[ninavizz]

Hey @eloquence, thx for pushing back w/ the thoughtful comments. I want to be mindful with my limited hours availability & agreed to priorities, and also want to get this right. Looking forward to richer discussion in tomorrow's UX meeting.

For that, I'll update what you're responding to as the "3rd Rev," and quickly add-in the "2nd Rev" we discussed, yesterday. Will push that update to Invision, at some point later this afternoon.

I'm also going to ask of everyone attending (and you) to pls carefully read all UI text when evaluating the solutions—the button texts, and the supportive text(s). As someone new to all this. Ideally, in advance of the meeting (tho I know everyone is busy and has limited time). /cc @zenmonkeykstop , @redshiftzero , @creviera , @harrislapiroff, @rmol , @kushaldas and anyone else I may be missing.

Will ping the SD Slack channel, once I've pushed those updates. Still in research planning cave. :)

[ninavizz]

15 May design review notes

• Harris:
  • Key/Ignore binary confusing
• Olivia:
  • Appreciates what Key/Ignore aspires to achieve
  • Verify/Delete likely clearer to journalist users
  • Disagrees with FFR/Delete and no "Ignore" option as paternalistic
  • Prefers succinct presentation with Keep/Delete
  • Discussion wrt broader issue of server hygiene via "Ignore" button option
    • Admins not often enough engaging w/ Journos in best practices steward role as our hopes/assumptions expect; we want to actively discourage Source hoarding, Delete button does that well.
• Erik:
  • "Verify" is problematic because of social media associations
  • Confirms, "Verify" is a concept about to go into use in SD Directory
  • Skeptical about Source List state to flag Source keypair; pushing to top and marking anew as "New" good enough & doesn't confuse
    • Cites recent convo w/ Nina about confusing blue-bar on the left edge of item in Issues list in GitHub
  • Finds person/checkmark icon in "Reply Pane" footprint confusing
    • Clock icon instead, to present semiotic of waiting?
• Kev:
  • Suggests "Approve/Reject"
  • Erik: "Approve" too loaded
  • Kev speaks to this as likening a moderation workflow
  • Erik mostly agrees, but then raises necessity of Source user action lost in that inference
• Allie:
  • Keep/Delete, preferred; likes clean binary
  • Why "binary," why not just a single button
    • ohai, discussion!
    • Erik cites GMail's spam pattern as non-paternalistic/headwhack example of single-button done well
• Jen:
  • Why the new state in the Source List after source is flagged?
    • Discussion; ensuing consensus = to remove. Not enough value added past bolding and moving to top, potentially confusing as so rarely seen.
  • Why push all lightning-bolt flagged items to the top?
    • Nina clarifies that as not intended, and rather just happenstance in the prototype preso (prototype assumes two DDoS Sources are the latest)
  • Consensus: lightning bolt nice, but shd not be a Beta dependency

Next Steps

• Remove green/dude/check state of Source List item; behavior will instead be to simply mark Source as unread, as soon as Source activity is detected
  • Possibly add clarification blurb above Reply box, to a confused user in source now keyed state?
• Explore single-button option
• Dual-button preference among team seems to be Keep/Delete, buut...
  • Erik (in postmortem public Gitter post): "my sense is that there was some recognition that "keep" alone may not be sufficient, "verify" probably doesn't work, and "accept" or "approve" might be good alternatives to "keep"
    but no definite outcome here. ultimately my sense is that if it's between "keep" or "approve" or "accept" we'd all be happy to defer to your final decision"

[ninavizz]

Very rad new pattern for spam filtering/handling, just discovered in GMail (not present a few months ago). Screenshots on my GDrive.

• 4 visible "levels" of content/action
  • Super dangerous
    • Red bubble w/ stop-x icon
    • Lengthy messaging that really spells-out risks
    • No user action offered
  • Dangerous
    • Red bubble w/ stop-x icon
    • Brief messaging with TL;DR do/don't advisements
    • User action of Looks Safe offered
    • Upon clicking above, Message marked not suspicious flashed as confirmation of user action
  • Likely Spam — specific
    • Grey bubble w/ solid stop-bang icon
    • "Why is this message spam?" as H1
    • Explanation specific to what triggered flag (in my case, email in language I don't use, Czech) as body.
    • User action of Report not spam offered
    • Upon clicking above, Conversation unmarked as spam and moved to Inbox. <learn more> <undo> flashed as as confirmation of user action
  • Likely Spam — generic
    • Grey bubble w/ solid stop-bang icon
    • "Why is this message spam?" as H1
    • "It is similar to messages identified as spam in the past." as body
    • User action of Report not spam offered
    • Upon clicking above, Conversation unmarked as spam and moved to Inbox. <learn more> <undo> flashed as confirmation of user action

[ninavizz]

29 May iteration

• Invision

Feedback

• Erik feels weird about de-coupling of explanation from action items
  • Nina does not disagree, but cites desired feedback from 14 May to retain Reply/Header footprint modifications only, to ease implementation. Cites reducing the volume of stuff in the top area a user will need to look at & filter-out over 100x (anticipated message volume in such a compromised situation, as clarified by Kev).
  • We shd test!
• Things out of scope for Beta macheteScript
  • Reminder: as a hyper-edge-case thing, it's dumb to waste cycles we don't have to, on this.
  • Source List
    • All things (lightning bolt & name in red)
  • Conversation Pane
    • Bubble-bar coloring
    • Timestamp coloring
    • Second sentence in FFR explanation implies out of scope functionality
  • Reply Pane
    • "It's been 4 days since" is not yet a tracked DB item, on "Source Flagged" state.
    • Such incredible scope creep on above
  • "Key Pair Successful!" page
• "Source Flagged" state/page, in-scope as that reflects existing experience
• Second sentence implies out of scope functionality
  • Speaking to "Suspicious Activity" H1/label/flagging not necessary
• Action Items
  • Kill "Key Pair Successful!" confirmation-y page
  • Kill out-of-scope Source List and Conversation Pane bits
  • Update explanation to indicate Source will need to log in again
  • Compose content for Read More overlay
  • Edit second sentence in description of FFR to eliminate mention of deletion
  • Make all instances of the word "source" lowercase
• Looking Forward
  • Spam flagging may be a desired functionality at some point, and at that point it'd be great to examine a larger top-o-pane system akin to GMail's (in comment above)

[ninavizz]

Iteration from above, based on feedback from @eloquence

Yet to compose "Learn More" content. Thoughts?

This source came in during a surge of traffic on the server. Because of that, the server has isolated this account. The source may continue to make submissions through this account, but you will not be able to send replies. If you would like to contact them, you will need to mark the account with Looks Safe. After that, once the server detects activity from the source using the account you will be able to reply—and the source will appear in the submissions list as a new, unread submission. Learn More

[ninavizz]

Delivered spec for beta

• Zeplin screens: Flag For Reply • Awaiting Keypair
• Invision flow
• SVG for Action Weeble icon
• Reply pane content:

This source came in during a surge of traffic on the server. Because of that, they were not assigned a GPG key. The source may continue to make submissions through this account, but you will not be able to send replies. If you would like to contact this source, you will need to mark the account with Looks Safe. After that, once the source checks in again you will be able to reply. Learn More

• Help pane content: TBD, to track in Workstation Client Content Inventory + Design #17

[ninavizz]

The peanut gallery got quiet, so I'm taking that as a sign it's kosher to close this?

[eloquence]

Fine to close, but I would shorten that paragraph a bit more if possible.

Recommend changing from:

After that, once the server detects activity from the source using the account you will be able to reply—and the source will appear in the submissions list as a new, unread submission.

To:

After that, once the source checks in again, you will be able to reply.

[ninavizz]

^ Super sweet! Less technical, me likey. Done!

Follow-up question @eloquence: now that we have much more user-friendly language to speak to journalists about this, with, should we update the existing Web UI tidbits and documentation to present this feature as "Suspicious Activity Handling" vs "Flag For Reply" ?

@harlo @huertanix How much bandwidth do y'all give to Flag For Reply, in training sessions? Do y'all believe the language proposed in the screens we just approved is a marked improvement—or could be further improved?

[eloquence]

Follow-up question @eloquence: now that we have much more user-friendly language to speak to journalists about this, with, should we update the existing Web UI tidbits and documentation to present this feature as "Suspicious Activity Handling" vs "Flag For Reply" ?

Yes, but I think that can wait until the change has landed in the client, and we've done a round of validation (since it's in the punch list for the next round of user research).

[ninavizz]

Iteration from above, based on feedback from @eloquence

Yet to compose "Learn More" content. Thoughts?

This source came in during a surge of traffic on the server. Because of that, the server has isolated this account. The source may continue to make submissions through this account, but you will not be able to send replies. If you would like to contact them, you will need to mark the account with Looks Safe. After that, once the server detects activity from the source using the account you will be able to reply—and the source will appear in the submissions list as a new, unread submission. Learn More