Skip to content

Qubes Journalist Workstation

Jump to bottom
Nina Eleanor Alter edited this page Jun 12, 2022 · 145 revisions

Problem

SecureDrop's current web-based Journalist experience is cumbersome and time-intensive.

Multi-device (6!) experience is confusing and time-involved. Dependence on, Tails (a live USB operating system for USB sticks) hampers host orgs with manual maintenence burdens, and end-users with Tails usability issues—which have proven to not be trivial—despite respect and immense gratitude from all users for best-in-breed security benefits.

Read More Time-on-task for each new check of SD by journalists within smaller news orgs imposes workflow burden that is speculated to influence source disengagement via subsequent infrequency of use by journalists; time-on-task for all users in newsrooms of all sizes, feels excessive. The current architecture's encryption needs additionally make it impossible for journalists to immediately access relevant metadata, which is hypothesized to force the creation a manual-spreadsheet "log" to overcome.

SecureDrop in its current form

Solution

Unified client experience in Qubes OS that will require only one laptop—no separate Live USB drives.

Through use of the Qubes OS and its Virtual Machine goodness, today's dependence on multiple hardware touchpoints and software context-shifts will be eliminated to offer a more natural correspondence experience for our non-technical end users. Should this project successfully deploy, it is desired for today's Web UI for journalists to be phased-out ~2021.

Read More Qubes OS overcomes today's hardware/software security requirements via multiple VMs on one laptop. Within a VM journalists will be able browse, read, and manage fully decrypted Source submissions in a client app that matches common mental models for messaging.

Documents will be a click away from being viewed in a Qubes' Dispoable VM window, and the "Open Document" interaction pattern will seamlessly decrypt docs—additionally relieving that cognitive burden from users. Today's web UI will continue to exist, through at least the end of 2020. Should users desire to keep maintaining a spreadsheet log, that can also be done through a different VM on the same laptop, and with cut-and-paste.

SecureDrop using the Qubes OS Workstation

Related project pages

  • SecureDrop Client (the app itself) repo
    • Being built in QT; incredibly rough, and slowly maturing from "proof of concept" for an Alpha phase security audit to a usable app for deployment in Q3-2019's beta pilot.
  • Qubes Workstation repo
    • Qubes-based SecureDrop Journalist Workstation environment for the above QT app to run on.
    • This is the code for the integration of the client with Qubes OS, including with the other required VMs.
  • UxR Call for Participation!
    • Securedrop.org webpage with seeder-survey to introduce the Workstation project and solicit volunteer research participants from the journalism community, who are not existing SecureDrop users.
    • Sharing through professional orgs supporting Investigative Journalists, and our friends at OpenNews.

Timeline

  • Feb 2018: Ideation & research began(ish)
  • August 2018: Preliminary research
  • September 2018: Alpha 0.1 UX & QT build begun
  • October 2018: Design & RITE testing sprints begin
  • November 2018: Alpha released & submitted for a security audit
    • Passed with flying colors!
  • Targeting...
    • Feb 2020: Pilot testing to begin with select customers
    • Q4-2020(?): GA Release, should pilot go smoothly

Production Outputs + Feature Prototypes

  • Icons & Artwork as SVGs
  • Dummy Content
  • Messages & Text Strings Audit
    • DRAFT Source-of-truth doc for what language should be used where; examines existing language that may already be in the build, against what's recommended against evidence created from user testing.
  • Gherkin Sandbox
    • Where spec'ing in Gherkin is worked out, before cutting-and-pasting final Story content into relevant GitHub Issue w/in the Client repo. No, this author is not a Gherkin rockstar—so any/all critique to make things easier for y'all, is welcome! :)
Export Functionality

.

Currently there are 2 solutions for Export; our preferred Briefcase flow, and then the more piecemeal file-by-file implementation more likely to happen for Beta. Should the latter be pursued, auto-attaching devices to the [SD-workstation] VM might be an option. Briefcase is our GA preference, tho, as we anticipate a multi-file experience akin to a shopping cart to better meet user needs, than the tedium of navigating menus/dialogs for each exported file.

