Design of securedrop-client UI

[redshiftzero]

This a brainstorming issue for ideas for the design of the securedrop-client program (a broader view is described in #88) that will have a UI for journalist users of the Qubes Workstation.

Conversation view

One approach that might be intuitive for users is a conversation based view like Signal Desktop (Image from the Signal Blog):

where the left panel would show the sources, and eventually group conversations (one source with n journalists or n journalists discussing some topic without a source involved). The right panel would show messages and replies ordered by time, with submissions displayed in a similar manner as attachments in Signal Desktop (e.g. with icons that map to the file extension). Clicking on the submission file would open the file in the disposable VM.

File view

Another approach is a file-based view, basically a simplified File Manager, which again has sources in a panel on the left, and on the right the files associated with that source, including the messages and replies to the source.

These ideas (and many more other possible designs) would lend themselves well to early prototype user testing and feedback like this (kudos to @ei8fdb for sharing this link with me) that can occur with few prerequisites (e.g. you don't need a working Qubes Workstation to do the user testing).

[redshiftzero]

Related to #102 (for debate in UX meeting) but not actually a prototype. This is one view of what the SecureDrop client could eventually look like (if inspired by a generic messaging client):

Everything is up for debate, currently just brainstorming. Dropping some implementation thoughts over in #88

[eloquence]

Thanks for the gorgeous mock-up, @redshiftzero, and for pushing the envelope on what a client could look like.

The kinds of questions the IM-style workflow raises for me include:

• How central is "file organization" to the SecureDrop workflow, and to what extent should it be directly supported by the client, as opposed to delegated to a file manager?

• How suitable is this workflow to a situation where only 1 out of 10 (or, as our research indicates, in some cases 1 out of 100) submissions are plausible/worthwhile? How does deletion work in this model? Does it effectively remove a source from view for all journalists?

• Do we need to block certain actions on "sync", to avoid journalists stepping on each others' feet (and if deletion is system-wide, to avoid a situation where a user responds to a deleted source)?

• How important is it to minimize retention on the server? If it's important to delete things on the server frequently, how can we ensure that these deletions don't get in the way of reliable one-to-many communication?

It seems like the interaction modeled here would be very convenient after a triage/1:n assignment workflow. That workflow might be similar to what's shown here but have a dedicated UI to quickly assess whether a source is worthwhile.

Just some early thoughts, definitely looking forward to discussing with our users. :)

[heartsucker]

Leaving some notes here after a chat with @redshiftzero and @kushaldas today.

1. Force syncing is a bad idea. Users may not want to have files removed.
2. Tagging items as "keep" is insufficient if a sync happens after a long period of inactivity. A user could sign in after months off and lose data.
3. Delete / trash is non-intuitive because a user moving a local file to the trash would delete it for other users (by DELETE-ing via the API). Delete would need a "delete for me" and "delete for everyone" option, perhaps.
4. Having local storage via SQLite / FS is a must IMO. Tor is spotty and client will need to retry many times perhaps. Client startup time will be unacceptably slow without a local cache to start.

[huertanix]

@heartsucker on these points:

1. This makes sense to me, although if the default changes to automatically download everything, I wonder if there'd be any preference towards having a delete-for-everyone-including-their-local-copy mechanism versus having each journalist have to remember to log in and delete their copy of a file.

2. I agree, and in my experience there are definitely cases where a journalist won't log in outside of a fixed monthly/weekly/etc time frame or in some cases not log in for months at a time.

3. There should be some way to inform the user of what availability state a file is in. A download glyph is used by Apple's iTunes to show whether a film/song/etc that is available for an account hasn't been downloaded locally, we may be able to do something similar.

4. Journalists already loathe how slow everything is, so anything that helps shave off a bit of time is a welcome improvement in usability.

[redshiftzero]

How important is it to minimize retention on the server? If it's important to delete things on the server frequently, how can we ensure that these deletions don't get in the way of reliable one-to-many communication?

I think when it's clear that sources are drive-by then they should be deleted from the server once the documents are handled. In addition, I think that sites will want to delete large submissions to free up disk space. Otherwise, I don't think there's a major issue in keeping sources around. Indeed, removing them entirely will prevent them from being to log in again with their existing codename.

To the other points re: the proper delete/sync behavior, I think journalists do expect that if they have the rights to delete, and they delete a message or source, that this is reflected everywhere. This is the behavior of the Journalist Interface currently, and it's also the behavior of applications like Semaphor.

With that said, it does seem important (based on chats with a few users) to ALSO have some kind of "save" feature so that they can save a particularly interesting document even if they are deleted on the server. This is something that can be done right now in the SVS, so preserving that behavior is important. What about something like this where there is a "cold storage" feature (I am not a designer and this is not design advice... but you get the idea):

Note that this is also now a minimal version of the client without any of the not-currently-possible fancy features (org name displayed on SD, emojis, icons for journalists, journalist-to-journalist comms) and this one can be implemented only using functionality possible via the API in freedomofpress/securedrop#3619

[heartsucker]

"I am not a designer"

posts amazing design

ಠ_ಠ

[heartsucker]

But really, yes, that sounds like it would do the things i think think it should do. A+++ would implement.

[redshiftzero]

Haha thanks @heartsucker. So one thing I don't like about my mockup above is the "cold storage" abstraction, I feel like people would get it but it doesn't seem totally natural, so I wonder if there is a clearer way to do this...

[redshiftzero]

@huertanix I'm particularly curious what you think about this, let me know if you have an idea on the "cold storage" concept 😇

[heartsucker]

Yeah agree on that. Maybe just call it "archive"? That seems intuitive enough. (Anyway, waiting on real UX people to tell us what ta do)

[trevortimm]

just chiming in here to say that looks amazing, @redshiftzero 😃

[huertanix]

@redshiftzero This mockup looks very good; Very familiar application elements, intuitive layout. On cold storage, I'm not sure I immediately understand it. Is this the equivalent of a personal stash that would, in the current SecureDrop system, be a bunch of encrypted files in a Tails journalist drive's persistent storage? Or the removal of the files/conversations from the local machine while still keeping them on the server?

Side note that these guidelines from Gnome may be helpful in figuring out some design decisions around the fine details like notifications, button layout, etc: https://developer.gnome.org/hig/stable/.

[eloquence]

@huertanix The interactive wireframes at https://eloquence.github.io/workstation-messaging/ (see #102 for background) may help to elucidate how "cold storage" (called "archival" in the wireframes) could work in practice. Click the menu, select "Mark for Archival" and then "Delete". Basically, this feature would ensure that the locally stored copy is not deleted from disk when a source is deleted.

I'm still not convinced that's truly an intuitive approach, but it's a tricky problem: we do want to support keeping local copies, while generally keeping the workflow as simple as possible. Alternative suggestions to explore would be most welcome!

[huertanix]

@eloquence Thanks for the example. Archive and cold storage don't really tell me where the archive will actually live. There's some verbiage on the message when choosing to delete that explains where it gets deleted and where it doesn't, which is good. I think something that may be worth considering is something closer to a webmail/cloud-esque set of expectations; e.g. removing the idea of a local copy completely from the design. Of course there would still be a local copy, technically. Gmail and Tinkercad download a copy of a message or 3D file from a server to a browser, but they're examples of an interface that doesn't need to bring attention to that, while still offering an option to export a thing as an archive file if the user wants to hang on to a copy.

Would there happen to be any feedback available from recent user interviews around how long journalists keep source histories around for, or how they deal with deleting older source histories? This may help inform what some of their expectations around this are.

[eloquence]

@huertanix

Thank you, great food for thought.

Our FAQ states:

"Journalists are also encouraged to regularly delete all information from the SecureDrop server and store anything they would like saved in offline storage to minimize risk."

The sample privacy policy states:

Journalists decrypt and read each message offline. They are encouraged to delete messages from the server on a regular basis.

I don't think these recommendations are consistently followed; the limited user research we have done includes quotes like "I think we haven't been going through old submissions and deleting them" but also "Periodically I would delete them when the submissions were dealt with."

I think we should be very clear why those recommendations exist, i.e. what threats they mitigate against, and how we want to deal with those threats in the new SecureDrop Workstation architecture. (CC @emkll). From my understanding of the threat model, the following approach may make sense:

• Add an "Archive" feature to the server that would disable a source login, but not delete the content. This would, at least as I understand it, reduce the risk of intercepting source communications or impersonating the news organization to the source via a compromised server.

• Add a "Move to cold storage" feature to the client that would prompt the user to insert a USB drive or other archival medium and store all content associated with the source in encrypted form on that medium.

This approach would enable a near-term/mid-term/long-term distinction for how to deal with content:

1. In the near term, you interact with a source through the client.
2. In the mid term, you can access all files associated with the source through your archives in the client, which are synchronized on all workstations via the server. However, archived sources can no longer log in, reducing risk to the source from a compromised server.
3. In the long term, submissions are deleted from the server, and only select individuals have access to cold storage files. Those files may be difficult to work with (think a folder with 1-benign-artichoke-msg.gpg type files again), offering none of the affordances of the client.

The software could express those concepts through subtle reminders ("This source is more than a year old. You may want to consider moving it to cold storage.")

Does that sound potentially like a workable approach? Regardless, the more I think about it, the less I think the idea of a per-workstation archive integrated in the client as in the current prototype/mock-ups makes sense. There would be synchronization problems that are difficult to surmount (some users ending up with incomplete archives), visibility issues (who has a copy of this document?), and mental model issues (what's server-side/local?).

[emkll]

I see there being three distinct ways of categorizing the data availability:

• Live storage (on servers and on workstation)
• Local (workstation) storage
• Archival (neither accessible by workstation or server) storage

The concern here is access to decrypted submissions or communicating with a source, leading to potential source identification. This could be achieved via obtaining source passphrase, rogue journalist or malicious actor by compromising the app server, acquiring either journalist or admin credentials, or obtaining access to the workstation.

To reduce the likelihood, we could:

• Ensure the journalists don't share logins
• Disable source account automatically after a period of inactivity
• Use physical tokens for GPG keys (would make key extraction difficult and loss of key easier to detect)

To reduce the impact, we could:

• Delete files from the server
• Make content undecipherable on the workstation
• and/or occasionally copied off the workstation on an encrypted key
• There was also the option to completely delete the submission, bypassing cold storage

Local storage feature would increase the impact if:

• There are many submissions in cold storage
• The workstation is stolen/compromised

The local storage approach would make a journalist more likely to delete submissions on the server, but increase the amount of sensitive data stored and accessible to the workstation. To reduce the amount of submissions that are stored locally (perhaps after a story was published, the documents are no longer needed, but want to be preserved), we could introduce some form of archival storage.

Disable source accounts

I think disabling/deleting source login should occur automatically after a fixed period of source inactivity, which we communicate, to reduce confusion (or triggered by the source). I think this is an area where the most user feedback is needed to better understand source and journalist requirements.

Local storage

Deleting files from the server immediately will mean that it's possible only one workstation has the submission:

• To improve visibility, submissions sent to local storage could have a flag indicating other clients to download and send to local storage the next time they synchronize, and get automatically deleted after a period of time.
• Send to local storage + immediately delete would also be possible

Archival storage

I think we might also want to consider another option, sending documents to archival storage:

• Archival key is in custody of the legal team
• Archival private key is not on the workstations
• Archival action would encrypt the submission to the archive public key
• Archived submissions occasionally backed up to an encrypted external hard drive.

[redshiftzero]

I think the disappearing sources idea is a good one, this came up a while back over in: freedomofpress/securedrop#2068 where there are some thoughts about whether this should be configurable (probably yes).

Regarding the archive/cold storage flow, thanks for feedback all, the concept is definitely confusing and adds significant complexity. What about we abandon this and just do the following:

• When sources/documents are deleted, they are deleted everywhere, and there is no way to modify that behavior.
• We state clearly in the docs / release notes / training curriculum describe that this is the behavior.

This simplifies the implementation significantly and makes for a clear experience. Then we can focus more engineering effort on the export flow, e.g. the UI that will probably need to enable options like:

• Save to external media (for transfer to other journalists in the org, i.e. encrypted to a PGP key that is not the SecureDrop submission key, e.g. the legal team like @emkll suggests)
• Onionshare
• Print (using a separate VM)
• Open in (e.g. MAT) (and all of those options also enable a user to preserve messages/documents they want to keep long term satisfying the reason why the cold storage option was suggested) Backups should be done regardless separately from this feature, opened Document backup policies for the workstation #120 to track

[redshiftzero]

this is very old, so closing - this is now in progress in individual followup issues in https://github.com/freedomofpress/securedrop-client and https://github.com/freedomofpress/securedrop-ux