JI Notes (2018)

Introduction

The journalist interface (JI) is the UI from which journalists download encrypted submissions, onto a "Transfer" stick. They are then opened on the SVS, Secure Viewing Station.

The below page was created by a developer, participating in a community effort to improve SD's usability in 2018.

Description

• The journalist accesses a web interface which is only accessible as a .onion service
• The web interface implements a webmail like interface, introduced in 2011
• All documents and messages are encrypted and cannot be read from the web interface, the journalists must download them, copy them to the airgap workstation that has the private key to decrypt them

The backlog, what was done and what is in progress

Over the years, a number of improvements were implemented for the journalist interface and some of them were suggested but not acted upon, or left in a draft state implementation that could be resumed. Late 2017 all issues have been labeled and issues with no labels are labeled on a weekly basis:

• journalist experience
• journalist interface

To get a better view of the current state of our work and what was accomplished in the past year, issues and pull request were sorted below. Note that the Admin interface, although part of the journalist interface from a technical point of view is not meant to be used by journalists and is left out.

Implemented workflow improvements after 2016

• Force journalists to use diceware passwords (2017)
• Add unread submission icon and select all unread button to submission view (2017)
• Fix button inconsistencies (2017)

Proposed workflow improvements

• proposing retirement of Shared Inbox (2017)
• create per user vs. per newsroom individual message starring (2016)
• Allow sources contact specific journalists (2013)
• Allow sources to choose specific destinations for their submissions (2016)
• [Submission categories] (https://github.com/freedomofpress/securedrop/issues/1170) (2015)
• 1Conversation history in the Secure Viewing Station (2016)
• Recommended 0.4 JOURNALIST UI fixes (2017)
• Assign journalists to specific sources was implemented in 2016 and withdrawn in 2017 for technical reasons
• Possible race condition when two Journalists Reply to same Source simultaneously (2017)

Usability improvements implemented after 2016

• Add globe icon in the locale dropdown for better understanding (2018)
• Css: Delete confirmation with css-only modal (2017)
• Localization (2017)
• Added expiration to sessions (2017)
• indication of which journalist is logged in (2017)
• Improve the login form usability by making input fields larger (2017)

Proposed usability improvements

• Add injectable organization name to source/journalist interface
• Change reset buttons for YubiKey/Authenticator in Journalist/Admin interface
• Show message for journalists when replies are deleted
• Downloaded submissions should reflect the logged in journalist's status

Journalist workflow improvements unrelated to the web interface

• daily email alert to journalists about submissions received in the past 24h (in progress)
• Add simple GUI updater for Tails journalist workstation (in progress)
• better documentation for a journalist working with the SVS

Problems with our current approach to the journalist interface

In the past, user interaction were designed and implemented based on private conversations and developer's intuition. This is problematic because:

• We have no trace of the conversations that led to a design decision. When the time comes to challenge the assumptions (for instance, is the shared inbox a good idea?), we risk introducing a regression. For instance, we could decide to revert the force journalists to use diceware passwords because journalists complain about these long passwords and we have no record of the user research that led to this decision.

• We do not conduct user research before implementing a change in the journalist workflow. For instance the idea periodically send email notifications to journalists lingered during a few years and that gave it some legitimity. The decision to implement it was motivated by a private conversation between a journalist new to SecureDrop and a developer, late 2017. It was a significant effort that lasted months and involved five developers. Because there was no user research, there is a chance that journalist do not actually want that change, which would be a waste of developer time.

Proposed methology

• Intercept interviews with journalists who are SecureDrop users either generic or more specific (for instance focused on the journalist interface rather than the broader SecureDrop usage).
• Compile an affinity diagram based on the interview transcripts
• Create a forum thread to figure out how to approach a desired workflow modification
• Conduct paper based or prototype experiments with users to validate the change
• Create one or more issues to discuss the implementation of a desired workflow change
• Implement the issues