» File-By-File Export ...click link to view prototype.

  • General
    • This is a VERY old prototype, and its size was optimized to facilitate remote user testing
    • The content on the overlay-guide panel was iterated on 3x, following clear feedback from users in testing.
      • The overlay panel itself may be styled a touch different to align it with the visual design, but the instructional graphics and written content would remain the same.
      • When you see a bright yellow rectangle with a pink arrow over it, click on it—and you will see animation(s) fudged.
  • Begin: Within benign artichoke...
  • Click: "Export" on file wrapper.jpg
    • Prototype assumes user has not already attached a device, and that Qubes cannot auto-attach devices to disp-VMs.
    • If in fact Qubes will be able to attach devices automagically, then the dialog on this screen will appear w/o the attachment messaging bubble(s) in the background.
  • Click: "Show Me How" (assuming you want to endeavor the not-automatic-attachment flow)
    • Follow instructions
    • Note: It has been noted that the instructions incorrectly advise the user must click on the "+" when in fact the whole bar is acceptable to get the same results. Instructions wd be updated, accordingly.
  • Click: Qubes' attachment widget
  • Click: Sys-USB 2-3: SAFE USB-04
  • Click: sd-workstation (once or twice—until the yellow box w/ pink circle appears)
  • Click: yellow box w/ pink circle, 'till it disappears
    • Leave "Encryption" option unchecked (because that functionality will be reserved for Qubes FileManager in preferred Briefcase flow) and click "Export"
    • Click through yellow rectangle arrows, to see UI messaging to user as export happens

User Research Informing Project

Archived Design Explorations

note: Effective 2019 Feb, all ongoing ux tasks are being tracked within this repo's Issues.

See Workstation Issues, or visit the UX Meetings page to see archived notes on past design reviews, or to see what's on the agenda for (and/or possibly RSVP to?) the next design review!

Single-Screen Wireframes
MVP Client Framework
  • Client GUI framework for Alpha release
    • Minimization of current framework for Beta, shown in the rest of the wireframes
    • Omits the far-left column to expedite getting Alpha built.
Conversation Threading w/ ID Badges
  • Journalist IDs will never be shown (as of now) to Sources; in the Client UI however, they will be shown to the Newsroom users.
  • ID badge currently consists of a colored square (one of TBD set rotating colors) and the first letter of the identified user's username.
  • If/when first/last names of Journalists are scoped-in to the Web UI (and thus the Client UI), this letter will be for the Journalist's first name.
"Action Required" Toast Directive: Note: edge-case shown in this particular screen.
  • Errors without security implications should have apouty-face icon.
  • The error shown in the linked PNG is a unique instance, when the system failed to send a message in the prior session; so, it gets the sendfail artwork.
Sign In from working Offline.
  • Not a modal.
  • Ideally pane would drop-down from top, but it could also open in the middle of the screen *shrugs*.
  • If user clicks area outside pane, pane should go away #nomodes.
Sign In Error
  • Graphical treatment replaces "Sign In" H1's footprint w/in window.
  • Uses pouty-face icon to signify non-threatening user error.
Dialog: Opening New Disposable VM
  • Opens when a user chooses to view a document or opts to view help text
  • Automatically closes when Disposable VM opens w/ target content
  • Note contextual text at end of message; shd match activity
Clickable interaction patterns, by task/functionality
Composing & Sending Reply.
  • Lots of time-based things and activity messaging in this one.
  • Alternate treatment shown for activity messaging that I'm leaning more in favor of, then prior pattern of re-using the footprint occupied by the "Refresh" button and timestamp.
    • Thoughts, in Gitter?
  • Should a Reply fail to transmit for any reason, this is a prior prototype done to rough-out just those things.
 01 Nov 2018
Deletion of Source Account, Messages & Files. Click-through directions and other details on intro screen for prototype. 28 Oct 2018
Activity status (upper-left of screen) & Download/Decrypt messaging. Click desktop icon in opening screen, then click signin button; then watch. Click on 6.4mb file to see file download/decrypt flow. No further action on that file is built into this prototype. 26 Oct 2018
Export With & Without Drive Attached.
  • Prototype simulates Client sniffing USB attached to VM in Qubes. On Step-4 of the prototype, pause to see automagic activity messaging in upper-left (currently timed at ~2.5secs in my prototype).
  • If a drive is attached at the time the user clicks "export", this dialog should appear.
  • If the user checked the "Don't show next time" thingy on the dialog last time, this is the view/functionality to show them now.
  • "Save With Encryption" flow is also built-in to this prototype.
    • It's a little messy at the end with things moving around, but the core functionality is there.
    • Select Mathieu Dandernault and Hayley Wickenheiser in prototype, then click "Save."
    • See the lovely activity messaging fly along time top!
 26 Oct 2018

