Add support for downloading submitted documents

[eloquence]

As a journalist, I want to download documents submitted by my sources, so I can view them or otherwise process them in various ways.

As shown in the messaging prototype (click blue download button next to a submission), download of submitted documents to disk should be possible from within the client.

[eloquence]

As I understand it, it has not been decided yet whether documents should be stored in encrypted form (see freedomofpress/securedrop-workstation#90) given the additional layers of full-disk encryption and user authentication that the workstation itself provides.

[eloquence]

That decision has been made; for now, we will store files unencrypted.

[redshiftzero]

hey @ntoll this is a good ticket to start on next: it has no qubes dependencies, and its completion unblocks #20 and #21

a bit more information about the scope here:

• we want to display in the conversation flow that a file exists to be downloaded.
• we want to indicate just the size of the file
• we want to download the file after clicking on it. UI-wise we should do something very simple in terms of user feedback when the download is happening and we can iterate later
• the files will be downloaded but not decrypted at this stage and that is OK, decryption will be handled in another ticket

[ntoll]

Questions / clarifications

• There has always been a notion in the mock-ups of "chat" with files attached. This is definitely not the case in the way the data is modelled. There are just files.
• I'm assuming that the workflow is something like: you click on a file, this is downloaded, the contents of which are then displayed (once decrypted). That's it.
• There is no "chat" to speak of (no pun intended). Just files that may (or may not) have been downloaded.
• The files appear to the left or right depending upon if they're submissions (from the source) or replies (from the journalist).
• The order of the interaction is alphabetical for the filenames used.

Right..?

I've got the UI all plugged in (so you click files and events are raised) but need to know how to proceed in terms of expected workflow. ^^^

[redshiftzero]

Excellent questions @ntoll - but first, heads up there's a separate ticket that is closely related to this which @joshuathayer is working on: #40 - I'll reference this in a couple places in my question responses and let me know if you think there is confusing overlap

There has always been a notion in the mock-ups of "chat" with files attached. This is definitely not the case in the way the data is modelled. There are just files.

Yep exactly. All submitted data (submissions) from sources are GPG encrypted files. They can be of two types:

• "messages" which are plain text and sent through a HTML form in the source interface (right text box here), or
• "files" which can be any file type submitted through the upload HTML form in the source interface (upload button on left here)

Both message and file submissions get GPG encrypted and stored on disk, and these are both then accessible via the API submissions-related endpoints. The way to distinguish them is via the filename on the submission, which end in msg.gpg for messages and doc.*.gpg for tests.

For both messages and files, we need to download and decrypt them. This ticket is just for downloading files. We'll keep the decryption part of the file decryption for another ticket as it has Qubes dependencies (the private key to decrypt the files are not in the same VM as the VM running the client). The message download and decryption is over in #40 (being implemented in Qubes first).

Note: this messages/files thing is indeed confusing on first examination, and you asking this question has made me realize that we should make an API change in the future (post alpha), I filed freedomofpress/securedrop#3904 over on the server side.

I'm assuming that the workflow is something like: you click on a file, this is downloaded, the contents of which are then displayed (once decrypted). That's it.

the "click on a file, it's downloaded" part - exactly. For the purposes of this ticket, we wouldn't do the decryption part. Another simplifying point is that the contents of the file won't be displayed - we won't attempt to open the file until #20 (files will open in a separate VM in case they contain malicious content).

There is no "chat" to speak of (no pun intended). Just files that may (or may not) have been downloaded.

The "chat" will get populated by #40 - once we sync - we'll start downloading the message files in the background and passing them to the decryption VM so that we can populate the message bubbles in the conversation view.

The files appear to the left or right depending upon if they're submissions (from the source) or replies (from the journalist).

Yep!

The order of the interaction is alphabetical for the filenames used.

Ah so the interaction counter is an integer that begins each filename (reply or submission), e.g.:

• 3-intermittent_proline-reply.gpg is the third interaction with the source
• 1-dejected_respondent-msg.gpg is the first interaction with the source

so alphabetic sort will not quite do what we want since e.g. ['1-blah-blah', '12-blah-blah', '13-blah-blah', '2-blah-blah'] when sorted alphabetically returns ['1-blah-blah', '12-blah-blah', '13-blah-blah', '2-blah-blah'] but selecting the integer and just sorting as integers will do the trick

let me know if anything is unclear or if there are further questions!

[ninavizz]

Ok... I have no idea if this is the right place for this, but since it's just Nicholas, Jen, and I'll 'cc @heartsucker for kicks, I figured I'd quickly share before hopping off for the eve.

https://projects.invisionapp.com/prototype/SD-IWS-DownloadDecrypt-cjnp346am00f0vk019tyfqvke/play/0cf6509e

This prototype demonstrates activity messaging in-progress, for:
• Initial downloading/decrypting of new messages upon sign-in (just click the sign-in button on that screen, text fields don't work atm)
• Downloading and decrypting files. The 1.6mb file in the prototype for Benign Artichoke, is live.

@heartsucker this is also a great mini-prototype instance for me to build some failed-to-send messages into... so wrt that separate ticket, I'll hop on that tonite after I'm home from class.

Animations in this are mega-choppy via tooling limitations on my end, and because sexy transitions aren't ever really a vision I've had. Namely just wanting to get in front of users to validate contextually located messaging; but, as allthesethings are the result of user feedback thus far, I figured I'd share.

Also (to keep Erik from panicking) THIS IS NOT TO BE ACTED ON VERBATIM... if Erik sees this, Nina Is Not Pushing Alpha Scope Creep. :D FYI. Just advising dev folks, for technical-debt reduction looking towards Beta, in how Alpha is getting built.

[redshiftzero]

this was done in #64