The Bad Bits Denylist is a list of hashed CIDs that have been flagged for various reasons (copyright violation, malware, etc).
The purpose of this list is to allow IPFS node operators (e.g. someone running a public IPFS gateway) to opt into not hosting previously flagged content.
View the Bad Bits Denylist (format specification)
The IPFS community Code of Conduct applies to content served over the public good gateways at ipfs.io and dweb.link run by IPFS Foundation and Protocol Labs. It does not apply to all IPFS nodes, nor to the IPFS network as a whole.
Reporting #
Please report any violations via the web form at ipfs.fyi/report-abuse or by email to the abuse@ipfs.io group. The Badbits Takedown team at Protocol Labs will handle all reports.
Protocol Labs also has a registered DMCA agent, and a public Google Form for DMCA takedown requests linked from ipfs.tech/legal.
Frequently Asked Questions #
Why are they called "bad bits"? #
We use the term "bad bits" when discussing topics involving copyright violations, DMCA, GDPR, Code of Conduct, or malware. This is a tactic to facilitate fruitful public discussion of concepts of freedom, censorship, privacy, and safety without slipping into destructive discussion patterns.
What is the denylist format? #
Bad Bits follow the Compact Denylist Format Specification published at specs.ipfs.tech.
The format is supported by many IPFS implementations such as Kubo (see content blocking documentation) or rainbow.
What is the legacy format? #
It is an old format where each entry is the hex-encoded result of applying sha2-256 to a <base32-encoded-cidv1-string>/<optional_path> string. This format is legacy and was superseded by the Compact Denylist Format Specification.
If you still need bad bits in the legacy format, it can be fetched from here.
How can I check that my node is blocking bad bits? #
Two sample CIDs let you test whether your node enforces the denylist.
Sample of an always blocked CID: bafkreicx5e3uuh5qqimy3copvblqebitoguqzqsnnqeq3ogz77aiwceopy
A benign test entry, kept on the list on purpose. A node that enforces the denylist refuses to serve it, so requesting it through your gateway fails (Kubo returns HTTP 410 Gone). Its content is a self-describing string: This is a benign test entry for the IPFS Bad Bits denylist at https://badbits.dwebops.pub/. If a gateway refuses to serve this CID, denylist enforcement is working as intended.
It appears on the list as the double-hash anchor 937cff398bf3be5f576d25bafa4c7f86a3a88f9b0354d1a1d5f48b6c98a54fc1. If your node serves it, the denylist is not enforced.
Sample of a never blocked CID: bafybeiczsscdsbs7ffqz55asqdf3smv6klcw3gofszvwlyarci47bgf354
The empty UnixFS directory (CIDv0 QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn). It is one of a few safe CIDs that the denylist never includes, because blocking them would break normal IPFS use. It should always resolve, so requesting it through your gateway should succeed. If your node blocks it, your setup is over-blocking.
I have other questions about IPFS gateways! #
Check out the Frequently Asked Questions about gateways in the main IPFS Docs.