30 January

Visual Design Things

  • First live-ish prototype-ish; just clicking around the first 4 Source Accounts at the top, works.
  • It's a nice way to see the current VisDe direction, with some interactivity. This will continue to get built-out and iterated upon for showing VisDe, going forward.

17 January

Visual Design Things

  • Reviewed progress in UX Meeting.
  • Presented:
    • David Bowie
      • Berry/blue color schema, with dark bar at top
      • Larger-scale hexagons pattern in background
      • Cyan error messaging contrast color
    • Elton John
      • Electric blue & purple color schema, with light bar at top
      • Smaller-scale hexagons pattern in background
      • Magenta error messaging contrast color
    • LogJam
      • Shows Tor "button" in upper-right, and a really bad way to present multi-error messaging
  • Notes here

21 December

Visual Design Things A few iterations on what was presented last week, and next-steps discussion.

Notes on this round's mockups:
  • Bub-01, Bub-02, and StarCol-01 all show different stylistic approaches to doing convo bubbles
  • Bub-03 shows the direction from Bub-02 extended to factor-in files
  • ClickThru3 shows what messaging to Sources and internal messaging among just the newsroom team, could look like as both visible in the same window. Also demonstrates option of showing all journalist messages in a solid bubble, and working with the ux paradigm of "Sender = white, Recipient = dark" for bubble coloration.
  • Things changed since last review: Interactive starring in its own column on the left, added Logo rotated
  • LouisVuitton-ish patterning of messages pane, removed

13 December

Visual Design: First Pass Rough mockups approaching look/feel considerations. These include use of color, use of typography, graphic styling, and general use of icons, in the client... as well as some Qubes things. TEAM FEEDBACK from review in UX meeting

  • Nina's 1st Pass Mockups
    • Two rough "Directions" to be refined further.
    • Does one or the other appeal to you more, and why?
    • What is working and what is not working, in one or the other?
  • XFCE theme screencaps
  • Screencaps of analogous apps
    • Some of these are mockups of imaginary apps that other designers did and uploaded to Behance, some are of existing apps.
    • WhatsApp and Signal appear to be the most frequently used in place of SD, at newsrooms, for Source communication—so it's important to consider their aesthetics and interaction patterns in the choices we make with our client.
    • Do some of these resonate with you? Which ones? Would you like the client to take inspiration from some? Let me know!

What do you guys want?

  • Do any of the analogous messaging app designs in the analogous directory resonate with what you'd like to see for the SecureDrop Client?
  • Dark, Light, don't matter?

Brand considerations:

  • Do we want to tout the SecureDrop brand?
  • Would showing the brand present security risks?
  • Would presenting the brand simply be obnoxious?
  • Would it be helpful to users to boldly remind them which app they're using with the SD brand?

Color considerations:

  • Legibility to live humans staring at content on a bright monitor
  • Legibility to snooping cameras seeking to capture information from a digital screen
  • What's simply pleasing or soothing?
  • On-brand without looking corporate-blue?

In testing, journalists expressed:

  • An excitement for something sleek, clean, and modern
  • An intereest in seeing encryption/decryption things made visible & easy
  • A desire for features that facilitate team collaboration & workflow
    • Who's seen what?
    • Who's replied to which Sources?
    • Private messaging among newsroom folks within Source views, desirable
  • A general disdain for ever throwing things away; so, anything to help sort signal from noise, good.
    • Maybe starring isn't so bad after all?
  • Concerns with exposing real names and/or photos to Sources

Qubes things:

VM Window Styling

  • Working off "Flat" XFCE theme with thinned sides & bottom edges
    • No window bevels, outlines, or overlaid gradients
    • No black dropshadows; each colorway should have its own darkened color dropshadow for text and for the window itself.
    • No rounded corners... as 2 rounded corners at the top and two square corners at the bottom appears dated, and 4 rounded corners would look wonky in the Disp-VM viewer apps.
    • Kill the far-left and 4th-right button at the top of the windows, as they'll be more likely to cause confusion than provide beneficial utility.

