How to block perticular cid

Help
15

Thanks for bringing these articles to our attention @Galactus. While it’s inevitable that some bad actors will seek to use IPFS, we immediately block malicious content on our gateways — email abuse@ipfs.io to report phishing. There is a system in place for processing this, at least for the one maintained by Protocol Labs.

To give more context, deciding which CIDs to co-host is a multi-faceted problem.
Here are some pointers at ongoing work in IPFS Community:

Tips for Gateway Operators

  • https://nft.storage/blog/post/2022-04-29-gateways-and-gatekeepers/ a case study by nft.storage team running their own public gateway.
  • If you want to run a dedicated gateway under your own brand, and only for your own content-addressed data, make sure it only hosts safelisted CIDs (or response types).
    • Consider denylists (described below) or running with Gateway.NoFetch.
    • OR (a quick alternative): If your gateway is used only for hosting image/video/audio assets, simply block text/html responses.It will make your gateway useless to phishing campaigns, but can still be used for asset retrieval (including trustless responses)

Allow / Deny lists

  • Protocol Labs’ gateway team maintains https://badbits.dwebops.pub, a list of hashed CID that have been flagged for various reasons (copyright violation, malware, etc). Feel free to reuse it until community-driven solutions exist (below).
  • IPFS Stewards and various gateway operators are working with Cloudflare to create a format for shareable allow/deny lists. Specification PR is in review: https://github.com/ipfs/specs/pull/299
    • We want to support this out-of-the-box in Kubo and other IPFS implementations. Feedback on the proposed spec will be appreciated.
    • Long term, we imagine various groups like content-addressed alliance https://discuss.ipfs.io/c/ecosystem/caa-wg/33 to maintain shared deny lists (similar to adblock lists we see today), allowing community to self-organize and defend against bad actors etc.
5 Likes