For her safety, Doe has opted to receive alerts from the US Department of Justice Victim Notification System any time she may be a victim in a new criminal investigation. Although she has received countless alerts, she was shocked when the CCCP notified her that it had identified AI-generated CSAM on xAI that depicted her. This re-traumatized Doe, whose complaint alleged that messages were found on online forums “between offenders chatting about creating AI generated CSAM of Plaintiff and other similarly situated known, legacy, victims of CSAM.”
Now, Doe fears that xAI has not only made it easier to make more violative images of the most distressing time in her life, but also that xAI allegedly has stored the images that Grok generates and uses those outputs to further train Grok. Because of this, she believes that Grok has been trained on both the initial set of images that have haunted her for more than 20 years and the more recent AI-generated ones.
This is the first case to accuse xAI of training on CSAM, and the complaint does not go into great detail on that claim. Previously, Ars reported on a controversial dataset that was later scrubbed after researchers found CSAM in the training data, but there’s no indication xAI trained on that data. In a press release from lawyers representing Doe, it explained that Doe’s images were included in a CSAM Hash List maintained by NCMEC, and “that same material” allegedly “was part of the dataset xAI used to build Grok’s image and video generating capabilities.” The complaint similarly only alleged that “CSAM depicting Plaintiff with its longstanding well-known hash values has been used as a part of the dataset used by xAI.”
Close, but not quite. A hash is better understood as a “fingerprint” for a given piece of data. Any given input will produce the same length of output, so it doesn’t really “reduce” information - a hash of “Hello world” would actually be significantly longer - but rather it identifies a matching piece of data.
This has a number of uses. For example,if you have a password system on a website, you don’t store a user’s actual password. That would be terrible for security. Instead you store the hash (yes, salted, for that one pedant who was about to interject). Then when the user enters their password to log in, you hash the entered password and compare it to the stored hash. If they match, you know they’re the same string. You can also create a hash of a file and provide that along with the file itself. If the receiver also hashes the file, they can then compare their hash to yours; if they don’t match, the file is corrupt or has been tampered with. You’ll often see this referred to as a checksum.
Technically, the reproducible data from a hash should be zero, so they don’t so much contain information as verify it. But as we’ve seen from that research, there are ways around that (not the only ones, to be sure). But the idea in theory is that you produce a hash through a one-directional algorithm; very easy to compute A from B, but very, very hard to compute B from A.
It should be noted that this is very different from stenography, which is a variety of systems for storing data, not fingerprinting it. Hashing is also distinct from encryption as a means of securing data, because encryption is intended to be reversible, hashing is not.
I’ve seen and used fixed length output on hashes, I assumed that is more common than variable length output.
I would not trust variable length output, and it looks like they screwed up their math enough that the function is reversible.