Iemand die claimt volledige veiligheid te kunnen garanderen is net zo betrouwbaar als een zogenaamd SEO specialist dat de eerste plek in de zoekresultaten kan garanderen. Heel kort gezegd, "niet dus".
Wat veiligheid lastig maakt, is niet alleen het eeuwig durende kat en muisspel met hackers. Veiligheid is makkelijker in een afgeschermende omgeving en een website is dat niet.
Soorten
Er zijn een aantal manieren waarin websites kwetsbaar zijn of kunnen zijn:
(1) Een website kan bestoken worden met een enorme hoeveelheid verkeer dat de server waarop deze website gehost is de druk niet meer aan kan en plat gaat. Dit wordt in vaktermen een Denial-Of-Service (Dos) aanval genoemd. Er zijn betrekkelijk weinig effectieve manieren om dit tegen te gaan. Men kan bijvoorbeeld meer servers inzetten, verkeer herleiden, of lekken in code dichten die veel gebruik makkelijk maken.
(2) Een andere manier is een Cross-site aanval. Met deze aanval wordt een stukje code ingevoerd (vaak Javascript) door de hacker in andermans website. Dat kan tot verschillende dingen leiden, zoals iets simpels als een veranderde achtergrondkleur in de browser tot meer vervelende zaken zoals de browser herleiden naar een website waar bijvoorbeeld een virus op zit.
(3) Een meer vervelende manier die er op gericht kan zijn om wachtwoorden te ontfutselen en het gebruik over te nemen van een website is een brute-force aanval. Hierbij probeert de hacker het wachtwoord te raden door middel van duizenden pogingen. Vaak gebruikt een hacker daarbij een woordenlijst en een soort geautomatiseerde browser en wacht dan net zo lang totdat het wachtwoord geraden is. Oplossingen tegen dit soort aanvallen zijn relatief eenvoudig, zoals een time-out periode na 3 of 5 verkeerde wachtwoorden.
(4) Een subtielere manier is de "SQL injection". In feite wat een hacker hier doet is een stukje code inserteren in bijvoorbeeld een formulier vakje die de hacker de gelegenheid geeft om toegang te krijgen tot de database, waarin dan weer de wachtwoorden liggen opgeslagen. Om dit laatste te voorkomen, moeten alle externe variabelen door filters heen en worden er wat heet "prepared statements" gebruikt.
Waar ligt de moeilijkheid?
Leken zullen nu ongetwijfeld denken, als er dan oplossingen zijn, wat is er dan zo moeilijk? Het is nog niet zo makkelijk code van een systeem goed te schrijven en bijvoorbeeld SQL injection te verhinderen. Je hoeft maar op één plek het te vergeten en je hebt al een lek en een beetje systeem beslaat al snel duizenden regels code. Probeert u maar eens een heel dik boek zelf te schrijven zonder typfouten en u begint te begrijpen dat dit nog niet zo makkelijk is. Dit is dan nog erg gesimplificeerd weer gegeven, anders dan bij een boek, kun je in een programma ook stukken code schrijven die wat syntax betreft in orde zijn, maar wel logische fouten bevatten die lekken kunnen veroorzaken.
Open Source
Anders dan voor custom programma's zijn voor open source systemen deze problemen zo niet nog lastiger. Tuurlijk een custom systeem kan ook lekken bevatten, maar doordat de code vaak niet vrij verkrijgbaar is en dus niet vrij inzichtbaar is, moeten hackers er extra werk in stoppen om te achterhalen waar deze lekken zijn. Bij een open source systeem zien hackers dit al, want de code is vrij verkrijgbaar en dus inzichtelijk. Een hacker hoeft het systeem alleen maar gratis te downloaden, te openen in zijn text-editor en de hacker ziet in de code waar het lek zit. Het is dat feit, dat maakt dat veel van deze open source systemen zo vaak updates ontvangen, want er is bijna altijd wel ergens ter wereld een hacker die een nieuw lek vindt. Vandaar dus het belang van die updates.
Een leek zal zich nu ongetwijfeld kunnen afvragen zijn er open source systemen die er beter in zijn en minder lekken bevatten dan andere?
Eigenlijk is dit een wat zinloze vraag om te stellen en het is ook niet goed te beantwoorden. Er zijn tegenwoordig zoveel verschillende systemen met veel code dat het eigenlijk ondoenlijk is om met volledige zekerheid te kunnen zeggen welke beter geschreven is in termen van veiligheid. Dat neemt echter niet weg dat men er wel over kan generaliseren. Vaak komt er ook andere zaken bij kijken zoals gebruikersgemak of het doel waarvoor het systeem is geschreven en waarvoor het dient, dat maakt, dat het ene systeem wordt verkozen boven het andere. Het moet gezegd worden vaak is dat een erg arbitraire keuze. Misschien is het daarom beter om deze vraag inzichtelijk te maken aan de hand van een voorbeeld.
Voorbeeld
Drupal is een systeem welke oorspronkelijk ontwikkeld is door een Belg. Het systeem was enigszins gebaseerd op het BulletinBoard forum systeem. Systemen die gebaseerd zijn op Bulletinboard kunnen als voordeel hebben voor gebruikersgemak dat bulletinboard code gebruikt kan worden, hetgeen het bijvoorbeeld voor een leek, die bekend is met deze fora makkelijker maakt, om tekst bijvoorbeeld cursief of vetgedrukt te maken. Lees dit overigens goed, ik wil niet zeggen dat het dat heeft, maar dat het dat kan hebben. Dat is een waarschijnlijkheid, maar geen zekerheid. Met andere woorden het is hypothetisch.
In tegenstelling tot Bulletinboard heeft Drupal ooit de naam gehad en bij sommige mensen heeft het dat nog steeds, dat het een betrekkelijk goed beveiligd systeem is. Ik laat voor nu nog even in het midden of dat naar mijn mening ook terecht is. Bulletinboard forums hebben overigens de naam zeer onveilig te zijn. Ook hier laat ik in het midden of dat terecht is.
Het probleem van perceptie
De praktijk is echter weerbarstig. Even los gesteld van de reputatie die Drupal heeft, is reputatie meer iets wat met imago heeft te maken. Anders dan identiteit, is imago iets wat niet op de werkelijkheid hoeft te berusten, maar meer met perceptie te maken heeft. Een perceptie kan juist zijn, maar ook fout. Dat hoeft niet alleen aan het systeem te liggen. Het kan ook aan de gebruiker zelf liggen. Een goede en ervaren gebruiker die een slecht systeem blijft gebruiken, blijft zwak. Vice versa een onervaren gebruiker met weinig reflectievermogen dat in principe een goed systeem gebruikt, blijft vaak zwak. Het is wat perceptie betreft, die beide kanten van de medaille, dat maakt, dat het moeilijk te zeggen is of een systeem nou echt goed of slecht is. Het blijft een beetje appels met peren vergelijken.
Praktijkvoorbeeld
Maar terug naar het voorbeeld van Drupal. Hoe pakt die praktijk uit?
De meeste veel gebruikte systemen hebben tegenwoordig hun eigen security team die lekken dicht, updates maakt en gebruikers hiervan op de hoogte houdt. Buiten die teams om zijn er ook mensen die waarschuwen over lekken. Zo is er in het verleden een Duitser geweest die waarschuwde voor een lek in Drupal versie 7 en dit bekend gemaakt heeft op een website. Die waarschuwing is opgepakt en door diverse media verspreid. Nu zult u denken dat klinkt als goed werk. Getuige een screenshot onder deze alinea, waarin een andere veiligheidsexpert stelt dat oudere versies voor versie 8 kwetsbaar zijn. De bewuste zin is onderstreept in het screenshot. De screenshot is van een Engelstalig artikel afkomstig van Threatpost.
Dat versie 7 serieus kwetsbaar is, is al enige tijd bekend. Het is door diverse internet kanalen bekend gemaakt en meer en meer verspreid geraakt zo rond september 2015 en nogmaals opgepikt in diverse media in januari 2016. Inmiddels (in augustus 2016) zijn er nog steeds websites die versies ouder dan versie 8 gebruiken. Anders dan bij bijvoorbeeld open source systemen zoals Wordpress en Magento kunnen we ook goed zien in de HTML broncode welke versie voor een website gebruikt wordt, omdat het er getoond wordt. Het is om die reden dat ik dus Drupal neem als voorbeeld in plaats van Wordpress. U moet daarom dus niet denken dat ik iets persoonlijk tegen heb op Drupal. Ik neem het systeem alleen als voorbeeld, omdat het zo makkelijk toonbaar is aan een leek.
Kijkt u eens goed naar het rood onderstreepte op de screenshot. Het is een screenshot van de HTML broncode van een hele bekende website. Door goed te lezen en een beetje kennis te koppelen, zou u moeten kunnen begrijpen om welke website het gaat en ziet u aan het nummer dat het inderdaad versie 7 betreft en niet versie 8.
Verificatie in de praktijk
Nou kunt u misschien denken. "Ik geloof u niet." "Deze screenshot is nep." Prima, ongelovige Thomas, zeg ik dan. Ik stel voor dat u even zelf naar de website gaat en de broncode opent van die website in uw browser. U komt bij de broncode door rechtsboven te klikken in de browser en afhankelijk van uw browser naar broncode te gaan of ontwikkelaar.
Als u dat gedaan heeft, ziet u dat het screenshot echt is. Nou zullen er nog mensen zijn die hun ogen niet geloven. Voor hun is misschien het volgende dat door hun hoofd gaat. Is het inderdaad wel versie 7? Kan het zijn dat het versie 8 is, maar versie 7 toont? Ook dat kunt u simpel nagaan door Drupal zelf te installeren, een versie 7 en deze te upgraden naar versie 8. Als de 7 een 8 wordt in de broncode dan weet u dat het toch echt versie 7 is dat daar gebruikt wordt.
Volgende vraag die wellicht speelt in uw gedachten. Misschien is het toch versie 7 maar met een upgrade die het lek gedicht heeft. Aha zeg ik dan, dus u krabbelt al terug, u geeft al toe dat het 7 is. Leest u dan nog eens goed de tekst in het voorgaande screenshot van het artikel. Daarin staat dat het versies zijn voor versie 8 die de kwetsbaarheid hebben, met andere woorden dus alles ervoor.
Misschien klopt de bron niet is wellicht het volgende dat u zich afvraagt. "Want hoe kan zo'n bekende website nu al niet gekraakt zijn?" Zo'n vraag is een verkapte autoriteitsargument, een drogreden, maar laten we daar eens voor de gekkigheid toch op in gaan. Waarom stelt u zich dan niet de vraag, maar hoe weet u zo zeker dat het al niet gekraakt is? Het kan best zijn dat een hacker al een account in het systeem voor zichzelf heeft aangemaakt maar nog niet gebruikt heeft en al die tijd ligt te slapen tot het moment dat de hacker denkt en nu doe ik er iets mee. We kunnen dat niet zeker weten. Echter zelfs dat maakt nog niks uit, zolang er versie 7 gebruikt wordt, blijft die kwetsbaarheid er.
Volgende vraag. Stel u accepteert dat het inderdaad versie 7 is en dat het inderdaad die kwetsbaarheid heeft, dan nog blijft de vraag, in al die tijd is er niemand die er kattekwaad mee heeft uitgehaald, geen Rus, geen handige tiener, enzovoorts? Verplaatst u zich even in die hacker. Die tiener hacker laat het wel uit zijn hoofd ook al weet ie dat het open en bloot ligt, want zo'n bekende site maakt dat veiligheidsdiensten een klopjacht naar zo'n hacker zullen organiseren. Dus die laat het wel, en voor de Rus is het juist niet interessant. Die kraakt liever gevoelige informatie van het Pentagon, want daar heeft hij meer aan.
Kwetsbaarheid in de Praktijk
Het is overigens niet zo dat die website nooit slachtoffer is geweest van hackers, maar dat zijn vaak DOS aanvallen geweest, die de website in kwestie tijdelijk plat hebben gelegd. Vaak gebeurde dat uit rancune, of was het een baldadige tiener die wilde zien hoe ver hij kon gaan. Net zoals er een tijd geleden in het nieuws is geweest hoe mensen over de hekken klommen of binnen braken bij een persconferentie. De kwetsbaarheid geeft echter meer mogelijkheden dan simpelweg plat leggen van de website. Denk bijvoorbeeld aan een politieke gelieerde groepering, die gaat hacken en er spamberichten opgooit.
Prioriteiten stellen
De datum in het screenshot van de broncode geeft in ieder geval wel aan dat de website wordt bijgehouden. Echter het is de datum van de facebook plugin, niet van het systeem zelf. Met andere woorden er wordt wel nieuws geplaatst op de website, maar aan veiligheid wordt niks aan gedaan. Veiligheid is zeer zeker geen prioriteit. Ik hoop dat ik met dit voorbeeld duidelijk heb kunnen maken dat het wat veiligheid betreft ook bij bekende organisaties men liever de put dempt, als het kalf verdronken is.
Het probleem oplossen
Stel we geven wel prioriteit om de kwetsbaarheid te dichten. Hoe kostbaar is zoiets? Dat hangt af van de situatie.
Laten we even terugkeren naar de website van het voorbeeld. Als het er alleen om gaat om simpelweg te upgraden van versie 7 naar versie 8, kan het probleem goedkoop en snel opgelost worden en kan snel ergere en meer tijdrovende en kostbare schade voorkomen worden.
Gebruikt die website echter plugins die alleen werken bij versie 7, maar niet bij versie 8 dan wordt het al snel meer problematisch. In dat laatste geval moeten of de plugins compatible gemaakt worden, of moet het stukje code in kwestie waar de lek zich bevindt met de hand aangepast worden. Beide opties kunnen tijdrovend en kostbaar zijn. Het eerste hoeft dat niet te zijn als er toevallig nieuwere en wel compatible plugins op de markt zijn en in het laatste geval kan het meevallen als het bewuste stuk makkelijk en snel gevonden kan worden. Is dat echter in beide opties niet het geval, dan mag u in dat laatste geval echt gaan afwegen of het inderdaad niet zinvoller is om pas in te grijpen als het te laat is geweest. In dat geval kunt u het risico op de reputatieschade voor lief nemen, omdat het wellicht vooralsnog als te kostbaar wordt gezien om alles te updaten of de plugins compatible te maken met versie 8.
Overigens even tussen neus en lippen door. In het geval van dit voorbeeld betwijfel ik of dat laatste het geval is. Het niet uitvoeren van de oplossing daar, lijkt helaas naar mijn mening, voor het huis waar het om gaat, eerder een kwestie van onkunde en onwetendheid en een gebrek aan vertrouwen, dan aan een budgettaire noodzaak.
Het Probleem van de Waarneming
Rest nog een laatste vraag. Wordt er dan niet gewaarschuwd? Ja, dat wordt er wel, maar de waarschuwingen zijn vaak aan dovemansoren gericht. Heel veel van deze organisaties zijn net zo'n ongelovige Thomas als u, ze geloven het pas als ze het echt zien gebeuren en zelfs dan nog zijn er mensen die weigeren hun eigen ogen te geloven. Het probleem wat hier speelt, heeft te maken met het eerder genoemde probleem van reputatie en perceptie. Een programmeur en hacker heeft kennis en ervaring en ziet wat echt is, een buitenstaander en leek heeft dat niet. Het probleem wat hier speelt is dat de kwetsbaarheid daardoor heel moeilijk verifieerbaar is voor een leek. Pas na verificatie zijn we als mens in staat het aan te nemen voor waar. Daar ligt het probleem voor de waarschuwer. Hoe wil je als veiligheidsexpert verifieerbare informatie delen aan een leek? Dat is verrekte moeilijk en vaak zelfs onmogelijk om te doen.
Ethical Hacking
Eén manier om op een verifieerbare wijze aan te tonen dat er een kwetsbaarheid is, is om een beloning te geven aan de expert om aan te tonen dat de kwetsbaarheid er is. Met andere woorden men laat de expert de website hacken in ruil voor een beloning. Zulke mensen worden in vaktermen "white hat" hackers of "ethical hackers" genoemd. De echte hacker, met andere woorden de slechterik, heet dan een "black hat" hacker. Echter het probleem is hier dat de wet geen onderscheidt weet te maken tussen een "white hat" hacker en een "black hat" hacker. Heel simpel gezegd ook al krijgt de expert een beloning ervoor, de handeling die hij ervoor doet, het hacken dus, blijft een strafbaar feit.
Dat soms niet tot vervolging wordt overgegaan komt dus door gedoging, net zoals euthanasie en drugsgebruik nog steeds strafbaar zijn, maar vaak gedoogd worden. Echter over hacken bestaat meer onwetendheid en meer onbegrip dan voor de andere genoemde zaken.
Dat komt doordat iemands zienswijze over gevallen van euthanasie en drugsgebruik op minder abstracte kennis en minder onbewuste kennis is gebaseerd. De twee andere zaken zijn concreter en tastbaarder dan hacken. Om die reden laten veel experts de beloning voor wat het is en houden het bij een waarschuwing. Of iemand er iets mee doet, is dus aan de gewaarschuwde.
Nog een ding dat hier speelt is de strafmaat. De in het verleden aangehouden en gestrafte hackers, zijn vaak zeer zwaar gestraft en dat voor misdrijven die vaak in het niets vallen vergeleken met zware geweldadige misdrijven. Ook hier speelt dat het recht wel redelijk en billijk in theorie zou moeten zijn, maar het in de praktijk helaas vaak niet is. Veel rechters zijn van een zekere leeftijd, hebben geen affinitieit met ICT en straffen om die reden dan ook harder. Hoe dat komt, daar speelt een stukje psychologie achter, maar dat zou een te lang verhaal worden om hier uit te leggen.
Ethical Hacking en de Toekomst
Aan deze huidige situatie lijkt voor nu en zelfs in de verre toekomst nog geen verandering aan te komen. Even leek het er op dat met een nieuw wetsvoorstel van Ard van der Steur dat dit zou veranderen en dat er (lees dit goed) er speciaal beleid zou komen voor dergelijke "white hat" hackers. Dat is er dus niet, als de kleine letters goed gelezen worden blijkt dat het nog even strafbaar is als voorheen. Van de overheid hoeft u wat dit betreft dus niks te verwachten.
Bevoegdheid
Wie echter wel de bevoegdheid gekregen hebben om te hacken zijn de buitengewoon opsporingsambtenaren (BOA's) die belast zijn met ICT. Deze werken overigens niet voor de overheid, maar zijn werknemers van private partijen die hiervoor getraind worden.
Eén bedrijf die hier namens de overheid voor mag werken is het hele bekende Fox-IT, dat onder andere in het nieuws is geweest i.v.m. het diginotar schandaal, yahoo malware schandaal en het belgacom schandaal.
Zeker geen onbelangrijke zaken als het om veiligheid gaat, maar het eerste en laatste schandaal laat echter ook gelijk hun zwakte zien, namelijk dat ze steunden op een klokkenluider welke dingen aan het licht bracht en laat ik hierin duidelijk zijn, dat was ook volgens de Nederlandse wet nog steeds strafbaar. Ik laat hier in het midden of dat een goede of slechte zaak is. Daar mag u zelf over oordelen. Ook kunt u aan deze schandalen opmaken dat dergelijke partijen zich dus met dit soort ICT zaken bezighouden, maar niet met de veiligheid van uw website.
Toetsing
Wat de overheid wel doet voor haar zelf is het bureau ICT toetsing (BIT) in het leven roepen. Echter ook hier dient u goed de kleine letters te lezen. BIT is niet bedoeld voor veiligheid, maar om ICT projecten te toetsen op kosten en haalbaarheid. Hoe deze instelling dat in hemelsnaam denkt te doen is buitengewoon twijfelachtig, er zit namelijk geen enkele expert in met een programmeursachtergrond. Even afgezien van welke politieke achtergrond de lezer dan ook mag hebben, dat klinkt mij als zeer niet effectief en de slager die zijn eigen vlees keurt. Het roept bij mij ook vraagtekens op over de banden van BIT leden. Het is allemaal zeer bedenkelijk.
Maar daar mag u zelf over oordelen. Harde bewijzen zijn er niet.
Komt er verandering?
Echter ik heb nu alleen de huidige situatie wat de overheid betreft geschetst. Hoe zit het politiek? Normaliter houd ik politiek liever hierover ver gescheiden, maar ik kan het niet laten om even dit te noemen. Geen enkele politieke partij die zich nu in de Staten Generaal (Eerste en Tweede Kamer) bevindt, wenst verandering te brengen in deze situatie. Dat is trouwens even buiten gelaten of ik vind dat er verandering hierin zou moeten komen. Die mening houd ik hier voor me. Ook hier mag u zelf over oordelen. Ik wil u alleen inzicht geven in hoe netelig deze situatie is. Het geeft al aan hoe lastig de situatie is en hoe lastig het is om hier verandering in te brengen. Tot die tijd modderen we dus maar wat aan.
Cookiewet, een voorbeeld van hoe de overheid faalt
Als de politiek al verandering denkt aan te brengen voor de samenleving, dan is het helaas vaak niet ten gunste van de samenleving. Wetten die zogenaamd zijn ingevoerd om de veiligheid van de burgers te verbeteren, leveren in de praktijk geen enkel voordeel op en zijn zelfs ten nadele van het bedrijfsleven of organisaties. De cookiewet is zo'n voorbeeld van een dergelijke wet.
De cookiewet stelt dat elke niet noodzakelijke cookie die zonder toestemming van de bezoeker op de computer van de bezoeker gezet wordt, een boete oplevert aan de eigenaar van de website in kwestie van ten hoogste 300.000 euro. Ten eerste kan zo'n boete zo hoog uitvallen, dat er in deze wet zeker geen sprake is van redelijkheid en billijkheid. Beide zaken die belangrijk zouden moeten zijn in het recht. Ten tweede kan een cookie zelf door de bezoeker heel makkelijk verwijderd worden of geblokkeerd worden. In de instellingen van elke browser kan "cookie setten" geblokkeerd worden. Cookies lijkt allemaal heel eng voor een leek, maar het zijn gewoon hele kleine en eenvoudige tekstbestandjes, die gewoon handmatig verwijderd kunnen worden. U hoeft alleen maar de map in kwestie te openen, de cookie te selecteren en op delete te tikken en de cookie is verwijderd. Niks engs aan.
Dat zo'n boete bijzonder schadelijk kan uitpakken voor een bedrijf dat een niet noodzakelijke cookie gebruikt op zijn website, behoeft geen verdere uitleg. Gelukkig is het zo dat de instanties die belast zijn met het uitvoeren en naleven van deze wet al in diverse media gesteld hebben, deze wet niet uit te voeren en dat is naar mijn mening maar goed ook. Toch wil ik daarmee niet zeggen dat u die wet niet moet naleven. Ik zeg niet tegen u, dat u het risico moet lopen op die boete. Helaas is wel vast te stellen, dat die wet ethisch verwerpelijk is.
Het geeft echter wel aan dat deze wet geheel buiten proporties is en nooit wet had mogen worden. Waarom is dat toch gebeurd? Daar zijn een aantal redenen voor. Ten eerste speelt er bij veel politici hetzelfde probleem als bij veel rechters het geval is. Ze zijn veelal van een zekere leeftijd en hebben geen affiniteit met ICT. Zelfs de zogenaamde ICT experts in politieke partijen hebben geen programmeursachtergrond en zijn dus net zo onwetend als de gemiddelde burger die ze dienen te vertegenwoordigen. Daar zitten overigens ook jonge politici tussen, dus wat dat betreft is een jonge leeftijd geen garantie dat ze wel de juiste beslissing kunnen maken en wel wijsheid in pacht hebben. Opzich is daar niks mis mee. Ik hoef als astronaut ook geen raketwetenschapper te zijn. Ieder heeft zo zijn eigen specialiteit. Echter het wordt wel een kwalijke zaak op het moment dat dergelijke slechte wetten een meerderheid vinden. Waardoor dat toch gelukt is, speelt naar mijn mening iets meer achter dan alleen onwetendheid.
De officiële lezing van de voorstanders van de wet was overigens deze reden. De reden van opgaaf voor de invoering van deze wet was bescherming van privacy tegen zogenaamde permanent cookies. Als u echter nu weet zoals ik, omdat ik u dat vertelt heb, dat cookies verwijderd kunnen worden door uzelf, dan weet u dus ook dat dit verhaal van permanente cookies volstrekt kolder is. U weet dan ook dat kennis van dit verwijderen een veel effectievere manier is van bescherming van de privacy, dan deze wet.
Als we weten dat de officiële verklaring onzin is, dan moet er een andere reden zijn. Ik heb er een verklaring voor, zij het iets historisch speculatief.
Om die andere reden toe te lichten komt een beetje geschiedenis bij kijken. Ik kom met een kort historisch voorbeeld. In de jaren zeventig zijn in West-Duitsland zogenaamde RAF-wetten doorgevoerd die de privacy en vrijheden van burgers beknotten. De afkorting RAF slaat in dit geval op de "Rote Armee Fraktion". Men was zo bang van dit terrorisme dat de wetgevende macht dergelijke rare wetten heeft doorgevoerd.
De cookiewet moeten we ook in dit licht zien. Het is dan niet gericht op de RAF, maar er is wel het hedendaags terrorisme en de aanslagen die we kennen van de televisie. Ook terroristen hebben websites en maken gebruik van social media. Blijkbaar is het voor de BOA's en de wet zo lastig om die terroristen aan te pakken op bijvoorbeeld het zaaien van haat (want wanneer is het haat prediken versus meningsuiting?),
dat onze wetgevende macht blijkbaar wat nieuws bedacht heeft door een boete op te leggen en jawel voor zoiets onbenullig als een tekstbestandje te downloaden. Het probleem hierin ligt uiteraard dat de kwaden gelijk met goeden gestraft kunnen worden en dat geeft gelijk ook aan wat er naar mijn mening verkeerd is aan deze wet.
Dat gebrek aan onderscheid tussen de kwaden en de goeden kan een aantal gevolgen hebben. De wet kan daardoor bijvoorbeeld gebruikt of misbruikt worden om politieke tegenstanders te belasten met willekeurige strafvervolging. Immers die officiers van justitie weten vaak net zo min als een rechter wat een cookie precies inhoudt. Of wat dacht u meer in de trant van BIT, van een commerciële partij, die een concurrent uit de weg ruimt door hem te overladen met dure strafrechtelijke onderzoeken. Bedenk namelijk dat in ons rechtstelsel eenieder aangifte kan doen van een strafbaar feit, tenzij het een misdrijf betreft waarvoor alleen een belanghebbende aangifte kan doen. Ik ben geen jurist, maar die laatste uitzondering lijkt me bij een dergelijk wet als deze niet het geval.
Dit soort hypothetische voorbeelden noem ik om aan te geven hoe kwalijk het is dat een dergelijke wet een meerderheid heeft gevonden.
Mocht u al een dergelijke geschetste hypothetische situatie in het echt meemaken, dan geef ik u bij deze het advies een goede advocaat in handen te nemen. Een advocaat die een rechter kan uitleggen waarom een niet noodzakelijke cookie, toch echt noodzakelijk is.
Dit voorbeeld van de cookiewet geeft helaas des te meer aan hoe lastig het ook is voor een leek om een juiste beslissing te kunnen maken over veiligheid. Als 150 politici er soms al niet uitkomen, hoe wilt u dat dan wel doen?
Tot Slot
Het voorgaande geeft helaas aan dat van de uitvoerende, wetgevende en rechterlijke macht weinig te verwachten valt. Ik zou met u de lezer, eindeloos kunnen speculeren over waarom hier de democratie zo in verdrukking is. Is het de langdurige economische recessie, of terrorisme, of corruptie, of incompetentie? U mag het zeggen. Echter langer door speculeren is weinig zinvol voor de dagelijkse praktijk, want in het kort komt het toch hier op neer:
Als het om veiligheid gaat, zult u het zelf moeten doen en de internetkranten goed in de gaten houden. Het blijft dus voor u zaak om uw gezond verstand te gebruiken, of anders een programmeur te vragen om hulp.
© 2024 Wiebe Eling de Boer