Create runbook for handling reported media

[stacimc]

Current Situation

WordPress/openverse-catalog#513 adds Slack reporting of reported media, with links to the Django admin page where these media can be manually reviewed and de-indexed/etc if necessary. There is however no clear process or SLA documented for this.

Suggested Improvement

We should write a runbook for handling reported media which should address:

• SLAs for when media reports need to be addressed
• Explicitly assign responsiblity for handling reports
• Explicitly document rules for addressing the various kinds of reports (DMCA, mature content, 'other')

As part of this work we may find that the current Slack configuration is no longer optimal; for example we may want to direct the alerts to a different channel.

Implementation

• 🙋 I would be interested in implementing this feature.

[zackkrida]

A great next step would be for us to write a post about our moderation requirements so we can share them with the broader community and make our ask for help clear. The more we can document clearly the easier it will be to make this work hapen outside of the Openverse team. Some questions I have around this are:

• How frequent are our image reports? Can we quantify how much work we'd be sending to an existing moderation team?
• What does the report handling workflow look like? For example, will it require Django admin access? Does the Django admin have a way to limit access to specific pages?
• How can we make the workflow as simple and fast as possible?
• How do we follow up with folks who have reported media?
• Can we automate sending media reports to the providers?

My last two thoughts are on the facilitation of this work:

• Who would be interested in taking on some of this work, and finding answers to the above questions?
• Should we move this issue to the main repo?

[sarayourfriend]

For example, will it require Django admin access? Does the Django admin have a way to limit access to specific pages?

Quick responses to this: I think yes for the first one and I know that the second is also possible. Django admin has tight integration with its wider permissions system. We would want to create a "report handler" group that has access to the requisite Django admin views.

How do we follow up with folks who have reported media?

Additional question to this (I think it's implied but would be helpful to be explicit): do we need to follow up with reporters? If so we'll need to start collecting contact info for reports.

Another question: how can we implement Cloudflare cache busting tool to remove reported media from our cache. Are there cost implications for this that we need to be aware of?

[zackkrida]

This is probably a suitable place to go over these questions in depth 😄

How do we follow up with folks who have reported media?

We likely don't need to, with exception for the case of DMCA/copyright requests. In those cases it seems to make sense to email folks with something like 'We received your takedown request and the image has been removed/kept/whatever'. I think those reports are exceedingly rare, which may inform how automated we'd like our response to be.

How can we implement Cloudflare cache busting tool to remove reported media from our cache. Are there cost implications for this that we need to be aware of?

There aren't any direct costs associated with cache-busting, we would just want to do it in a way that minimizes hits to our origin servers. For example, if we remove image 'A', on first glance we might want to bust the cache for:

• Image A's thumbnail
• Image A's detail response
• Any search that might display image A

The last point is impossible, so instead we'd have to bust the cache for all image searches, which would be hugely undesirable. Instead, the frontend could just exclude images whose thumbnail endpoints 404 from the search pages, or something.

We can probably set up something programmatically in the Django admin pretty easily with the Cloudflare API.

[sarayourfriend]

I'm closing this in favour of the #383 project, which supersedes the approach assumed by this issue.