Desktop(s)

  • Something with texture that's not distracting (so, a nature image) will help visually boost the VM windows up from the desktop—something that noticeably does not happen with the flat-color desktops.
  • The exploding-Qubes logo thing is darn nifty, but too similar to the SecureDrop logo

27 Oct

  • Quickie Prototype to demonstrate functionality and notifications involved in a send-fail message.

A likely edge-case, but still something that seems very important to get users on asap upon signing in... but without the "OMGWTF!" anxiety error-bangs and warnings could promote, in the security-sensitive environment. All semiotics and visual design treatments (UI specifics) are WIPs. This is just to demonstrate core expected behaviors, and where things should appear in the UI.

24 Oct: 2.2 UxR sprint

  • 2 users, 2 newsrooms
  • Invision prototype that demonstrates time-based activity messages and download/decryption
    • Click desktop icon
    • Click sign-in button
    • Observe: activity messaging in top-left of screen, and contextually where relevant
    • Click: Benign Artichoke's 6.4mb file, to see download/decrypt. Entire bar is supposed to be clickable, at the start.
  • Invision prototype that demonstrates view and export flows
    • Benign Artichoke's 6.4mb file may be viewed. Window currently only close'able via VM window's "x" button
    • Same file may be exported.
      • Click on the graphic of the fly-out menu in the wizard, to fudge the system automatically detecting an attached drive.
      • If you click "Next" that assumes the user failed at attaching their drive.

17 Oct: 2.2 UxR sprint

  • 1 user, 1 newsroom
    • More participants TBD
  • Invision prototype
    • Note: at end of discussion guide below, nav-paths are outlined.
    • Primary updates to this prototype were addition of activity messaging and attach-USB wizard(ish)
  • Updated discussion guide

Prototype to be updated from the 2.1 UxR sprint as follows:

  • Add toast messaging for opening disp-VMs and delete
  • Refinements to Attach USB wizard(ish), including pings from OS wrt attached drive status
  • Update ordering-by-chronology and mix-in responded-to messages in Beta screen
  • Add "Seen By" in Beta screen
  • Update available "Export" window functionality
  • Add Refresh-bar messaging wrt downloading/decrypting, and grey bars over preview text while things decrypt

Running Themes To Address

  • Problem: User expectations management remains incomplete
    • Iterative Solution: Add more toast messages where appropriate—confirm delete action, and what was deleted; confirm downloaded files?; when opening disposable VMs (see above), etc.
  • Problem: Users confused with regards to what is encrypted/decrypted and downloaded, and when.
    • Iterative Solution: Update "Refresh" text throughout processes to better communicate to users what's going on and when
      • When downloading messages from server
      • When decrypting messages
      • Possibly to tweak "Last Refresh" details to include decryption/download language
    • Iterative Solution: To discuss with Jen, timing/lag wrt decrypting message text upon load—if it makes sense, will add grey-bars indicating activity where preview text should be in Sources List pane.
  • Problem: Users confused by many things upon entering prototype; "I see read/unread but don't remember having seen those Sources before," when do I take files to the SVS, etc.
    • Iterative Solution: Update framing of prototype/session in script.

16 Oct: Findings & Action Items from 2.1 UxR sprint (Oct 10th, 11th, and 15th)

  • 5 users, 3 newsrooms
  • Focus on Online/Offline, Sign In, and overall comprehension of what's being looked at
  • Export & Save functionality, introduced with last participant
  • Most recent Invision prototype tested against (updated through 2.1 sprint 3x w/ minor tweeks)
  • Findings Report (3pg GDoc)
2.1 UxR Sprint: Findings & Action Items.

11 Oct: 2.1 UxR sprint, continued

  • 2 users, same newsroom
  • Invision prototype note: linked prototype includes file viewing/exporting functionality that was not shown or reviewed in research sessions
    • Remove re-authentication when a user signs-in, goes offline, then goes back online
    • Updated read/unread pattern to load first-view upon sign-in with selected message being the most recent "Read," with all unreads shown above
    • Tweaked to language on files in all states
    • Tweaked language on offline/online banner to improve comprehension and actionability

