I created a publicly accessible IPFS Gateway and I would like to mitigate legal trouble from it.
The tor operators guide is pretty extensive, but I imagine a little over-zealous.
Is there a guide or doc of suggested configurations?
2 Likes
You should double check because it should depends on the legislation where your servers are.
Of course you are directly responsible if you are trying to do something illegal with it! I strongly suggest to not do that 
Yes, thanks for that suggestion, we all need reminders to follow the law sometimes.
Let’s assume I am not breaking the law, and I want to be least responsible for others doing questionable things whilst using my gateway. Are there suggested configurations or guides for those that want to help the IPFS community by running a public gateway? Is there value in me providing such a service (with aims of stability and longevity) to the community? Or am I just wasting my time and resources? At the very least, I can use it for my personal/family uses, but I would like it to be safe also.
For now, I am considering:
Allowing writability (for POST requests)
Rate limiting at 10 GET requests per hour (this will change later)
Reducing total cache size to 2GB (if I see value, I may scale this up into the TBs, who knows)
My http frontend will close the connection after serving a file larger than 1GB (I would prefer if my ipfs daemon had the option to refuse to serve files larger than X)
These considerations are only to mitigate rampant warez (as well as other unmentionable illegal numbers) distribution coming from my gateway, as to reduce negative attention from authorities et al.
I understand it’s impossible to prevent all/any illegal numbers from landing on IPFS, but I would still welcome some input, suggestions, or shared experiences about mitigating those sort of unwanted attentions, especially when you are specifically trying to prevent such uses on your gateway.
Any better suggestions other than “don’t do illegal things!”? Or should I find a better place to discuss my concerns?
Probably IPFS is too small to even consider these things. There are no guidelines as far as I know, as it is a protocol.
I think that the ultimate goals is to avoid the usage of Gateways and use directly the nodes.
Warez are part of the legacy web, and they’ll be part of the IPFS-based web. (They probably are already.) So if you allow for writability, which I applaud—globalupload.io also offers uploads to the gateway, even though it’s currently not working—, I’d suggest to offer an abuse/DMCA contact, so you can at least remove an object from your own gateway node. The file would still be available on the network (probably), and since there are no IPFS blacklists at the moment, you could add a little IPFS/IPNS hash check to your gateway node, i.e. that any outside request for a file that has already been taken down via your abuse/DMCA system before, will be blocked permanently. You will not be able to block the object within the IPFS itself, but every outgoing gateway traffic could be thwarted. Then you’d be on the safe side. (I assume.)
Another thing you could do is limit the pin-time of uploaded files, i.e. files that a user uploads to your gateway node, e.g. via curl POST, will only be pinned for, let’s say, 2 or 4 weeks. After that, the node will run an automated ipfs pin rm command (without immediate garbage collection, however). If the file hasn’t been distributed on the IPFS yet (no demand), then the uploader is out of luck. But if it’s illegal content, and you receive a takedown request pertaining to that IPFS object, you can then answer that the file is already gone from your node. (You can still block downloads through your gateway, though, to be on the double-safe side.)
You might even be able to base the upload part on transfer.sh (GitHub); uploaded files are deleted automatically after 14 days, but the server will have added them to the IPFS already, and you can then program your IPFS node to adhere to whatever pin/retention time you want. You just have to reprogram transfer.sh to output the IPFS hash(es) as well, apart from the legacy download link. (Not sure if that’s possible.)
Thanks for this. I would like to encourage others that are interested building their own gateway, so I will attempt to write a guide.
I see an interesting future for ipfs and I think having a bunch of independently run, stable gateways would definitely bolster the health and usability of ipfs in general. (Not to mention the cool possibilities of a CDN-esque ipfs system).
I may also consider adding a disclaimer header to every response with a link to an end user license agreement or something that could help me prove my absolution or whatever.
1 Like
My aim is actually to wait and see how filecoin is supposed to work. I have always rented web servers, and there was always some space to share, so at first my plan is to develop a functioning IPFS node without any gateway, just to strengthen the whole network, filecoin or no filecoin. The next step would be an upload service for users without a local node, i.e. new users who want to share files via IPFS, but don’t have the “guts to go command-line”. Don’t know if there will be a third step, which would be a gateway or “exit node” for external users to download stuff from the IPFS. The primary goal should be to get people inside the IPFS, not present IPFS to them as just another cyberlocker of some sort. So I’m not really sure about step 3 (download). Steps 1a (functioning autonomous node), 1b (node with filecoin), and 2 (upload to the IPFS) are cool, though. As long as there is no download functionality, you won’t need any disclaimers, abuse/DMCA stuff etc.
Ever get around to writing this guide? Would be very much interested in it.
I have started some work on this guide, I have also made ipfs easy to deploy via docker, see here: IPFS in Docker with HTTPS , the guide will be made next.
2 Likes