Enable journalists to view, download and decrypt replies deleted from source interface

[msheiny]

Feature request

Description

We currently ask sources to delete replies from journalists, through the following language.

You have received a reply. To protect your identity in the unlikely event
someone learns your codename, please delete all replies when you're done
with them. This also lets us know that you are aware of our reply. You can
respond by submitting a new message above.

This is both inaccurate (deleting replies does not intuitively convey information to the journalists) and conflicts with the anticipated new client workflow (see freedomofpress/securedrop-workstation#89). We should enable journalists to view, download and decrypt replies deleted from the source interface, and update the messaging above to be consistent with the final workflow (i.e., potentially remove the sentence "This also lets us know ..").

User Stories

As a journalist, I'd like to be able to see prior communications with sources, even when the source has deleted those replies.

As a source, I'd like to continue to remove replies when I have read them, so that a compromise of my codename does not give an attacker access to those replies.

Subtickets

• [reply refactor] Also encrypt replies to submission key #3673 Also encrypt replies to submission key
• [reply refactor] Allow journalists to download replies from journalist interface #3674 Allow journalists to download replies from journalist interface
• [reply refactor] Preserve conversation history between sources and journalists #3675 Preserve conversation history between sources and journalists
• [reply refactor] Add journalist interface API endpoints for replies #3676 Add journalist interface API endpoints for replies

Significantly refactored by @redshiftzero and @eloquence; see edit history for original report by @msheiny.

[msheiny]

To clarify, yeah i know there is a counter on each message .. I guess a journalist could infer that well there is a missing reply because i see a 2-code-name-reply.gpgand a4-code-name-reply.gpgbut no3-code-name-reply.gpg` .... I dont think thats a good UI experience though. It also doesnt help in the situation where the last journalist reply is the last message in the convo chain (and then gets deleted by a source).

[redshiftzero]

I was thinking about this more and the behavior should be modified to:

1. From the source side, we should continue to encourage them to delete messages to continue to reduce the impact of a codename compromise. I think using the term "delete" is not misleading, as they will be deleted from the source perspective and not available in the source web application. Thoughts welcome on this particular term, we could always use "mark as read", but would need to indicate they will no longer appear.
2. When replies are sent to sources, they should be encrypted to both the airgap submission key as well as the source public key.
3. In the journalist interface, the replies should be available for download.

Optional:

4. When the source deletes a message on their side, it marks the reply as read on the journalist side.

The primary advantages of this is it enables a journalist to recall what they have been saying to sources by following the conversation history in the SVS. It also enables a journalist to view what other journalists have been saying to sources, to circumvent the problem where one journo has replied, but no-one is sure if that's happened or if the source just checks SecureDrop a lot and has deleted the reply already (to @msheiny's point above).

The disadvantage of this is that a journalist, after seeing this behavior change, may not be aware that their reply can be read by others onboarded to SecureDrop. To address this (legitimate) concern, we could have a "Mark as private (only the source can download it, not other journalists)" [text needs massaging] button that makes it downloadable via the UI only by the journalist that submitted it. This issue is closely related to per-journalist keys, as in such a case the reply should ideally only be encrypted to the source key and a key that only the journalist possesses.

[redshiftzero]

when this change is made we should add (at least) two new API endpoints: GET /api/v1/replies and GET /api/v1/sources/<source_uuid>/replies so that journalists can get replies across all sources and then download replies per-source

[redshiftzero]

I want to pick this issue up in the sprint as we need it implemented it for the conversation view in the client. The current behavior is pretty confusing from the journalist's perspective, so the current web interface should also be updated also at the same time. This also will get users used to the behavior coming in the client.

Plan of implementation:

• Allow all journalists to download/decrypt/read replies sent to sources (just as they can read replies from sources -> journalists). It only makes sense imho to restrict access when Retire SecureDrop's shared inbox for journalist users #1550 is implemented
• Preserve "delete reply" text on source interface as the goal of this practice is to delete replies from the source inbox to minimize the impact of source codenames being compromised

[redshiftzero]

woops accidentally closed

[redshiftzero]

(added link to subtickets to original issue)

[eloquence]

All work identified has been done and merged into develop; closing this epic, we can open new issues for any fixes/improvements identified during QA.