10 Oct: Alpha Build Delivery

  • Woo! Meeting between Jen, Nicholas, and Erik, to coordinate bridging wireframes into code
  • Nina's mockup to eliminate far-left column on wireframes to simplify Alpha GUI to meet MVP reqs for auditors
  • GDoc with dummy content, for prototypes and live build

10 Oct: 2.1 UxR sprint

  • Sprint conducted across 3 days of testing
  • Invision prototype for testing today with 2 users from 2 newsrooms
    • Online/Offline redone to offer more clarity to users
    • Other assorted updates viewable in "Findings and Action Items" from prior session

01 Oct: 2nd Round of UxR Testing Begins

  • 2-4 RITE studies will be conducted through October and early November. More about RITE testing.
    • Testing segmented into "sprints" numbered similarly to software releases, to group participants viewing similar features/functionality to facilitate iteration and reporting.
  • Invision prototype for the 2.0 UxR sprint, tested with 2 users from 2 newsrooms.
1st Iteration: Findings & Action Items

-

Hi/lo observations from testing, below. Detailed findings are in the linked GDoc; fully anonymized, and open for comments.

Online/Offline

  • Not clear. Most significant actionable issue between both participants.
  • Subtlety in colors, italicization, etc., totally washed-over both users' heads
  • Combined with confusion around encryption/decryption status of shown content, both emerged in parallel as highest priorities for next iteration.
  • Seeing unread messages in Offline mode, confusing—as workflows unlikely to reproduce in reality.
  • Next Iteration Action(s):
    • 2-state Offline/Online banner w/ "Go Online" and "Last Refresh" and a hard-refresh button, include
    • Interstitial sign-in pane between clicking the app icon and initial client view; Erik's ASCI sketch for reference
    • Remove "Unread" messages from initial view in Offline mode

General

  • Need messaging to confirm successful action completion, and where actions took place (local, server, both)
  • "Conversations" concept confusing (Note: bucket nested within Sources list, to separate newsroom-reciprocated correspondence from un-reciprocated submissions)
  • Timestamp(s) in messaging pane too small/pale
  • Discoverability issues with "Reply To" block
  • Pointers on message bubbles, confusing
  • Language: "Export" more functionally clear than "Save"
  • Attached file things generally clear, some bumps to smooth-out
  • Idea validated that "Pick things to delete" as a dropdown item on a single Source, would be useful.
  • Next Iteration Action(s):
    • Include toast messaging—initially, for "Delete" flow, and with explicit messaging
    • Update "Delete Source" language to "Delete Account"
    • Remove "Conversations" bucket (currently nested within Source's list)
    • Simplify read/unread paradigm, with removed "offline" state and "Conversations"
    • Change all uses of "Save" to "Export"
    • Add Download icon, and omit word "Decrypt" in initial view—but note decryption happening in-progress.
    • Include "Latest Action" verbiage on messaging pane timestamp, and improve visible discovery
    • Include big paper-airplane-like button in "Reply To" field
    • Kill the bubble pointers, make less bubbly-looking

27 Sept: Quickie team walkthrough of the past week's updates

  • Download/Save/View things updated, per Erik convo
  • Avatars removed per Jen/Erik citations of scope limitations (likely to carry into Beta)
  • Beta screen kept in first slide for reference, but otherwise this is the beginning of the split between Alpha-only and Beta-only prototypes.
  • Remember, mind the pink arrows at the top of this not-fully-clickable prototype. To view particulars re: file-download/save states, hot spots are all over that little area. Click on any area of the screen, and hot-spots will show in blue for where you can click to get somewhere. :)
Feedback Highlights
  • (Jen) Option to delete individual messages or files?
    • Group discussion followed, consensus that "messages" should not get cluttered with an individual-delete option, but that files should.
  • NOTE: Icons in the downloaded file are placeholders-only... finding the right icons.
  • Team love for the Magritte-inspired Admin icon; perhaps users will share that love? 🗡
  • Team love for the loading animation. No comment on the proposed-logic of heads-up'ing users to long download times for files over 50mb
  • Michael: How about different colors or canned-illustrations/emojis to delineate different users in Source list?
    • Convo redirects to how that could be useful for journalists to distinguish among one another.
    • Nina created these journalist weebles a coupla years ago; could adapt into a series of rotating avatar placeholders for Beta, if time. Wd need to know how many journalists are typically in each SD news org, tho, and design a few more than what anticipated max is.

