Ik heb de naam van het bedrijf uit de klachten weggehaald, omdat de klachten
anoniem en onverifieerbaar waren, terwijl ze voor een groot deel werden
toegeschreven aan anderen dan de posters (’een vriendin’ e.d.).

In het forum heb ik deze actie toegelicht met: “Misschien zouden we plaatsing van deze klachten
mét de naam van het bedrijf wel willen toestaan als degenen die daar
verantwoordelijkheid voor nemen zich met hun echte naam en adres bij de uitgever
van deze website bekend maken. Ook moeten de klachten dan redelijk onderbouwd
worden, van de schrijver zelf komen en niet worden toegeschreven aan allerlei
anonieme mensen. Het bedrijf krijgt dan bovendien gelegenheid voor een weerwoord
in dit forum. Kortom, een serieuze kritische discussie mag, maar een bedrijf anoniem
aan de schandpaal nagelen mag niet.”

De posters hebben zich niet bekend gemaakt. Als de posters zich wel bekend hadden
gemaakt en hun beweringen enigszins geloofwaardig konden maken, dan zou ik de
naam van het bedrijf hebben terug gezet en ze inderdaad de kans hebben geboden
een weerwoord toe te voegen.

Ik voel er weinig voor om enkel op basis van een klacht te verwijderen. De vrijheid van meningsuiting is een groot goed en iemand die klaagt zal op z’n minst aannemelijk moeten maken dat zijn klacht gegrond is. Ik zou er eerder voor kiezen om persoonsgegeven af te geven of om personen (anoniem) in contact met elkaar te brengen.

Hierbij hield ik in mijn achterhoofd het volgende: een consumententorganistatie heeft onderzocht hoe providers daarmee overweg gingen door bladmuziek van Bach daar onder te brengen en er vervolgens over te klagen. Bijna alle provider haalde de muziek weg om eventuele rechtzaken te voorkomen. Ik vind dat destijds een kwalijke zaak en sta daar nog altijd achter.

29 december 2008 - Door Erwin Boogert / Emerce.nl

“Tutorials, instructievideo’s, recensies en blogreacties nemen de gidsfunctie van Google over. Ze zijn het nieuwe besturingssysteem van het web. Richard Rosenblatt, de man die MySpace verkocht, en oprichter Demand Media (platform en netwerk) heeft een oorlogskas van 355 miljoen dollar om zich deze markt toe te eigenen. Maar er zijn meer liefhebbers. ( … )

( Lees verder Ermerce.nl / Nieuws / 29 dec. 2008 )

Bron:
http://www.emerce.nl/nieuws.jsp?id=2820284

( N.B. Zo aan het einde van het jaar verschijnen er meer bijdragen over de kracht van de massa en uitwisselen van informatie en ervaringen en internet. )

Het is in veel gevallen trouwens net zo makkelijk om geen IP-adres op te slaan, maar een andere identifier te gebruiken die niet meer te herleiden is tot een IP-adres. Gebruik bijvoorbeeld de MD5 hash van het IP-adres. Dan heb je nog steeds een uniek getal voor elke zoekopdracht, maar het is niet meer mogelijk om te achterhalen welke bezoeker de opdracht intypte.

Het klopt niet dat uit een MD5-hash van een IP-adres dat adres niet meer te achterhalen is. Er zijn immers niet meer dan 2^32 mogelijke IP-adressen (bij IPv4). Het is doenlijk om van al deze adressen de MD5-hash te nemen, en dit resultaat te vergelijken met de opgeslagen hash.
Een MD5-hash van een IP-adres lijkt me daarmee ook een persoonsgegeven.

Je hebt wel een beetje gelijk: normaliter gebruik je een ’salt’ bij het berekenen van hashes die je geheim wilt houden, zie wikipedia.
32 bits informatie (het ip-adres) in 128 bits informatie (een MD5-hash) “verstoppen” is een beetje naief. Maar ja, cryptografie is Moeilijk.

