There should be a web protocol standard for reporting CSAM to image hosts. Then nostr users could quickly notify image hosts to take it down.
Discussion
I have a relay already, I wish my relay implementation just came with http file uploads/downloads, no reason to be websockets only? 🤔
It's not exactly part of nostr/nips but it's an obvious adjacent function we need?
Or am I regarded
at a certain scale you probably don’t want your relay to be ingesting big ass jpegs and should split the two apart, but in general I agree this would be great.
also there is a new nips.be/96 for an HTTP file server
I feel like my personal relay that only serves my notes could very easily also serve my images from nginx or something? 🤔
yup. probably return a url from the file upload with a different host e.g. https://images.relay.* so you can move the static fileserver to another box/cdn if needed.
checkout nips.be/96 about file storage
Nostr seems like a good fit to be that protocol 😃
Most image hosts could care less about nostr, this probably needs to be a new web spec like along the lines of how lnurl did it (define some endpoint you could send reports to, etc)
I’ll help write an RFC, design doc, code, etc.
Might be good to have a fallback in the spec, something that emails abuse@domain.com perhaps.
Here's a high-level outline for such a protocol:
1. Introduction
- Purpose of the protocol
- Scope of the protocol
- Definitions and terminology
2. Protocol Overview
- Explanation of the protocol flow
- Roles and responsibilities of the involved parties
3. Identification and Verification
- Process for identifying and verifying the reporting entity
- Use of digital certificates or other secure methods for verification
4. CSAM Reporting Mechanism
- Detailed description of how to report CSAM
- Required information in the report (e.g., URL of the image, timestamp, any additional context)
- Use of secure and encrypted communication channels for reporting
5. Image Host Response
- Process for the image host to verify the report
- Steps for the image host to take upon verification (e.g., immediate takedown of the image, reporting to law enforcement)
6. Fallback Mechanism
- Process for sending an email to security@domain or abuse@domain if the primary reporting mechanism fails
- Adherence to ISO 29147 guidelines for vulnerability disclosure
7. Audit and Compliance
- Regular audits to ensure compliance with the protocol
- Penalties for non-compliance
8. Privacy and Security Considerations
- Measures to protect the privacy and security of the reporting entity
- Measures to prevent misuse of the protocol
9. Protocol Updates and Versioning
- Process for updating the protocol and maintaining different versions
10. Conclusion
- Summary of the protocol
- Contact information for queries related to the protocol
This is a high-level outline and each section would need to be expanded upon with detailed procedures and technical specifications. It's also important to involve legal, technical, and child protection experts in the development of the protocol to ensure it is effective, lawful, and ethical.
Shouldn’t be hard to put out a call for more help.
First draft, just needs some more eyes
https://gist.github.com/geeknik/27b2d44cd28551523a3c8927267a17fe
The issue isn't as much with reporting, as it is about dealing with the reports.
You either automate it, and it's easily abused. Or you're doomed to ultimately end up with a giant backlog or reports you can't go through in a timely manner.
At least with a protocol hosts can at least start to automate this stuff and get them thinking about solutions, instead of random email complaints
Creafree developed a free global standard for intellectual property that could be easily implemented on Nostr.
https://drive.google.com/file/d/1o_SSwAQnCMoKmexeb1M9t7UPHCfjTZsb/view?usp=sharing.