3 ms·
> You can't effectively scan for prohibited content on the client side for several reasons: I disagree. I think these scanners can only be good, but never per
by ardy42 7y ago
> You can't effectively scan for prohibited content on the client side for several reasons:
I disagree. I think these scanners can only be good, but never perfect, so they're mainly effective against technically unsophisticated abusers. Weakness that are only exploitable by someone with advanced technical skills are not actually a problem.
> A) someone who wants to send or receive prohibited content could alter the client to skip the checks.
That's true in any kind of scanner. Server side checks could be defeated pretty trivially by using any encoding scheme not anticipated by the scanner's authors (e.g. sending an image as text messages encoded with rot13 Base64). No scanner can be robust against even a mildly technically savvy opponent unless the scanner has complete end-to-end control over everything, including the clients.
> B) shipping the check to the clients makes it possible for distributors to run the checks and alter their content until it passes the checks.
My understanding is those databases and algorithms are not secret information, but are publicly available to provide low barriers to implementation, so someone could download one and do what you propose now.
- bastawhiz 7y ago> I disagree. I think these scanners can only be good, but never perfect, so they're mainly effective against technically unsophisticated abusers Assuming the checks are not hash-based (literally any mutations to a file make these worthless, and the libraries of hashes of illegal content are gigabytes and growing), the computing power required on the client side is infeasible to ship in a product intended for any modest consumer hardware. Let's assume this is limited to child pornography only. You first need to store some perceptually-encoded version of _every_ illegal image on the user's device (in such a way that it's impossible to reverse-engineer one of the images back out). Then you need to try to match the image being sent against each of the encoded versions of each of those images. On a server farm, that's _maybe_ practical. On someone's crappy Samsung Galaxy phone from 2013, it would take days or weeks to process a single image. Let's assume it _was_ some hash based check. People complain that the Facebook Messenger app is over a hundred megabytes. Do you think someone is going to download the Signal client onto their phone with a gig of file hashes so that they can get reported to the police in the event that one of their images has a prohibited hash? No, that's crazy. And even if it _was_ feasible, Signal is open source [0]. It would take a single person maybe a day of works tops to create a version without those restrictions and throw an APK onto a static website. [0] https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Android