Logged out mid-upload due to inactivity?

[rocodes]

Description

While testing uploads and downloads of different file sizes, I observed in the middle of an upload (50MB file, it was at the ~7 min mark) that I was redirected to the "logged out due to inactivity" screen.

I had been doing other testing previously while logged into this account, so it's quite possible I was up against the 2h expiration timeline, but I had been "active" (uploading files), and since an upload was in progress, as a user I would not have expected to be logged out.

Steps to Reproduce

Attempt to upload a file that takes more than SESSION_EXPIRATION_MINUTES ( = 2 hours). Or log in, have a user session that is close to SESSION_EXPIRATION_MINUTES in length, perform some user activity, then towards the end, begin an upload.

Expected Behavior

Upload continues

Actual Behavior

Redirected to "you were logged out due to inactivity" screen.

Comments

My naive expectation was that "activity" (such as clicking buttons, uploading files, etc) would reset SESSION_EXPIRATION_MINUTES. If that's not the case, and a user has two hours total before getting logged off, no matter what, maybe we should advertise that more prominently (in the docs our in the source interface?) so that users are not caught by surprise, especially since file uploads can be slow (I was getting just over 1 Mbit/s best case, and ~ 0.6 Mbit/s average case).

Another thought: we also had this report of being redirected due to inactivity mid file upload - #6737. However, I can't reproduce my issue consistently.

[zenmonkeykstop]

That is the behaviour for JI sessions (which are server-side and Redis-backed) but not for SI sessions (which are client-side). SI sessions have a timeout value that is set once, when the user logs in, to now+120min (see original implementation discussion here: #880).

This is kindof a problem anyway, as https://metrics.torproject.org/torperf.html?start=2022-12-03&end=2023-03-03&server=onion&filesize=5mb indicates that we should be expecting on the order of 2-3min for a 5MB upload (assuming uploads and downloads to an onion service are roughly equivalent), which naively gives us about 3-5hrs or so for a 500MB one 😬. It's entirely possible that a source uploading multiple big submissions in one session would hit the limit, even if they were avoiding maxing out individual submission sizes.

So, maybe at minimum we should be:

• verifying that the assumption that TBB wipes cookies on shutdown is still true
• updating the SI session timeout to ~300min (to actually give submissions of ~500MB a fighting chance of success)

A bigger change, requiring some security modeling, would be:

• adding similar logic to the recent JI session update (but still stored client-side) to bump the session expiry on activity.

[zenmonkeykstop]

Probably simplest way would be to just reset the expiry time at the beginning of submissions, not sure if it's worth capping the number of times you could do that a la JI

[rocodes]

I timed upload times on a couple of different circuits yesterday and with files 1-50MB just to get some anecdata.

My best speed was 2.2 Mbit/s, but average was more like 0.4-0.6 Mbit/s. I also encountered one very slow relay, where I encountered multiple timeouts while trying to access the source interface. Switching circuits resolved this.

Very unscientific results (each file size tried over 2 different circuits) for uploads:
1MB file: 22 seconds, 17 seconds, 17 seconds (0.36 - 0.47 Mbit/s)
5MB file: 54 seconds, 18 seconds, 50 seconds, 36 seconds. (0.74 - 2.22 Mbit/s)
10MB file: 1:58 (0.6Mbit/s), 2:28 (0.54 Mbit/s)
20 MB file: timeout (didn't retry)
50 MB file: one server error, one logged out due to inactivity (this issue), one successful upload @ 18 min (0.37 Mbit/s)

Downloads (from client):
1 MB ~ 6 seconds, 3 seconds
5 MB ~ 24 seconds, 3 seconds
10MB ~4 seconds
15 MB 11 seconds

50MB : 1st try sync failure after 2min, can't reach server; restarted Tor, 2nd try approx 4:15 (approx 1.57 Mbit/s)