25 Sept: Implement follow-up items and distinctions between Alpha and Beta functionality

Feedback Highlights
  • Avatar pics not in scope for Alpha, maaybe for Beta; wd create dependency on showing in Source interface, too.
  • For user-account level functionality, "Sign Out" is all, for now. To change passwords, users will need to login to the web interface... so, that should at least get mentioned.
  • Docs need to download and decrypt from the SVS first, then may be viewable
    • Simply the download can be a slow process, because of all the security measures. 100mb files can take up to an hour.
    • "View All" would crash the machine, as that'd force it to open multiple disposable VMs at once... :)
  • Download, Export, Save, View, etc. flow/things
    • "Export" means "Save," which will also prompt a dialog to ask a user if they want to save to another VM or to insert a USB drive... which makes no sense. Erik looking into how to circumvent that.
  • "Show/Hide" widget in password fields, pls to have
  • Currently Sources cannot submit multiple files; so rule would need to exist to show files together, if submitted w/in an hour of each other (or something).
  • Team read/unread device, Erik really not into the color bars; for testing, let's at least transition to "Seen By"

13 Sept: Research & Design Review

Action Items
Next Steps
  1. Coordinate with Nick on QT GUI things
  2. Put new stories into spreadsheet, as they correspond with the below feature/functionality things
  3. Content Audit
    • Shd be done of Source interface, asap; too much conflicting terminology
    • Have ready for Thursday's UX meeting, that Anxhelo has RSVP'd to via Ellio
  4. Wireframes: split into 2 separate directions
    • "Post Alpha" for exploring all the neat ideas
      • Keep all the things shown today, and as time permits iterate on neat things; otherwise, not a priority
    • 0.1 Alpha, to reflect what is needed for the Auditor release.
      • Strip all the not-to-include things, and focus on this for iteration and dev.
  5. Wireframe iterations (spelled-out, below)
  6. Wireframe advanced flows for 0.1 Alpha
    • What does opening a doc look like?
    • What does exporting a document look like?
    • What do delete flows look like?
    • Modals: will we ever force users into a modal?
      • Probably, yes, to "Destroy" but nothing else?
  7. Qubes stuff: not an immediate priority
    • Yes, meeting with their team at some point wd be great
    • Should prepare things for said meeting
    • Explore filing UX issues in GitHub?
      • Who's David? Jen said he'd done this and found success
  8. GUI/VisDe: not an immediate priority, but some guidance to/with Nick is

Interface/feature iteration decisions

  • Assume 1 laptop, many users, for now; team has research to do, yet to decide
  • Alpha MUST
    • Login
    • Trash concept
    • Offline mode (Should)
    • Star (grr!)
    • Export functionality
    • Multi-select (should or must)
  • Alpha WON'T
    • Search concept (note: not even search by username?)
    • "Reset Source"
    • Team read/unread (seen by)
    • Que (vs send) concept (we should send real-time, no need to sync)
    • Onion share
    • No response to Source in offline mode; just show "must be online to compose response" message (or keep blank, or something)
    • Excerpt length widget
    • Merge feature too complicated for first release
  • No PIN at offline login
    • Possibly username, ok
  • "Team Read/Unread" for MVP
    • "Seen By" will be useful; team read/unread bar, shd be tested
  • "Trash/Destroy" functionality for 0.1 Alpha
    • Will put super-user role and duration-to-destroy preference setting for Admins as "Could" for 0.1 Alpha, as command-line can do that?
  • Tagging and Source or task assignment a-la GitHub
    • Not action-items for now, shelved for later iteration
  • Private notes among journalists or a common "Scratchpad"
    • Will explore a very rudimentary "Newsroom Stratchpad" for 0.1 Alpha
    • Robust chat-like stuff with @user notifications, good to explore for post-MVP
    • Middle-ground option, good to explore for MVP
Feedback Notes

...from morning UX Meeting

