Qubes Journalist Workstation

Nina Eleanor Alter edited this page Dec 12, 2018 · 120 revisions


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 burdens 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.


Unified client-based GUI 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, the expectation is that today's Journalist web UI will continue to exist, through at least the end of 2019.

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 2019. 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.

See the latest UX prototype!

  • Links at the top of this discussion guide page, and click-path w/ available functionality is described towards the end of the above GDoc
  • Link above updated 11 Dec 2018

Related project pages

  • SecureDrop Client (the app itself) Repo
    • Being built in QT; currently in "GUI proof of concept" phase, though quickly moving into something more polished, per the below schedule.
  • Qubes Workstation Repo
    • Qubes-based SecureDrop Journalist Workstation environment for submission handling.
    • 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 journalist volunteer research participants.
    • Sharing through professional orgs supporting Investigative Journalists, and our friends at OpenNews.


  • 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
  • Targeting...
    • Mid November: Alpha Code freeze, to deploy workstation for auditor review
    • Feb 2019: Pilot testing to begin with select customers
    • June(ish) 2019: 1.0 Beta release

Production UX Outputs

  • 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! :)

User Research Informing Project

Ongoing Design Things

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

03 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.

  • XFCE theme screencaps
  • Nina's 1st Pass Mockups
  • 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.
Approach - tbd -

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.


  • 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


  • 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.


  • 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:




Et cetera

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.