Over productreviews en het bespreken van bedrijven

benzinepomp-prijs-vast.pngHet bouwen van vergelijkingssite is de laatste tijd populair, ik krijg er in ieder geval opvallend veel vragen over. Zou het met de crisis te maken hebben? In ieder geval, het levert leuke juridische kwesties op, zoals de vraag of je een bedrijf tegen diens zin in je vergelijker op mag nemen, en vooral de vraag wat je mag en moet doen met recensies.

Want prijzen zijn leuk, maar als lezer wil je toch liever weten wat nu de beste winkel, de handigste telefoon of het grappigste spel voor je spiksplinternieuwe Wii (jaja, kerstkado) is. En nog liever hoor je waar je de slechtste service, botste horken of langste levertijd krijgt, zodat je die winkels kunt mijden. En dan wordt het pijnlijk, want winkeliers hebben weinig behoefte om in zo’n overzicht te staan. Welke grenzen heb je nu als beheerder van zo’n site?

Het staat iedereen vrij zijn mening te geven over een winkel, of die winkel daar nu op zit te wachten of niet. Je mag dus gerust een platform bieden voor meningen over winkels, of over bedrijven of producten natuurlijk. Als beheerder ben je niet aansprakelijk voor die meningen, mits je ze maar niet vooraf modereert of controleert. Wel moet je optreden bij (terechte) klachten.

Als een bedrijf komt klagen, zal dat meestal zijn omdat iemand negatieve kritiek heeft. Negatieve kritiek mag, maar die moet wel gefundeerd zijn in de feiten. Het is dus een goed idee om bij recensies de eis te voeren dat negatieve kritiek op jouw verzoek onderbouwd kan worden met bewijs. Het bedrijf de mogelijkheid van een weerwoord bieden is ook erg belangrijk, als een bedrijf zich niet kan verdedigen tegen kritiek, heeft het sneller een juridische claim. In het Garagetest-vonnis zorgden deze maatregelen dat het forum niet aansprakelijk was voor negatieve recensies.

Verder: je mag bedrijfs- of productlogo’s tonen, mits je dat maar op een nette en zakelijke manier doet. Toon ze dus bij alle bedrijven of producten uit een categorie, en vermijd alles waarmee mensen kunnen denken dat jij een zakelijke band met het bedrijf hebt. Houd logo’s dus klein en zet ze niet vlak naast je eigen logo. En vraag je af of je dat logo echt wel nodig hebt. Kun je niet volstaan met het gewoon typen van de naam?

Een ander goed idee is het monitoren van IP-adressen van plaatsers. Daarmee kun je mensen herkennen die onder verschillende namen steeds hetzelfde bedrijf afkraken – of juist ophemelen. Het zal niet de eerste keer zijn dat een bedrijf zichzelf de hemel in prijst onder naam van een zogenaamd tevreden klant. Of juist de concurrent consequent de grond in boren. Met zo’n controle kun je dat opsporen en tegengaan (bv. met een IP-ban). Je moet trouwens wel in je privacyverklaring melden dat je dit soort dingen doet.

Je hoeft dus geen toestemming te vragen aan een bedrijf om het bedrijf of diens producten in je vergelijkingssite op te nemen. Het kan wel, alleen kun je je afvragen waarom een bedrijf daar toestemming voor zou geven. Zeker als je in het contract zet dat je ook negatieve kritiek zult plaatsen. Als bedrijf zou ik niet weten waarom ik dat zou accepteren. Dit bleek in 2004 bij Telecomvergelijker een probleem bijvoorbeeld.

Komt er ondanks alles een klacht, al dan niet in dure juridische taal met veel “verzoek en voorzover nodig sommeer” en “mogelijk onrechtmatig”, haal dan eerst eens diep adem. Als je je aan bovenstaande houdt, loop je weinig risico. Onderzoek de klacht, en informeer zo nodig bij de klager of het wel klopt wat hij schreef. Bied het bedrijf aan een weerwoord te plaatsen, het liefst bij de recensie zelf in plaats van onderaan als reactie nummer 385 (zoals ik deed bij RWE Energie). En bekijk dan hoe je het op een minnelijke manier kunt oplossen.

Hoe zouden jullie omgaan met klachten van boze bedrijven? Stel dat de klager terugmailt dat het echt waar is maar verder weinig medewerking vertoont, wat doe je dan?

Arnoud

