Extent file upload size limit

[huertanix]

Description

Extend file upload limit from 500MB to 2.5GB.

User Research Evidence

A number of journalists have expressed concern about the 500MB file size upload limit, since they've had to deal with leaks in the form of large video or database files. A file size limit of 2.5GB would accommodate the size of a wider variety of files, although this is a preliminary recommendation and it may make sense to check whether this would be too slow for real-world use or susceptible to Tor connection-related problems.

User Stories

As a whistleblower, I'd like to be able to leak a document that is larger than just a document.

[zenmonkeykstop]

500MB limit was apparently motivated by concerns about traffic analysis flagging suspiciously long-lasting Tor sessions, even more so than network performance/availability issues. See #986.

[ninavizz]

I've been creating instructional videos for another client, and many are over 1GB in size.

One of the primary selling points for adopting SD, is precisely that it allows for file sharing. I would like to bump it up to at least 1.5GB, and would prefer 2.5GB.

As a non-technical user w/o video editing software, how would I know how to split a file up? As myself, I use a FOSS editing program, and it takes FOR-EVER to compile new videos from broken-up chunks; which could also impose hardship upon users.

986 was filed in 2015. How significant of a risk issue do those concerns continue to be?

I really want to be mindful to optimize the SUI for non-technical sources short on time and resources. Asking users to do encryption or to split-up files, introduces more friction for them than I'm comfortable with. @emkll @redshiftzero ???

[huertanix]

Some thoughts on #986:

Regarding the risk around traffic observation, re: it "could in itself make the internet connection interesting enough for a preliminary investigation", has there been any analysis on how Tor v2 and v3 onion service traffic may look more interesting during a file upload versus other more typical Tor Browser use case, like watching a Youtube video on the regular internet?

Tor network traffic already looks suspect to many network observation systems if it is flagged at all. If we're assuming a network would ignore Tor traffic in general, why would we assume there would be an exception made for this specific kind of traffic?

Regarding some of the proposed mitigations referenced in #986:

a) Sending via USB

Many newsrooms have a mailbox to send things to, this could be a workaround if it came down to it.

a.1) Generate a PGP key
a.2) Instruct the source to install GnuPG (option 1: downloaded over Tor from the SecureDrop site, option 
2: download in plain view, as if for standard personal usage)
a.3) Display the PGP's public key with which the data should be encrypted.
a.4) Display a mailing address that the USB should be sent to.

Whistleblowers in recent history are generally not Snowden-level skilled. PGP has, over it's 20+ year history become less easy for people to use, with fewer people in studies successfully navigating the most user-friendly client software available in 2015 than what was available in 1999: https://arxiv.org/abs/1510.08555. Any workaround involving PGP would likely not work out unfortunately.

[huertanix]

Forgot to add these:

b) Similar to the above, except with the source serving the file over bittorrent (the difference being that this is much more "normal" use of traffic)

Network monitoring software in public spaces may in many cases look for torrent traffic for unrelated copyright enforcement / IT staff wanting to avoid their bosses yelling at them about the DMCA notice they got served. Many Tor relay guides recommend blocking out ports used by bittorent, and even with that, using bittorent over Tor requires a level of technical proficiency not typical of the vast majority of known whistleblowers.

c) Arrange to meet in person. Obviously not the best option, but it's one way to avoid asking the user to download and install GPGTools or Tails to their devices

There are some uses cases where this works. Many, many times though, sources are in other countries or otherwise far away from their newsroom.

d) Allow the source to proceed with a large upload (eg up to 500MB), but show a friendly OpSec message that this may not be the safest thing to do.

There's already a lot of warnings to manage in the Source Interface, and in many cases they may be getting ignored, as people have gotten used to ignoring warnings about cookies and privacy.

[ninavizz]

Whistleblowers in recent history are generally not Snowden-level skilled.

The above is actually true of all whistleblowers, throughout history (from what I've learned in my past year of reading monographs—Dr @martinshelton is actually a PhD on these matters, though).

Gentle reminder: SecureDrop's targeted users, are whom allthings should be optimized for. This is a rollup of what was presented at the retreat, wrt who uses SD and who it should be optimized for. If there is disagreement on what is currently on the UX wiki, we should step-back and re-evaluate as a team.

[deeplow]

Any workaround involving PGP would likely not work out unfortunately.

Maybe there's a way @huertanix - just a random idea: encrypting with pgp for sending via usb stick could be made easy by providing a page in the onion service with a drag-and-drop interface for encrypting with PGP (all client-side). It would perform the encryption with the journalist's GPG public key transparently to the source and then it would show a download link and further instruction.

But two problems come to my mind:

• It could use the OpenPGP.js, but it would go against the recommendation of disabling javascript
• performing encryption of large files in-browser could lead to browser crashes/freezes

This might be far fetched and not worth considering. Just throwing it out there

[zenmonkeykstop]

@deeplow There was some work done on a firefox(Tor) extension to do something similar - to pull a GPG key from a server and use it to encrypt a file prior to download. If it also gzipped files first that would make the time taken for encryption less painful. IMO this was a more promising approach.

Apropos of the file size thing in general, I'm currently waiting on a mere 100MB upload and it's already stalled once and is crawling the second time. I can't imagine what something on the order of a couple of GB would be like (more chance of dropped connections for one). If there was a need to increase SD upload sizes, just upping the limit would not realistically do it. There would probably need to be support for resuming uploads or splitting files up locally. Not exactly easy without JS.