DIP-288 Content Takedown Announcement

[wesbiggs]

Abstract

Enable relevant entities to identify illegal content that should be removed either system-wide or regionally based on relevant statutes.

Introduce the following:

Content Takedown Announcement

• announcementType
• fromId: DSNP User Id making the announcement
• targetContentHash: the targeted content (Activity Content Note or attachment)
• regions: what regions are relevant to the takedown, based on the jurisdiction of the author
• legalReference: enumerated code for law under which content should be taken down

It may make more sense for the legalReference to be a URL with further information on the takedown request, as an enumerated list of laws would be complicated to maintain.

In response to processing a Content Takedown Announcement, a network participant should:

1. Determine whether they trust the originator of the request
2. Determine whether they are impacted by the request (e.g. geography)
3. Make content inaccessible either globally or regionally as requested

It is also envisioned that a compliant implementation would maintain a deny list of content based on the collection of targetContentHashes that would apply to future content as well.

Motivation

As a law enforcement organization, I want a mechanism for notifying actors in a decentralized, distributed system about content that is illegal and should be removed.

This helps address areas where the Tombstone announcement is insufficient.

1. Providers can only Tombstone content which they published (on behalf of delegating users).
2. Uncooperative Providers may refuse to publish a Tombstone Announcement for illegal content brought to their attention.
3. Tombstone is a very binary tool: content is either active, or tombstoned. It does not allow for any nuances with respect to legal jurisdiction of a particular request, such as scenarios where certain content may be illegal in one region but legal in another.

Specification Pull Request

Current change pull request: TBD

Rationale

Why were the design choices made? What other solutions were rejected and why?

Backwards Compatibility

No migration necessary. However, providers with prior knowledge of deny listed content may wish to batch announce these as soon as this facility is available.

Reference Implementation and/or Tests

What could this look like implemented or what tests could be provided to assist in validation of implementations?

Security Considerations

Each network participant processing a Content Takedown Announcement must decide whether or not to honor it.
It is unclear, for example, whether a Takedown request from an individual user should be honored. We would hope to establish a list of well regarded fromIds that participants can trust, and encourage them to use this facility sparingly.

It is impossible to "guarantee" that a piece of offending content will be removed from all possible caches and access points. At that point the issue may necessitate a further legal process. We hope a facility like this will accommodate reasonable implementation times, to give network participants time to receive and triage such announcements.

Dependencies

None

References

There is a list of hashes of content removed from IPFS that might be interesting.

Copyright

Copyright and related rights waived via CC0.