Add a third file type in the source store, to allow journalists to store notes readable in the SVS or SecureDrop Workstation

[zenmonkeykstop]

Description

Currently the source filestore includes message and document types, covering the different categories of possible submissions. Both are encrypted to the Submission Key and are only readable in the SVS and SDW.

If journalists want to annotate source records (say, for categorization beyond starring, or to add notes for other journalists with access), they must use another system in addition to SD. This system may not be secure, and will not be integrated with the SDW client.

To address this, we could add a 3rd file type, the notes type. There are two potential ways this could work:

1. simple messages: notes are text messages (just like source messages) but created by journalists, encrypted to the submission key, and downloadable and decryptable in the SVS like other submissions. Unlike replies, they would not be encrypted to the source's reply key and would not be visible to them. They could also be created and displayed in the source's conversation timeline in the SDW client, styled appropriately so as not to be confused with source messages or journalist replies.

2. structured data: notes are structured (eg JSON) text files, created based on journalist input, encrypted to the submission key as per (1). They include prioritization, labels, notes, and other potential source metadata. This version would not be as useful in the SVS, as the notes file could not be decrypted and updated in the JI. If supported, any new notes file would be created from scratch in the JI.

If it was SDW-only, however, it could serve as a way to record and share sensitive metadata as described above without having it stored in plaintext on the server. As part of the process of syncing source data with the SDW, notes files could be downloaded and applied to the SDW's source entries, and journalists could edit the fields via the SDW, uploading a new encrypted notes file when done.

How will this impact SecureDrop users?

This would allow for tagging and annotating source entries, either in a basic manner as per (1) or with arbitrary complexity as per (2), opening the door to several requested SDW features.

How would this affect SecureDrop's threat model?

Threat model implications are similar to those raised by replies. While the notes would be encrypted, forensic examination would allow for a clearer picture of which sources journalists considered important, and when in the conversation order they recorded information about them.

This could be mitigated in (2) by creating a single notes file for the source on account creation, and only updating that file. The file could be padded appropriately and have the same creation/modification time obfuscation as other submission types, to reduce forensic value.

User Stories

As a journalist, I want to be able to classify and annotate sources without compromising their security.

[rocodes]

I like this suggestion and am interested in exploring it further when we have capacity. Some brief non-exhaustive thoughts:

• This could reduce 'shadow' sd infrastructure and be very helpful to folks, but there are huge UI implications and we'd probably want some ux/ui help with it. It would have to be very very obvious when one was writing a private note and when one was replying to a source
• My first impression is I would support keeping things as simple as possible and accepting the same observability properties as we do for replies, rather than trying to mitigate the observability of notes even more than we mitigate replies, esp if there's a big usability difference for journos (displaying 1 giant note vs interleaved notes), or a big maintainability difference for us
• I'm getting ahead of myself here, but one thought I had is that this could allow us to potentially deprecate star/unstar, which has mixed/negative user feedback

[zenmonkeykstop]

• My first impression is I would support keeping things as simple as possible and accepting the same observability properties as we do for replies, rather than trying to mitigate the observability of notes even more than we mitigate replies, esp if there's a big usability difference for journos (displaying 1 giant note vs interleaved notes), or a big maintainability difference for us

I'm not sure what you mean by observability. Way I was thinking, if we did have one giant structured note, it would be more like ancillary data to be added to the source db on the sdw side. So when we sync a source, the notes file gets pulled down too and used to update the sdw-side DB, then the source entry would be rendered with any tagging/highlighting options, and the conversation would be rendered with with the notes in sequence.

• I'm getting ahead of myself here, but one thought I had is that this could allow us to potentially deprecate star/unstar, which has mixed/negative user feedback

That or implement it as a special case for tagging. If you wanna get really ahead of yourself, it also paves the way to emoji reacts on messages :)

[rocodes]

I'm not sure what you mean by observability

Sorry, confusing wording on my part. I meant that my first reaction is that the threat modeling for replies should suffice for notes as well, meaning that yes we would be accepting that we're leaving some indicators in the DB and more notes probably means a more interesting source, same as replies.

[cfm]

I agree that this will be good to discuss further before trying to prioritize. The questions that jump out at me are:

1. whether we can reduce notes to submissions from journalists to the submission key; and
2. whether we therefore do the encryption step in the Journalist Interface (like submissions/replies; server sees plaintext) or only in the SecureDrop Client (server sees only ciphertext).

Sequence diagram to analyze this typing in terms of keying and directionality:

https://gist.github.com/cfm/e2d19584197025ec866a69add78af0b6

[zenmonkeykstop]

I agree that this will be good to discuss further before trying to prioritize. The questions that jump out at me are:

1. whether we can reduce notes to submissions _from journalists_ to the submission key; and

Yup, that's effectively what I'm suggesting. The question is what the plaintext looks like and can be used for, which leads to:

2. whether we therefore do the encryption step in the Journalist Interface (like submissions/replies; server sees plaintext) or only in the SecureDrop Client (server sees only ciphertext).

...which is kindof where I'm getting at with the 2 potential approaches - if it's just text notes then IMO doing it in the JI is fine. We already accept the risk of the server seeing plaintext replies before encryption, so as Ro pointed out this is similar.

If you want a structured format or additional information (tagging etc) then IMO it's client-only, as the JI can see plaintext before it's encrypted, but can't decrypt the note to either annotate source entries with it or allow it to be updated.

(And in case it comes up, I would not use either the reply key or another encryption/decryption method serverside for something like this, as that would mean that source metadata in the notes file could be compromised with a popped server.)