@mig5 Since we are fortunate to have you with us and you are an Onionshare lead dev, I wanted to ask how easy it would be to add resumable downloads? This helps in scenarios where large transfer ahppen over unreliable networks that constantly drop the signal or in cases where the uploader/downloader has to move around.
Hi @HulaHoop!
how easy it would be to add resumable downloads?
First of all, you can uncheck the setting ‘Stop sharing after first download’ in the OnionShare settings. This will keep the Onion Service active in case the receiver (downloader) cancels the running share. Of course, it means the service stays active even after that resumed download completes later, so the onus is on the sharer to ensure they stop the share later if they don’t want it to linger too long.
(It’s also possible to use the Shutdown Timer feature in conjunction, so you can have a scenario whereby ‘leave the share running after first download (or for a resumed first download) but stop sharing either way after (say) 3 hours’.
A maybe unrelated note: @Patrick asked me recently about resumable downloads, I think with the belief that something on the Whonix infrastructure was not allowing resumable downloads. Whilst investigating this, I realised that in Tor Browser, right-clicking on a canceled download allows you to resume, whereas left-clicking actually starts the download from scratch again. This seems different to other browsers, and some users may not be aware of the right-click allowing resume. I mention this only because I wasn’t sure if that’s what you meant about resumable downloads or if you were talking about the ‘stop sharing after first download’ mode of OnionShare.
Finally, in the latest couple of versions of OnionShare, you can use ‘Persistent mode’ (again, in the Settings). What this setting does is saves the Onion Service private key to settings, meaning that next time you share, you get the same .onion url (and same slug too). This is useful when your connection drops but you don’t want to have to (or can’t) contact your receiver to advise of the new .onion.
After writing this great big response, I realise that the above (persistent mode) is likely what you were talking about all along. Use Persistent mode to solve the issue of a severed connection and retain the URL for a subsequent share.
I hope that makes sense? My advice is:
-
to uncheck the stop-share feature, and rely on Shutdown Timer mode if you want to make sure your OnionShare doesn’t linger for ages and ages for attack surface reasons, if you are concerned that a user might cancel the download mid-download, but wants to resume very shortly afterward
-
use Persistent Mode if you are roaming and/or your connection drops and you want to re-share it, but don’t want to have to re-communicate a new .onion to your receiver.
Let me know if I didn’t answer your question 
3 Likes
Thanks for the response. This is what I meant - resuming a half downloaded file in case the connection is interrupted and you’re right, its Tor Browser’s different way of doing things that caused confusion. Also keeping the onion address the same is mighty useful in these scenarios. Thanks for this great program
Tangentially related: since reducing the time-frame for compromise of sharing party is a goal, how about supporting uploads to a tahoe-lafs Onion server? That would allow for asynchronous sharing and protect the sharing party which can shutdown their process and access to sensitive material whenever they are done uploading and the downloader can then fetch whenever convenient - all while the tahoe server has no idea what is being shared.
1 Like
I think one of the primary goals Micah had was to avoid any requirement for a intermediary third party server, even if secure - it’s just a lot more convenient when there’s no need to run any additional infrastructure for either party.
Later this year we will move to defaulting to Onion v3 support (we’re holding off only because it’s unstable with Persistent mode), which should significantly reduce the risk of ‘discovery’ (compromise) of the onion.
You can also mitigate the discovery risk of v2 onions right now by using Client Auth (available in the settings), although that adds a burden on the receiver (they need to add configuration to their torrc to access the onion).
I’ll certainly mention this in the issue queue though! Thanks!
1 Like