...from afternoon FOP Team Preso

  • Qubes OS change proposals
    • Grub menu—Erik clarifies it should only take 4 seconds to boot.
    • Nina requests all things not branded "Qubes" to be hidden—and if not, to be presented in a more expected fashion to users (so visually, less afterhought-y)
      • Note: Issue is not with aesthetics, issue is with confusing users not accustomed to working with experimental/open-source projects intended for dev audiences. OMGWTF fatigue needs to be reduced as much as possible, given security-sensitive nature of work.
    • Ideally, if Grub to exist on user machine, should be hidden (users will not understand what Grub is, even if it takes only 4seconds)
    • Erik: We can propose, unlikely Qubes team will implement most
    • PIN & Password things
      • Kill PIN, doesn't seem to offer much value
        • Nina: Put-in, to at least include in a use log who's been viewing the SD offline
        • Erik: Users could at least enter their username, there? Yet Another PIN feels excessive (Jen agrees on the latter).
        • Erik adds that any user who loggs into this machine at this point, has full administrative access (NA: really?!)
        • N&E to take offline
        • Read/Unread
          • Erik asks about vertical bar "intended to be a counter?"
            • Counter could be whom *exactly* has viewed this
            • Erik: seeing whom specifically has read something, could offer legit more value than fuzzy-logic of bar brightness? Re: "Seen By" pattern such as in Facebook.
            • Trash flow
              • Erik introduces, qualifies concept as shown is a "shared trash"
              • Jen says it makes sense and seems "very useful," especially for distributed teams
              • Mikael or Kev mentions deletion policy during sync'ing; an implementation detail
              • Jen: Auto-delete after 14 days a good call
              • Erik: As I recall, spreadsheets used to track who's checked SD and who uses with what submission… benefits of additional logging and what may be missing from this set of wireframes? Here you see view of what everyone's saying—makes it much easier to see what everyone's working on.
            • Mikael or Kev—interested in "Editor" role, asks if it implies assignment editor role to assign journalists to pursue sources
              • Nina: Clarifies "Editor" as simply a super-user permissioning thing to restrict access to whom can immediately Destroy (vs trash) things, create new users, etc.
              • Mikael or Kev: ok, that sounds cool
              • Erik: It'd be interesting to think of like a GitHub type flow to assign responsibility to Sources, assign Triaging responsibility, etc., for future stuff.
              • Nina: mentions tagging as interesting opportunity explored some time ago; explains value as outlined in 2yr/ago wireframes.
              • Jen: Yep, Tags could be useful
            • Jen: Spreadsheet also used to track who is working on stories that have not onboarded to SD but also working on documents, and agrees that "Seen By" is also useful. Tags could also be useful.
              • Jen: Private notes among Journalists—like stickies on shared meatspace documents—could also be useful/fun to think about. "I shared this with Charles in the newsroom, he'll be looking at them?
              • Mikael or Kev: Like a website's chat interface between different journalists?
              • Yeah, that's like what it could look like.
              • Conor: Even something as simple as a scratch-pad that anybody could post to and identifies username. Something that all journalists have read/write or append-only access to. Could accommodate (same spreadsheet workflow) w/o jarring security reqs
              • Erik: A per-device notepad that's in this client could be valuable as a first feature.
              • Nina: Cites customer support-chat flyout-tab chat pane as an option?
            • Erik: Terminology audit in the Source interface would be valuable; too many concepts/functionality bits referenced by different language across U
            • Josh: I'm interested in the research, and in the Qubes usability stuff. Qubes was created for super technical people, and we're creating something here for non-technical users.
              • Erik: We can remove entire boot menu from Qubes because it was just on my machine
              • We should set-up mtng w/ Qubes folks. I only expect that a few might get done, but that'd be better than zero. Maybe there's an existing library that can bundle-up notifications? What easy wins might there be, what can be put into a long-term backlog?
              • Jen: David filed many UX issues to date for Qubes, and that could also be a path
              • Erik: We could get you (Nina) a Qubes workstation to play with?

            Follow-up 1:1 with Erik:

            • FYI: wireframes "look" like a webapp, not QT app
              • Discussed w/ Nick in AM meeting
              • QT looks more like Windows 3.1; good to sync w/ Nick to familiarize myself more with OEM GUI offerings with QT toolkit.
              • Things to "Must" for Alpha
                • Login
                • Trash concept
                • Offline mode (Should)
                • Star (grr!)
                • Export functionality
                • Multi-select (should or must)
              • Things to remove for Alpha
                • Search concept (note: not even search by username?)
                • "Reset Source"
                • Team read/unread (seen by)
                • Que (vs send) concept (we should send real-time, no need to sync)
                • Onion share
                • No response to Source in offline mode; just show "must be online to compose response" message (or keep blank, or something)
                • Excerpt length widget
                • Merge feature too complicated for first release
              • Decision for 0.1 Alpha on 1UPL vs MUPL tbd; technical research to do
                • Assume that for now it will be more than one user per laptop
                • For offline mode don't show anything user specific?
              • Me: Would it help to track all these features on the Stories spreadsheet?
                • Erik: Sure, that'd be great—just let's
                • As you have time available we should wireframe advanced functionality
              • Flows good to wireframe next:
                • What does opening a doc look like?
                • What does exporting a document look like?
                • What do delete flows look like?
                • Modals: will we ever force users into a modal?
                  • Probably, yes, to "Destroy" but nothing else?
              • Styling of QT styles "nice to have" for auditor, but generally irrelevant to them—usability affordances, excepted.
                • If we have time before then, it'd be great to do styles—but they're so not a priority.

