Big file, Torrent, Executable download policy proposal for Tor2web

[fpietrosanti]

Premise:

• Tor is not considered useful for file sharing as it hurt tor network
• Sometime t2w node administrator receive DMCA Takedown notice due to copyright
• Transfer of big files, seriously harm the Tor2web networks of proxy performance
• Having bittorrent tracker exposed may bring to some additional liability
• Having some malware (.exe trojan) hosted on Tor2web exposed websites
• Having Java Applet / ActiveX exploits

For the reason explained above i'd suggest to consider that Tor2web by default will have a policy so that it kindly ask Tor Hidden Service operator not to use tor2web to transfer big files, use Tor2web for any hacking, or use tor2web to host bittorrent trackers.

Tor2web will then handle a feature in a kind way, so that when the user is going to download a file bigger than X (where X maybe bigger than 10MB?), it will be redirected to a web page (landing page).

That landing page invite the user to download Tor Browser Bundle (for his platform), proposing him (for usability):

• the URL to be copy&pasted to access the file he was trying to download (under .onion url)
• the URL to be copied & pasted to access the referral webpage (under .onion url)

The very same behavior should apply to executable files *.exe, ActiveX, Java Applet and certain file types.

That way Tor2web can mitigate/discourage the use of Tor2web for file sharing purposes, downloading executable or bittorrent, without blocking the action itself, but again inviting the user to download the file directly over Tor.

The very same policy should be applied to Bittorrent trackers, that should provide the very same behavior, to bring the end-user to accessing directly and anonymously the tracker he is trying to download.

This set of action enforce the message that Tor2web should always try to drive the end-user into installing Tor and accessing content directly.

Such a feature should be enabled by default, by the tor2web node maintainer should be allowed to disable it.

By using such an approach we can foster a wider adoption of Tor Hidden Services, but in the proper way, by using directly Tor Browser Bundle, by reducing liabilities and performance hit of Tor2web network.

Cc @vecna @hellais @evilaliv3

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[fpietrosanti]

Addition: The main goal of tor2web is to expose Tor Hidden Services to the internet, but not to replace their functionalities completely. So it maybe reasonable to limit functionalities that can be used via a web page/http transfer, to the one that keep tor2web sustainable, always inviting the user to use TorHS directly with TBB.

[vecna]

well, the most strong option would be: keep track of the proxed session length, and if a session overcome a limit (eg, 5 megabytes) it's forcefully closed. HTTP 1.1 supports download resume, and then, if there no other way to download a file, may be possible resume every time the session get blocked, but would likely demotivate the user performing the download. tor2web would works fine with a "normal" web navigation, that is composed by smallest data transfer.

[fpietrosanti]

Yeah, from technical point of view it would be something like a matter of handling withe filename extensions, http headers such as Content-Type and Content-Length

[fpietrosanti]

@evilaliv3 reported that should not be possible to detect file size on Chunked-Transfer encoding.

[fpietrosanti]

In the mailing list the discussion goes in the direction that:

• bittorrent and magnet should not be blocked
• .exe are dangerous and could be blocked
• java applet / activex could be blocked
• big file download could be throttled

[hellais]

I don't think we should be blocking .exe, since there are a lot of legitimate uses for having such kind of files types be offerred over tor2web.

I do agree on the other hand for blocking torrent trackers that are hosted on tor2web. This is very different from blocking .torrent downloads.

Torrent trackers generate a lot of traffic and are damaging to tor2web, though I believe that with the current implementation of tor2web torrent trackers will probably not work since they will have the banner injected in them am I mistaken? If not we should block those.

[fpietrosanti]

Regarding the .exe a possible tradeoff would be to provide a warning to be accepted by the end-user (with Javascript interaction).

That way legitimate download files still will work but automated trojan download will stop working.