30 reacties

  1. Ik had zoiets laatst: in het forum van mijn website Carri?retijger (zie link op mijn naam) waarschuwden twee leden sollicitanten voor kwalijke werkgeverspraktijken bij een bepaald bedrijf. Waarop ik een klacht kreeg van het bedrijf dat er sprake was van “laster danwel smaad”.

    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.

  2. Een van onze forumgebruikers had een foto geplaatst. Hier kregen we later een klacht over. De persoon beweerde de auteur te zijn van de foto, dat de foto onder een CC licentie en citeerde het deel waarin de voorwaarde was opgenomen dat de auteursnaam genoemd moest worden. Wij hebben toen niet gedaan waarom gevraagd werd omdat de klager geen enkele onderbouwing gaf. We hebben in correspondentie gevraagd om de auteursnaam en een link naar de plek waar de foto aangeboden zou worden, maar hebben daarop geen antwoord gehad.

    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.

  3. Gouden kansen met How To-economie

    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. )

  4. Ik zie in dat artikel over privacyverklaringen de volgende tekst staan:

    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.

  5. @SvdB: er bestaat niet iets als “de” MD5-hash van een ip adres; immers, bereken je een hash over de 4 bytes van het adres of van de tekstuele representatie, of een van de andere variaties die vast nog wel mogelijk zijn?

    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.

  6. @Mrten: Ik heb het bewust niet gehad over de representatie van het IP-adres of het gebruik van salt, want het is irrelevant voor mijn argument. De beheerder van de site weet in welke vorm het IP-adres is gehasht en welke salt er (al dan niet) gebruikt is. Het genereren van de lijst van hashes van alle mogelijke IP-adressen kan met dezelfde representatie en hetzelfde salt gebeuren. Welliswaar kan iemand die alleen de hash weet deze niet herleiden tot een IP-adres, voor de beheerders van de site is het nog altijd herleidbaar tot een IP-adres, en is daarmee dus een persoonsgegeven. En dat is waar het hier om gaat. Al encrypt je de persoonsgegevens met een PKC-encryptiemethode — waar je dus een aparte sleutel voor encrypten en decrypten hebt, en dus alleen de bezitter van de private key (welke niet op de webserver hoeft te staan) de persoonsgegevens kan terughalen — je blijft persoonsgegevens opslaan.

  7. @SvdB: inderdaad is het met zo’n tabel mogelijk een MD5 terug te vertalen naar een IP-adres. Maar de wet eist niet dat het onmogelijk moet zijn, enkel dat het ‘eenvoudig’ is om het gegeven terug te vertalen naar een specifiek persoon. Ik vraag me af of een set rainbow tables als ‘eenvoudig’ telt. (Een IP-adres (met tijdstip) is ‘eenvoudig’ terug te vertalen, aldus het CBP, omdat je naar de provider kunt met een gerechtelijk bevel of omdat je via Google of anders met dat IP-adres sporen terug kunt vinden. Dus wie weet. Je bent wel de eerste die dit verzint trouwens.)

  8. Je hebt geen rainbow tables nodig (noch zou je er veel aan hebben als er een salt gebruikt wordt). Gewoon ??n voor ??n alle IP-adressen proberen. Zelfs met een ongeoptimaliseerde MD5-implementatie op een standaard PC verwacht ik dat je het IP-adres vindt in minder tijd dan het kost om zo’n gerechtelijk bevel te regelen. En het schrijven van een loopje dat de MD5-functie voor alle IP-adressen aanroept is voor een beetje programmeur ook een fluitje van een cent. Dus ik zou het opzoeken van een IP-adres bij een MD5-hash “eenvoudig” noemen.

    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”?

  9. Ach ja, dat is ook zo, er zijn maar zo weinig IP-adressen dat je dat eenvoudig kunt brute forcen. Wat denk je, zou het bij IPv6 ook nog zo eenvoudig kunnen?

    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?

  10. Volgens de Duitse rechter is een IP-adres geen persoonsgegeven in de zin van Richtlijn 95/46/EG, dus ook geen persoonsgegeven in de zin van de Wbp. Het herleiden van een IP-adres tot een persoon kan volgens deze rechter namelijk niet zonder onevenredige inspanning:

    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.

  11. @arnoud(9): Een 128 bits getal is natuurlijk niet zo gemakkelijk te brute forcen als een 32 bits getal. De computer zal er 2^96 keer langer over doen. Als ik het aan mijn 286 over zal laten dan doet ie er wel een tijdje over zal doen, maar ik denk dat het voor een moderne computer nog heel goed te doen is.

    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.

  12. @bona fides: de rechter lijkt er vanuit te gaan dat de provider de gegevens moet afgeven voordat het IP-adres een persoonsgegeven wordt. Maar de Artikel 29-werkgroep redeneert nu juist dat de provider de gegevens zelf kan gebruiken, ze kunnen intern immers precies zien wie welk IP-adres gebruikte. Daarmee is het volgens de werkgroep al een persoonsgegeven nog voordat afgifte plaatsvindt. Tijd voor een prejudiciele vraag?

  13. Ik denk dat Alex de grootte van het getal 2^96 onderschat? Neem een schaakbord met 96 velden. Leg op het eerste veld 1 korreltje rijst. Op het tweede veld 2 korreltjes rijst. Op het derde veld 4 korreltjes rijst. Ga zo verder tot en met veld 96. Dan praten we verder.

    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.

  14. MD5 is gekraakt, zie de referenties op http://en.wikipedia.org/wiki/MD5#Vulnerability .

    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.

  15. Maar ja, als je zo’n lijst bouwt ben je weer persoonsgegevens aan het verwerken (aangenomen dat een IP-adres een persoonsgegeven is, maar die aanname was de aanleiding voor het toepassen van een hash).

  16. Naar mijn mening is een IP-adres alleen in combinatie met een tijdstip een persoonsgegeven. IP-adressen worden door de tijd heen door andere mensen gebruikt immers. Of is een straatnaam en huisnummer ook per definitie een persoonsgegeven? Ik zou zeggen alleen als uit de context blijkt welke periode het betreft. In 1978 woonde in mijn huis iemand anders, en in 1982 stond het een half jaar leeg.

  17. Tja, het lijkt me dat de Wbp op die manier tandeloos wordt gemaakt. Als je als voorwaarde stelt dat het gegeven direct en gemakkelijk herleidbaar moet zijn naar een persoon, dan heb je met het huisadres, telefoonnummer en geboortedatum van een persoon nog steeds geen persoonsgegeven in de zin van Wbp. Want die persoon kan tenslotte verhuisd kunnen zijn; dus volgens de redenering hierboven zijn de genoemde gegevens alleen herleidbaar als er ook een jaargetal bij staat.

  18. Uit de context blijkt denk ik ook vaak wel om welke periode het gaat. Verder hoef je denk ik niet te bewijzen dat een specifiek gegeven daadwerkelijk herleidbaar is tot een persoon voordat het kan worden aangemerkt als persoonsgegeven. NAW-gegevens zijn normaal gesproken te herleiden tot een persoon, en dat zou voldoende moeten zijn voor de verwerker om zich aan de Wbp te (moeten) houden. Bij een IP-adres is dat wel of niet zo, afhankelijk van wiens redenering je volgt: die van het CBP of die van de Duitse rechter.

  19. @Arnoud: Interessant wat je zegt over het CBP. Ze spreken daar over een derde die de gegevens moet kunnen herleiden tot een natuurlijk persoon. Van een cryptografische hash bij gebruik van een geheim salt is dat niet mogelijk. Maar de combinatie “hash van IP adres + salt (+tijd)” zou dan weer wel een persoonsgegeven zijn.

    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).

  20. @SvdB: ik denk dat je gelijk hebt ja, het is een fundamenteel iets. Ik dacht later nog aan een combinatie van IP-adres met een door de gebruiker te kiezen wachtwoord als salt (of voor mijn part simpelweg als pre- of postfix). Dan moet hij dat elke keer opgeven om ‘zijn’ hash te laten maken. Als het systeem dan dat wachtwoord niet opslaat, heb je een unieke ID zonder mogelijkheid deze terug te vertalen naar een IP-adres.

    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.

  21. Even heel wat anders, wat ik wel eens bij beoordelingssystemen heb gezien is dat je bij een reactie een cijfer moet geven. Als het onderwerp op een smadelijke reactie wil reageren, moet deze zichzelf of het hoogste cijfer geven, wat verwaand overkomt, of een lager cijfer, wat niet van zelfvertrouwen getuigt. Degene die zich tegen een smadelijke reactie wil verweren, kan het in dat geval nooit goed doen.

  22. Ik doelde niet op “kwaad” met persistente cookies. Als een site een cookie zet met daarin alleen een uniek, random gegenereerd nummer, dan kan de site aan de hand van de waarde van het cookie (dat bij ieder request wordt meegestuurd) de gebruiker identificeren. De site kan dan in plaats van IP-adressen de waardes van de cookies van alle gebruikers opslaan. Dan heeft de site nog bruikbare gebruikersdata, zonder dat er persoonsgegevens worden opgeslagen.

    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.

  23. N.a.v. het “Garagetest-vonnis”, http://jure.nl/AZ8634, daarin schrijft de rechtbank:

    “[gedaagde 1] c.s. heeft gemotiveerd betwist dat hij geen weerwoord van Auto Heemstede wil plaatsen op http://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.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.