11 Sept: Qubes Workflow Review

Nina/Erik quickie call to validate Nina's takeaway assumptions from last week's intro to Qubes and the Alpha vision.

Feedback Notes

Feedback Highlights:

  • Co-branding = nope; Source interface only, contextually relevant there
  • Discussion re: user password management. To avoid "Post-It On Monitor" user hacks to poor usability w/ stringent security mandates, I'd like to recommend a password manager and 1-2 analog alternatives (and why they're recommended) as part of the install and/or training documentation.
  • Step #3
    • Window branding is Qubes (Erik sent screenshot); password characters show as bullets
    • 1 text entry field, a progress bar, no button.
    • Some confusing text as attribution to Qubes tech partner; wd like to suggest a recommendation for them to consider as an alternative, citing prob/solution rationale.
    • Boot/progress bar continues regardless of when user does Auth-01
  • Step #4
    • No actual button, user expected to just hit return. Would also like to include recommended messaging or button option in communication with Qubes team.
    • Nope, Qubes has been booting the whole time
  • Step #5
    • Erik timed, ~15sec boot time
    • Tasks should all be invisible on properly setup machine
  • Step #6
    • Also Qubes branded dialog; password characters shown as bullets
    • No 2FA
  • Step #8
    • "No VMs Running" not entirely true, but to the technically-oblivious details unimportant
    • Yep, SD icon on desktop can automagically execute expected SD load steps
    • Step #9; discussion ensued re: issues around multi-user/single-laptop client and assumptions around how a "Load client with decrypted data from last session" could work. Also discussed issues wrt needing internet connectivity to do SD app authentication; current assumption from Erik/Jen = flow would only have app needing to auth with server to download/decrypt. Can't store SD server password, locally. Tabled discussion for later, Erik to followup with Jen... meanwhile, Nina wireframing how a few different options can work, in click-thrus to review on Thursday.

06 Sept: Wireframes Review

Nina presented this PDF and reviewed in person with Eric.

Assumptions:

  • Icons all rough/PoC only; no visual-design (typography, color, iconography) reflected in wireframes.
  • Wireframes outline ideas for envisioned functional experience; not yet broken-out by release feasibility (so yes, assuming a few things shown are not MVP priority).
  • Decryption/Encryption specifics and launch flow, unknown at time of drafting.
  • Inclusion of taggging functionality in today or the future, unknown (was in discussion when I was last involved in the project in 2017).
Feedback Highlights
  • _Triage_ a nice idea, but likely a cognitive burden for 90% of newsroom customers who don't have the volume to merit its value.
  • _Trash_ flow interesting, possible solution to issues already in discussion re: cold storage.
  • Read/Unread bolding paradigm potentially confusing if applied to full team vs individual user
  • Timestamp only on latest correspondence, as security measure
  • Things needing consideration: server-sync, offline/online viewing, initial Qubes decryption flow.
  • Erik shares hypothesis that today's spreadsheet logs a likely process hack to assist journalists track who communicated about what, given inability to see anything from Sources today via decryption/encryption flows; interested to probe on in further research.

Team generated docs to track feature prioritization and general discussion/ideation:

Who Uses SecureDrop?
Learn about SecureDrop's users!

Design

Contributors

Learn!

User Research

Et cetera

Clone this wiki locally