CSAM hashes from failed policies: What does it mean for programmers

 

Author: Carolina Christofoletti

Link in original: Click here

Disclaimer:

This article is part of the (hereby funded) Insight Series, which will be composed of articles aimed at examining, with concrete data visualization proposals, how a single database (known hash matches, later divided in two subsections) could contribute to improving CSAM policies in platforms that rely on, at some level, hash technology to detect CSAM content hosted or posted in its channels.

For terminology purposes, I will separate, within the known hashes set, what I will call “CSAM hashes from failed policies”. By that I mean, only, CSAM files that platforms only recognize when their hash values are updated to the platform’s databases. You could also name it “hash dependent files”.

For consistence purposes, the same terminology will be kept within all articles and, always where needed, new terminologies and neologisms will be explained.

The original program for that is:

1. CSAM hashes from failed policies: What does it mean for programmers
2. CSAM hashes from failed policies: How to measure how long they survive, after being hashed, on the platform.

There is, also, another insights that could be derived from the visualization of CSAM known hashes as a whole.

3. Hash matches: Could they reveal what kind of files are circulating on the Dark?

4. Hash matches: Could they reveal how CSAM sharing evolve across industry?

Considered that, let us start with the first one: CSAM hashes from failed policies: What does it means for programmers 

_______________________________________________________________________

Transparency Report data is, most of the time, not so clear as we wished they to be. In order concretize my point, I would need than to extract, preliminary, this data via mathematics. Though this introduction may seem boring to some readers, it is absolutely necessary for arguing the point I want to show you today.

According to Google’s last Transparency Report, Google and YouTube reported, together, 2,904,317 pieces of content to NCMEC between July and December 2020, having contributed to 1.449.284 CSAM hashes to the NCMEC database, which will later on inform, together with other hash partners, industry hash lists.

That means that maximal 1.455.033 (2,904,317-1.449.284) known hashes have been identified in Google and YouTube platforms. Considering that, in this statistic represents the number of contents reported to NCMEC, which includes images, videos, but also known links to CSAM content and texts in which those materials are solicited, we may expect this number to be a little lower.

While such discrimination between YouTube and Google data does not exist to new material data, where the two platforms seem to be part of a single statistic (with 1.449.284 new CSAM material hashed and reported to NCMEC), old hashes are built (with the application of a specific filter) into two different statistics in Google last transparency reports.

From all items reported to NCMEC between July 2020 and December 2020, Google contributed to 2.804.726 of them. YouTube to 99.591 of them. For following the argument, it would have been necessary to filter, among this data, what is (solely) old hashes, meaning videos or images that were found on the platform. 

When we first face this numbers, the first thought is that, if there is a CSAM hashing technology being applied to the platform and if known files are being immediately removed, the situation must be really out of control, for this data shows that criminal are still highly active in trying to upload CSAM to platforms as such, and variance in temporal settings would mean periods of time in which they were more active. This conclusion is though, biased. 

It is biased because hash lists are being constantly updated and, the time a new hash enters the platform code, the platform is being scanned for this new content which is, sometimes, found to have been hosted in the platform until that very time.

For this is a data that has great implications for statistics, it must be also fragmented: Between the known hashes, platforms should start displaying how files that the platform was hosting do hash matches found, and how many new upload attempts did the hashes matches “scanners” found.

But why would anyone be interested in that? Mainly, because this is exactly the data that indicates how long do CSAM files survive in platforms, until their hash comes to the database.

For Trust & Safety teams, this is exactly the data that could indicate where their operational artificial intelligence and content moderation policies failed. After all, the file came first to light when the hash appeared.

Together, YouTube and Google hashes 1.449.284 pieces of new material. Between the approximate 2.904.317 pieces of known CSAM that the platform found, some amount of that is what I now call “CSAM from failed policies”. And we absolutely need to filter this data.

Maybe, criminals tried to upload 500,000 pieces of known content, being the other half CSAM files that the platform discovered after the hash was set to run in the platform. Maybe, this “CSAM from failed policies” data is much lower than we think: Maybe, we are talking about 10 files with. 1000,000 copies each, maybe about 1000,000 files with 5 copies each.

Independently, this is the dataset that shall be, first, given to AI programmers to analyse it. What happened to these files that they are hash dependent?