Wel grappig: wat nu moeilijk is kan morgen eenvoudig zijn, dus wat je vandaag als niet-persoonsgegevens opslaat, kunnen morgen persoonsgegevens zijn. Wat zegt de wet daarover, reguleert deze de actie van het “opslaan”, of het “opgeslagen zijn”?

In 2000 zei de Artikel 29-werkgroep hierover:

Zoals reeds in dit document is opgemerkt, kunnen internetaanbieders en beheerders van lokale netwerken zonder veel moeite internetgebruikers identificeren aan wie ze IP-adressen hebben verstrekt, doordat ze als regel systematisch de datum, het tijdstip, de duur en het verstrekte dynamische IP-adres van gebruikers in een logbestand vastleggen. Hetzelfde geldt voor internetdienstverleners die een logboek op de HTTP-server bijhouden. In deze gevallen is het buiten kijf dat men kan spreken van persoonsgegevens in de zin van artikel 2, onder a), van de richtlijn.

In de richtsnoeren van ons eigen CBP worden IP-adressen als persoonsgegevens aangemerkt omdat “het door een derde – de internetaanbieder– eenvoudig te herleiden valt tot een natuurlijk persoon, de afnemer van het internetabonnement.”

Verderop zeggen ze “Geanonimiseerde gegevens zijn geen persoonsgegevens als de betrokken personen redelijkerwijs niet identificeerbaar zijn. … Zolang de gegevens echter zonder onevenredige inspanning herleidbaar blijven naar natuurlijke personen, door de verantwoordelijke of door een derde, moeten ze als persoonsgegevens worden behandeld.” Men verwijst naar een rapport uit 2007 van die Artikel 29-werkgroep, waarin “onomkeerbare hashfuncties” als ‘passende technische maatregelen’ genoemd worden waarmee je gegevens kunt pseudonimiseren:

Zelfs als bepaalde betrokkenen in dit geval ondanks al die protocollen en maatregelen kunnen worden geïdentificeerd (…), kan de informatie … niet worden geacht betrekking te hebben op personen die geïdentificeerd zijn of identificeerbaar, rekening houdende met alle middelen waarvan mag worden aangenomen dat zij redelijkerwijs door degene die voor de verwerking verantwoordelijk is dan wel door enig ander persoon in te zetten zijn. (cursivering in origineel)

Het is dus weer de bekende redelijkheidstoets.

Zie jij een manier om een IP-adres te mappen naar een unieke ID zodanig dat een derde die de mapping en de output te pakken krijgt, deze niet ongedaan kan maken?

Die Beklagte könnte den Nutzer nur mit Hilfe des Access-Provider ermitteln, der aber mangels Rechtsgrundlage den Betreiber eines Internetportals diese Angaben nicht zur Verfügung stellen darf. Die theoretisch mögliche, aber illegale Möglichkeit einer Identifikation des Nutzers durch den Access-Provider und Weitergabe der Daten an die Beklagte als Portalbetreiber kann vorgeschilderter Definition der Bestimmbarkeit der personenbezogenen Daten nicht entsprechen. Eine solch illegale Handlung kann kaum als normalerweise und großen Aufwand durchzuführende Methode angesehen werden.

Het is trouwens niet juist om te beweren dat met dergelijk one-way algoritmes een uniek getal op leveren. De veiligheid van dit systeem zit hem nu juist dat ze geen uniek getal op leveren. Twee dezelfde 32 bits getallen kunnen het zelfde zoveel bits getal op leveren, maar dat is niet erg waarschijnlijk.

MD5 is trouwens onveilig, omdat het o.a. kan voorkomen dat het getal dat er in gaat het zelfde is aan het getal wat er uitkomt. Er zijn algoritmes op de markt die een groter getal op leveren en waarbij het langer duurt voordat de uitkomst bekent is. SHA2 bijvoorbeeld.

Ik zeg niet dat het voorgestelde systeem voor IPv6 niet te kraken is, maar je zult slimmer moeten zijn dan brute force.

De veiligheid van MD5 zit er mijns inziens trouwens in dat het “for all practical purposes” een uniek getal oplevert. Theoretisch kun je duplicaten tegenkomen, maar de kans daarop is verwaarloosbaar. Zodra je een voldoende flexibele methode hebt om duplicaten te maken, wordt MD5 waardeloos. Je kunt dan namelijk documenten vervalsen.

