Transparently resume and complete stalled or failed submission downloads.

[zenmonkeykstop]

Description

Large file downloads over Tor fail more often than over public Internet, and the client and server do not yet support resuming failed downloads or even provide good feedback as to download progress - users just have to start over after an indeterminate period.

With range request support in the server, the client would be able to a) be more assertive about timeouts, and b) send multiple requests to complete downloads, ideally without requiring user intervention.

There have been multiple related issues touching on different aspects of this problem:

• https://github.com/freedomofpress/securedrop/issues/3907
• https://github.com/freedomofpress/securedrop-client/issues/1707 - note that this one mentions using sd-proxy to store incoming fragments, this is probably not advisable as it means submission data would persist in a new location.
• https://github.com/freedomofpress/securedrop-client/pull/1718 - any solution should expect to use the RiiR proxy. But if possible the client should manage storing and assembling fragments and issuing range requests.

How will this impact SecureDrop users?

UX improvement for journalists using SDW.

How would this affect the SecureDrop Workstation threat model?

If download segments are stored in the same way and on the same AppVM as full downloads are currently, this should not have any threat model implications.

User Stories