Recent searches
Search options
In what is hopefully my last child safety report for a while: a report on how our previous reports on CSAM issues intersect with the Fediverse.
https://cyber.fsi.stanford.edu/io/news/addressing-child-exploitation-federated-social-media
Similar to how we analyzed Twitter in our self-generated CSAM report, we did a brief analysis of public timelines of prominent servers, processing media with PhotoDNA and SafeSearch. The results were legitimately jaw-dropping: our first pDNA alerts started rolling in within minutes. The true scale of the problem is much larger, as inferred by cross-referencing CSAM-related hashtags with SafeSearch level 5 nudity matches.
Hits were primarily on a not-to-be-named Japanese instance, but a secondary test to see how far they propagated did show them getting federated to other servers. A number of matches were also detected in posts originating from the big mainstream servers. Some of the posts that triggered matches were removed eventually, but the origin servers did not seem to consistently send "delete" events when that happened, which I hope doesn't mean the other servers just continued to store it.
The Japanese server problem is often thought to mean "lolicon" or CG-CSAM, but it appears that servers that allow computer-generated imagery of kids also attracts users posting and trading "IRL" materials (their words, clear from post and match metadata), as well as grooming and swapping of CSAM chat group identifiers. This is not altogether surprising, but it is another knock against the excuses of lolicon apologists.
Traditionally the solution here has been to defederate from freezepeach servers and...well, all of Japan. This is commonly framed as a feature and not a bug, but it's a blunt instrument and it allows the damage to continue. With the right tooling, it might be possible to get the large Japanese servers to at least crack down on material that's illegal there (which non-generated/illustrated CSAM is).
I have argued for a while that the Fediverse is way behind in this area; part of this lack of tooling and reliance on user reports, but part is architectural. CSAM-scanning systems work one of two ways: hosted like PhotoDNA, or privately distributed hash databases. The former is a problem because all servers hitting PhotoDNA at once for the same images doesn't scale. The latter is a problem because widely distributed hash databases allow for crafting evasions or collisions.
I think for this particular issue to be resolved, a couple things need to happen: one, an ActivityPub implementation of content scanning attestation should be developed, allowing the origin servers to perform scanning via a remote service and other servers to verify it happened. Second, for the hash databases that are privately distributed (e.g. Take It Down, NCMEC's NCII database), someone should probably take on making these into a hosted service.
Integrated reporting to NCMEC's CyberTipline would make life easier for admins and increase the likelihood that those reports get filed at all. Even without attestation, the big instances should all be using PhotoDNA; it's unclear if anyone on the Fediverse is even doing this, given that they'd have to manually hack it in. UI needs to be added to mainline Mastodon to allow for that—it's a very simple pair of REST calls that just need a couple auth tokens.
@det is PhotoDNA AGPL? If not, there is zero reason to trust it does what it says it does, and isn't also searching for politically dangerous content, and alerting authorities in those countries, many of which are openly hostile to individual liberties.
@det I wrote about my vision on these topic, as a (new) Mastodon team member: https://renchap.com/blog/post/evolving_mastodon_trust_and_safety/
The big issue is: we dont have enough resources :( There is only 1 full-time dev on the project, I am working far too many hours per week as a volunteer, Eugen has many other duties, and we are struggling to keep up with maintenance work, so big features like this, that we want, are very hard to develop.
Hopefuly we will be able to get more money, but for now, this is very hard.
@det I would be happy to discuss this further with you if you want :)
@renchap An unenviable position for sure. I've wanted to have some of our research assistants write T&S tooling for Mastodon, but since they need to learn Ruby/RoR first and they only have limited hours, it's not come to fruition as of yet.
We do have experience integrating with pDNA/NCMEC/etc though, so I will drop you a line and see if we can be of any help.
@by_caballero @renchap In terms of the code for API calls or PDQ hashing we're happy to share our (fairly basic) Python code if it helps. It's more the UI and glue between front and backend that is harder for new CS + trust and safety students to ramp up on.
Someone should really diff the blocklist between mastodon.social and mastodon.online :-(.
I just found out two domains were missing from the latter. Which are sadly related to this discussion.
I reported them all as such, but it's a demoralizing oversight.
Also a third related domain that wasn't on either, but it was on the Oliphant/Seirdy blocklists. Sucks that we don't seem to have robust co-operation here.
@sourcejedi_ben @det thanks, relayed to our mod team