MD5 is trouwens onveilig, omdat het o.a. kan voorkomen dat het getal dat er in gaat het zelfde is aan het getal wat er uitkomt.

Hoe bedoel je dat? De input is normaal gesproken langer dan de output. Met 32-bit input natuurlijk niet, maar die zou je eenvoudig kunnen aanvullen. Verder zou het me zeer verbazen als er met 32-bit input hetzelfde getal uit zou kunnen komen, maar misschien ben ik niet goed op de hoogte van de zwaktes van MD5.

Je zult bij IP6 wel iets meer nodig hebben inderdaad dan brute force. Je zou slim kunnen gokken, als IPv6-adressen bijvoorbeeld per land vaak beginnen met een bepaalde prefix, dan kun je de Chinese IP-adresrange alvast weglaten als je weet dat je met een Nederlander te maken hebt. Wat je weer kunt afleiden uit de taal van zijn forumberichten bijvoorbeeld.

Met IPv6 zal brute force op alle mogelijke adressen inderdaad (vooralsnog) niet realistisch zijn. Maar *de derde*, de internetaanbieder, kan wel weten welke adressen in gebruik zijn, en kan alleen op die adressen een brute force attack uitvoeren.

Zie jij een manier om een IP-adres te mappen naar een unieke ID zodanig dat een derde die de mapping en de output te pakken krijgt, deze niet ongedaan kan maken?

Dat lijkt me onmogelijk, aangezien dezelfde mapping op alle IP-adressen uit te voeren is. Je zou een mapping kunnen gebruiken die lang duurt om uit te voeren, zodat een brute force attack niet realistisch is, alleen is het een kwestie van tijd voordat dit niet meer het geval is (want snellere hardware).
Maar andere, niet-enumeerbare eigenschappen zouden wel gebruikt kunnen worden om een persoon uniek te identificeren. Zo zou er een cookie gezet kunnen worden wat behouden blijft over meerdere sessies (via Flash bijvoorbeeld).

Het gaat er mij dus om hoe een systeembeheerder een authenticatie kan bouwen waarbij mensen persistente identifiers krijgen die geen persoonsgegeven in de zin van de WBP opleveren. Als je kwaad wilt, kun je inderdaad altijd wel wat met cookies, hidden fields, stiekeme scripts of verborgen frames.

Ik noemde Flash omdat HTTP cookies tegenwoordig door veel browsers kunnen worden weggegooid aan het einde van een sessie, terwijl je Flash “cookies” niet zomaar kwijtraakt.

Niet dat ik hier zelf als gebruiker tevreden mee zou zijn, aangezien ik alsnog geïdentificeerd kan worden aan de hand van mijn gebruikersgedrag (bv. zoektermen in een search engine). Naar mijn mening zou het het beste zijn wanneer logs na korte tijd worden weggegooid.

Een lezer vroeg me:

Door de komst van het internet zijn er allerlei sites ontstaan zoals iens.nl. Sites die gegevens verzamelen over bedrijven en gebruikers de mogelijkheid geven om hun mening te geven.
Iens doet dit voor de horeca. Recent ving ik ee…

“[gedaagde 1] c.s. heeft gemotiveerd betwist dat hij geen weerwoord van Auto Heemstede wil plaatsen op www.garagetest.nl. Het weerwoord, waar Auto Heemstede op doelt, zo heeft hij uiteengezet, was afkomstig van de computer van Auto Heemstede waarvan het e-mail adres uit anderen hoofde reeds was geblokkeerd. Auto Heemstede heeft hier tegenin gebracht dat zij het bericht niet vanaf haar eigen computer heeft verstuurd.
”

Kennelijk dachten rechtbank en garage in februari 2007 dat e-mailadressen rechtstreeks gekoppeld zijn aan een bepaalde computer. Dat is niet het geval. Zelfs IP-nummers en computers hoeven in principe niet altijd een-op-een overeen te komen.