Hoe ga je iets vergelijken, met een algoritme als het op voorhand al met encryptie binnen komt? Dit gaat niet werken, daarom is het ook end to end, en niet alleen op hun servers.
Je kan versleutelde data wel vergelijken mits de soort encryptie dat toelaat. (Vergelijk dat ECB-versleutelde plaatje van tux voor een idee.) Dat is wel een zwakte in de encryptie natuurlijk, en om dat dan weer tegen te gaan worden er willekeurige nonces en dergelijke ingezet. Maar dat kan je ook niet doen. Daarnaast is het natuurlijk duidelijk dat als de ontvanger niet kan ontsleutelen dat die dan helemaal niets aan het plaatje heeft.
Maar let even op, het gaat hier over "gesloten groepen met publieke uitnodiging". Ik weet niet hoe de sleuteldistributie werkt bij whatsapp maar het lijkt me dat je checkservers prima lid kan laten worden van zulke groepen. De uitnodiging is immers aan iedereen.
Daar hoef je niet eens voor te rommelen in client software of zelfs het OS. Dit kunnen anti-kinderpornogroepen heel goed zelf: Zoek de publieke uitnodigingen, voer ze aan je checkserver, die volautomatisch alle plaatjes in de groep checkt.
Lijkt me een veel minder groot sleepnet dan maar gewoon iedereen met een permanente checker op al z'n plaatjes op z'n eigen telefoon op te zadelen. "Telefoon kan plaatje niet opslaan want geen dataverbinding om het plaatje door de checker te halen." Ja, nee, wat?
Op de telefoon het doen voordat het encrypted is, gaat ook niet werken, dit zet de deur open voor misbruik, koud kunstje om voor FB een tweede connectie dan open te zetten en je chats lekker binnen te halen, allemaal in de naam van “scannen”
Daar kom je niet onderuit, niet bij servers en niet bij clients.
Dat staat nog naast het feit dat een cliënt scanner, CPU van je telefoon zal gaan gebruiken, dat is ook minder fijn
Hash trekken en opsturen naar een checkserver want ze gaan natuurlijk niet de hele lijst rondbazuinen. Zo'n hash voor een enkel plaatje is wel te doen, vergelijkbaar met het plaatje versleutelen voor transport naar de andere leden van de groep, of weer ontsleutelen bij ontvangst. Maar de checkserver krijgt bij iedere post een check-aanvraag van iedere ontvanger, dus die kan gelijk precies zien wie er nog meer in de groep zit.
Zo'n lijst is overigens op zichzelf ook een risico. Zo bleek er op de Australische lijst van hashes van kinderpornowebsites ineens de website van een tandarts te staan, die geen idee had waarom er niemand meer op z'n website kwam (en wat 'm dus klandizie kostte) want de lijst is geheim. Alle andere landen met vergelijkbare lijsten hebben vergelijkbare problemen, ook al houden ze die ook geheim.
Zo kan ik me voorstellen dat als er iemand met (indirecte) schrijftoegang op de hashesdatabase kwaad wil, die natuurlijk gewoon hashes kan trekken van het hele fotoalbum van zijn doelwit en die in de database kan storten. Geen hond die kan zien dat de bronfotos geen kinderporno zijn want hashes.
Om nog maar te zwijgen van "near matches" die dartelende kindertjes in kinderbadjes ("naakt!") erbijpakken en zo de whatsapgroep van de buurtmoeders twee straten verderop als grote bron van kinderporno aanmerken. Hoe ga je ervoor zorgen dat ze niet ondertussen als pedofiel gebrandmerkt worden? Ik noem maar een dwarsstraat. Je zal dus altijd heel zorgvuldig met de hand na moeten kijken of je niet toevallig tegen collissions aankijkt, of dat er een andere reden is waarom het volautomatische checksysteem mischien steekjes heeft laten vallen. Dat wordt hier, maar ook bij andere toepassingen van hetzelfde idee zoals "cloud storage", website hosting, en zo verder, maar al te gemakkelijk vergeten.
Dus zo'n panacea is die hashesdatabase zelf ook weer niet. Wat mij betreft is dit gewoon weer zo'n dom idee dat maar niet wil sterven, en daarmee een goede intentie die de weg naar de hel helpt te plaveien.