Vpn-dienst Mullvad waarschuwt voor dns-lekken op Android

Vpn-provider Mullvad waarschuwt Android-gebruikers voor potentiële dns-lekken. Deze worden veroorzaakt door bugs in het os en kunnen misbruikt worden om de ruwe locatie van gebruikers te benaderen en te achterhalen welke websites er worden bezocht.

Mullvad heeft twee scenario’s gevonden waarbij Android dns-verkeer kan lekken. Enerzijds kan het systeem kwetsbaar zijn wanneer een vpn actief is terwijl er geen dns-server is ingesteld. Anderzijds kan het dns-verkeer gedurende een korte tijd worden blootgesteld wanneer de vpn-tunnel opnieuw wordt geconfigureerd of wanneer de vpn geforceerd wordt afgesloten of crasht.

Volgens de vpn-dienst worden deze kwetsbaarheden veroorzaakt door bugs in Android zelf en worden alleen bepaalde apps getroffen. De lekken zouden zich voordoen in meerdere versies van het os, inclusief Android 14.

Mullvad geeft aan dat het eerste probleem eenvoudig kan worden opgelost en dat er binnenkort een fix beschikbaar moet zijn voor de Android-app. Het is naar eigen zeggen echter lastig om de blootstelling te verhelpen wanneer de tunnel opnieuw wordt ingesteld. Het bedrijf heeft de problemen gemeld aan Google en verbeteringen voorgesteld.

Reacties (38)

[HollowGamer]

Dit is niets iets nieuws, naar mijn weten is dit gevaar ook aanwezig op de desktop en routers.

Volgens mij hebben de meeste apps hiervoor een soort kill switch. Daarmee wordt de verbinding verbroken als de connectie met de VPN wegvalt. Het gevaar is namelijk dat dan data lekt, wat zeker kan gebeuren bij het uitvallen van of switchen van netwerk.

Ik weet niet of dat hetzelfde is? Maar ik dacht altijd dat dit niet bullet proof was, dus dat je echt zelf nog goed moest letten op verkeer dat mogelijk kan lekken.

[Lucb1e]

naar mijn weten is dit gevaar ook aanwezig op de desktop en routers

Niet precies ditzelfde risico. Op welk besturingssysteem dan ook, als je de routeringstabel aanpast zodat het in-VPN router-IP-adres (bijvoorbeeld 100.64.0.1) wordt gezien als default gateway ("internet") en alleen het IP-adres van de VPN-dienst zelf de echte router in je netwerk gebruikt om naar het internet te komen, dan gaat het besturingssysteem niet opeens alsnog verkeer voor een willekeurig IP-adres naar de echte router sturen wanneer de VPN-software sluit of crasht. Andere software moet de algemene route naar het internet via je router eerst terugzetten alvorens het besturingssysteem dat weer aanziet als een pad voor gewoon internetverkeer. Meestal zal de DHCP-daemon, die bij het besturingssysteem wordt meegeleverd, dat doen.

<detalis>
Feitelijk pas je de routertabel aan van:
0. Stuur verkeer voor 10.0.0.x direct uit op apparaat eth0
1. Stuur alles via 10.0.0.1
naar:
0. Stuur verkeer voor 10.0.0.x direct uit op apparaat eth0
1. Stuur verkeer voor 100.64.0.x direct uit op virtueel apparaat tun0
2. stuur verkeer voor 192.0.2.1 via 10.0.0.1
3. stuur alles via 100.64.0.1
Waarbij het 10.0.x-adres je router is, het 192.0.x-adres de VPN-dienst, en 100.64.x de router binnen de VPN-tunnel. De eerste match wordt direct uitgevoerd, van boven naar onder lezend. Hierdoor kún je niks lekken, want als de VPN-software crasht en vervolgens een pakketje voor 31.22.80.152 aan de kernel gegeven wordt ter verzending, dan gaat regel 3 matchen, dat vervolgens regel 1 gebruikt waar een apparaat aangesproken wordt (tun0) dat niet meer bestaat, en het netwerkpakket dus in bijvoorbeeld "network is unreachable" resulteert. (Kun je zelf uitproberen als je de default route weghaalt en dan 31.22.80.152 (Tweakers) pingt.)

DNS-verkeer is daarnaast nog een losse instelling. De resolver zit meestal op LAN (de router geeft jouw apparaat die informatie in hetzelfde pakket als waarin het je een lokaal IP-adres toewijst) en dus zou je alsnog die bevragingen (queries) lekken: in beide gevallen matcht het regel 0, wordt het uitgestuurd op LAN, en gaat het vanaf daar (via je gewone verbinding dus) het internet op. De VPN-software moet dus ook de DNS-instelling veranderen naar een adres binnen de VPN.
</details>

Op Android is het probleem dat je die rechten standaard niet hebt. Er draait wel een Linux-kernel en die doet ook routeren (jep, jouw telefoon kun je ook als router inzetten want de code/functionaliteit zit er al in), maar de Androidlaag daar bovenop beheert die routeringstabel. Je moet bij de Androidlaag aankloppen als VPN-app, waarna het de nodige dingen voor je aanpast. Ook de in de kernel ingebouwde nftables-firewall (vroeger: iptables) kun je op Android standaard niet zelf beheren. Als je volledige toegang hebt tot je eigen apparaat kan dat natuurlijk wel, en er zijn ook apps die dat makkelijk maken (zoals AFWall+), maar telefoonfabrikanten mogen van Google die toegang niet standaard aanzetten dus dat is pas mogelijk als je een OEM-unlockprocedure uitvoert en bijvoorbeeld een superuser-binary installeert, wat voor veel mensen te technisch en de moeite niet waard is. Hoe dan ook, als de VPN-app crasht of de verbinding wil herconfigureren (misschien naar een nieuwe server switchen als de huidige te druk wordt), dan is het dus afhankelijk van hoe Android daar precies mee omgaat of je op dat moment verkeer lekt buiten de VPN om dat voor binnen de VPN bedoeld was.

Dit probleem heb je op desktops niet, want daar heb je de volledige toegang tot je apparaat en je verleent dat toegangsniveau ook aan de VPN-software. In Windowss verleen je dat wanneer je zo'n fullscreen "Do you want to allow this app to make changes to your device?"-vraag krijgt en op "ja" klikt; op Linux krijg je meestal de vraag je wachtwoord opnieuw in te voeren of moet je het met bijvoorbeeld `sudo` uitvoeren. Vanaf dat moment kan de software eigenhandig die routeringstabel aanpassen en is het niet van een bovenliggende laag afhankelijk om het goed te doen.

Daarmee wordt de verbinding verbroken als de connectie met de VPN wegvalt.

Ik zou dit formuleren als: daarmee is bij het systeem geen functionerend pad naar het internet bekend (behalve naar het/de IP-adres(sen) van de VPN-dienst zelf). Het is niet zozeer dat de code doet "als [connectie met VPN verloren] dan [verbinding verbreken]", want daar kan (een korte) tijd overheen gaan, maar meer dat het bij voorbaat al verbindingen enkel via de VPN mogelijk maakt totdat andere software daar overheen fietst met andere plannen.

[Reactie gewijzigd door Lucb1e op 22 juli 2024 17:35]

[RobertMe]

Een van de problemen is juist dat die hele kill switch in een bepaald scenario bij het gebruik van een specifieke API niet werkt. Als de "kill switch" geen DNS server instelt (/overruled?) en er wordt gebruik gemaakt van de [mono]getaddrinfo[/] C functie dan wordt er alsnog een DNS query verstuurd, naar de originele DNS server. Maar als de Android API gebruikt wordt om de DNS lookup te doen dan wordt er geen DNS query verstuurd, en als er wel een DNS server wordt ingesteld (/overruled) dan wordt de query ogenschijnlijk ook niet uitgevoerd. Waarbij Mullvad op de korte termijn dus met een workaround komt door bij het gebruik van de kill-switch een bogus DNS server in te stellen.

[FrostyPeet]

Een "goede" travel router heeft een auto killswitch, die meteen de verbinding verbreekt bij een probleem. De betere hebben een vpn client die moderne protocollen ondersteund. Ook is er een firewall. Bij sommige travelrouters kan je een 4G/5G usb dongel inpluggen voor mobiel internet via een telco. Met de travel router maak je verbinding met de wifi, 4G/5G netwerk of de netwerkkabel naar "de muur". Aan de "achterkant" verbind je je eigen hardware.

[Florensie]

Wat een verwarrend artikel zeg. Het zijn bugs in het Android besturing systeem, gevonden door de VPN service, die de VPN service kan patchen in zijn eigen app?

[DutchieSmokah]

Inderdaad. Ook het vermelden waard: er staan helder uitgeschreven reproductie scenarios op de website van Mullvad waarmee je je eigen vpn even snel kunt checken ;-)

[MPAnnihilator]

staat er toch in uitgelegd, dat zij ook last hadden van de bug als de gebruiker geen DNS server had ingesteld in de app ( en terugvalt op Android DNS ) , wellicht zullen ze er nu een DNS vereiste inbouwen.

[jurroen]

Wat een verwarrend artikel zeg. Het zijn bugs in het Android besturing systeem, gevonden door de VPN service

Gevonden door GrapheneOS. Mullvad treed er nu mee naar buiten, maar dit was twee weken geleden al gepubliceerd. Zie bijvoorbeeld: https://grapheneos.social/@GrapheneOS/112316307560525598

[Reactie gewijzigd door jurroen op 22 juli 2024 17:35]

[Vogel666]

Nou ja...bugs...???
Het zijn scenario's waarin je ondanks je VPN service toch soms data buiten de VPN om kunt versturen als je VPN service toevallig net gecrashed of verbroken is.

En ja, als je op een fout netwerk zit en de foute netwerkbeheerder ziet dat je net porno opvraagt...dat was nu net het doel van de VPNservice...om dat te voorkomen.

[MeNTaL_TO]

Ok, dus als je geen VPN gebruikt ben je altijd veilig? Of trek ik dan een verkeerde conclusie?

[dasiro]

je bent in beide gevallen veilig, want in het beste geval kunnen ze je IP achterhalen en zo bij benadering uitvogelen waar in de wereld je ergens zit en welke adressen je opvraagt, beiden zijn al jaar en dag relatief makkelijk te achterhalen en het is niet toevallig dat een vpn-verkoper dit in de aandacht probeert te brengen, want die beweren dat v/heiliger dan de paus te zijn, ondanks velen er (net zoals de lieve geestelijken) dat zeker niet zijn.

[RobertMe]

Het gaat niet perse alleen om "IP adres achterhalen". Een app zou bv een tracking id / tracking data kunnen communiceren naar het thuisfront via DNS. Als er dan "lekken" zijn waardoor DNS verkeer helemaal niet geblokkeerd wordt, in bepaalde scenarios (zoals een van de issues is), dan zal ook op dat moment die blokkade omzeilt worden.

[dasiro]

heb je gelezen wat er fout gaat? enkel traffic van apps die een C-functie aanroepen ipv de API's van android is zichtbaar, dan spreken we niet over inhoudelijke data die verstuurd wordt, laat staan andere data die op het toestel staat. Hoe jouw scenario daarin past zonder dat het op een andere manier mogelijk is, is me een vraagteken, aangezien zulke apps (moesten ze die data al hebben) op veel veiligere manieren hun info kunnen doorsturen naar het thuisfront ipv open en bloot voor iedereen die het wil zien.

[RobertMe]

Ja, ik heb, eerder vandaag, al de originele post van Mullvad gelezen

En doordat de mogelijkheid er is om DNS queries (buiten de VPN om / buiten de blokkade/kill-switch van VPN om) te sturen is het dus wel degelijk mogelijk om (zeer beperkt) data te communiceren. Al is het dus maar een uniek ID. Immers kan tracking prima plaatsvinden via een "DNS" server. Dus een "alternatieve" DNS server / implementatie die queries doet "loggen". Simpelweg dus door de app bv een DNS lookup van "<uniek tracking id>.mijn.tracking.service" te laten doen. Waarbij die DNS server implementatie dus weer kan loggen dat dat apparaat bv op dat moment de app gebruikte of wat dan ook. En mogelijk dat het zelfs "past" (geen idee hoe lang een domeinnaam mag zijn) om hele data bv in base64-encoded JSON te verpakken in zo'n DNS query.

[sjongenelen]

In bijvoorbeeld Iran lijkt me een bug als deze behoorlijk een probleem

[dasiro]

je gaat uit van een malafide app , maar die kan de query even goed door een vpn tunnel sturen of zelf versleutelt communiceren op een andere manier, daar helpt een vpn niet tegen en is hij ook helemaal niet voor bedoeld. Het is geen great firewall of china die DPI op alles toepast en reroute naar z'n eigen infrastructuur.
Het lekken van data uit een VPN-tunnel is even "gevaarlijk" als geen VPN gebruiken en het énige dat ze er uit krijgen is een dns-request die ze anders ook al niet zouden kunnen tegenhouden.

Om het voorbeeld van @sjongenelen te gebruiken: als grinder over vpn deze functioncall doet voor een eigen server, dan weten ze mogelijks dat er ergens een andersgeaarde rondloopt als bij de provider alles gemonitorred wordt. maar zoals ze zelf aaangeven: als je app correct geschreven is, dan gebeurt dat dus niet.

[RobertMe]

Behalve dus dat DNS de kill switch omzeilt. Dus ook als er "geen" internet is (doordat de VPN down is / de kill switch actief is) zou een app data naar buiten kunnen smokkelen via DNS.

[dasiro]

again: dat kan ook terwijl een VPN actief is. Apps kunnen data naar eender waar sturen en malafide apps zullen dat op een (voor zichzelf) veiligere manier doen.

[lenwar]

je gaat uit van een malafide app

Dat, is een adverteerder. Pak Meta als voorbeeld. Die heeft in het verleden al vaker verwerpelijke dingen gedaan. (Het op de achtergrond meeluisteren met de microfoon en zo.)
Maar ook andere advertentieverkopers zie ik er voor aan om hier misbruik van te maken.
Ook diensten als Netflix kunnen deze data gebruiken om te voorkomen dat een Europeaan Amerikaanse Netflix-titels bekijkt. (Ik zeg niet dat dit goed of fout is).


Het probleem is domweg, dat het besturingssysteem DNS-data lekt, waar dit, met een goed functionerende VPN-implementatie, niet mogelijk zou moeten zijn.

[kodak]

Aangezien de keuze van een netwerk juist een heel belangrijke te respecteren keuze is, juist omdat er nogal wat vanaf kan hangen, is een keuze voor een specifiek virtual private network dat dus ook. Eerder juist nog meer, omdat het bescherming hoort te geven dat er niet zomaar toch via andere netwerken gecommuniceerd zal worden.
Dat een app malafide is mag dan de betekenis hebben dat deze probeert de systeemkeuzes van de gebruiker te negeren, maar een app staat niet zomaar boven of gelijk aan de rechten van een systeem. Dat is namelijk waarom een OS rechten beperkt, bijvoorbeeld op specifiek verzoek van de gebruiker. Nu blijkt dat het OS de rechten onvoldoende weigert wat betreft te gebruiken verbindingen. Het interesseert Google niet dat en waarom een Android-gebruiker de vpn wil gebruiken. Ze vinden de keuze van het systeem de eigen ontwikkelaars en zelfs die van willekeurige apps belangrijker dan wat de gebruiker als netwerk wil gebruiken. Terwijl ze tot nu toe geen enkele afgewogen reden geven dat de wil van de gebruiker maar minder belangrijker hoort te zijn. Simpel stellen dat een keuze voor een specifiek verbinding niet als doel heeft om veiliger te zijn is daarmee eerder malafide te noemen dan de keuze van de eigenaar en gebruiker te respecteren. Want dat is precies wat malafide software kenmerkt.

[Raymond Deen]

Volgens mij haal je de termen vpn en firewall door elkaar. Een vpn houdt helemaal geen verkeer tegen, maar stuurt het daarentegen via een tunnel naar je privénetwerk waarna je het internet weer op kunt, of op je privénetwerk kunt werken.
Een firewall kan wél verkeer tegenhouden; verkeer van en naar internet toe, van en naar poorten, communicatieprotocollen en noem verder maar op.

Ook via een vpn kun je prima met 8.8.8.8 communiceren dus en wanneer een applicatie of api hard ingesteld met dit adres communiceert op poort 53 terwijl je een ander adres hebt ingesteld, wordt dat niet tegengehouden. Pas wanneer je dmv je firewall instelt dat dns-verkeer alleen met jouw ingestelde dns adres mag, wordt dat ook afgedwongen.

[RobertMe]

Neen, ik haal ze niet door elkaar. Het punt is dat de VPN apps (/Android API voor VPNs?) een optie hebben om alle verkeer dat buiten de tunnel om gaat te blokkeren en dit ook te doen op het moment dat de VPN niet werkt (ter voorkoming van het onbewust sturen van data buiten de tunnel om als deze down is). En juist in dat geval gaat DNS verkeer dat via de C API geïnitieerd wordt ineens buiten de instellingen om (gebruikt de standaard DNS server én gaat niet over de tunnel heen).

En uiteraard is het een vorm van samenspel van VPN en firewall. Waarbij noch de routing noch de firewall APIs beschikbaar zijn voor Android apps. Maar er wel een high level API is die (VPN) apps kunnen gebruiken om deze afgeschermde low level zaken in te stellen. Alleen resulteert dat dus tot problemen in specifieke scenarios. Dus: als de kill switch actief is en de VPN app geen DNS server heeft ingesteld dan levert de C [mono]getaddrinfo[/] functie ineens een DNS query buiten naar de standaard DNS server, buiten de VPN tunnel om, op. Waarbij in ieder geval Mullvad nu met een workaround komt door dan maar een bogus DNS server in te stellen.
Waarbij dit probleem dus ontstaat door of een foute implementatie van de C library, of de high level Android API die dit soort apps verplicht moeten gebruiken iets niet goed doet configureren op het low level niveau.

[Mausssie]

Lijkt mij dat een VPN toch over het algemeen wel veiliger is, dan een verbinding zonder VPN. Vraag is of de gemiddelde burger die extra veiligheid nodig heeft, waarschijnlijk niet.

[blorf]

Je moet alsnog wel precies weten wat er gebeurt. Bij een Android-app is dat vrij lastig. Het is bijvoorbeeld niet de bedoeling dat een of andere app de boel omzeilt met de nodige permissies en iets op de echte buiten-ip gaat zitten proberen.

[Rjanssen1]

Dat is denk ik niet de correcte interpretatie. Deze fouten hebben als gevolg dat de vpn soms deels niet werkt. Het is in die gevallen dan alsof je geen vpn hebt. Wat natuurlijk onwenselijk is als je kiest voor een service als mullvad.
Je wordt door deze bug dus niet onveiliger dan wanneer je geen vpn hebt. In plaats daarvan zakt je veiligheid* naar het niveau van iemand zonder vpn.
*ik zeg veiligheid omdat je dat woord zelf gebruikte, anonimiteit past eigenlijk beter. Ook is niet elke vpn dienst hierin gelijk, zeker bij gratis vpns is het goed mogelijk dat je beter af bent zonder.

[Lucb1e]

Het gaat inderdaad om verkeer dat de VPN per ongeluk niet gebruikt terwijl die wel ingeschakeld is en daardoor een IP-adres kan prijsgeven dat je geheim wilde houden, of een verkeerd antwoord krijgt op de DNS-query omdat het niet binnen het bedoelde (virtuele) netwerk gebeurde

De vraag klinkt een beetje gek op het eerste gezicht, alsof je vraagt of je zonder antivirus veiliger bent dan mét AV wanneer een AV-bedrijf een lek in Windows gevonden heeft dat alleen van toepassing is op de AV-functionaliteit zelf. Ik denk dat mensen je reactie daarom op +/-0 zetten, maar als ik je goed snap bedoelde je te vragen of Mullvad alle Androidgebruikers waarschuwt voor DNS-lekken of aan specifiek de gebruikers die een VPN gebruiken

[Reactie gewijzigd door Lucb1e op 22 juli 2024 17:35]

[ibmpc]

en kunnen misbruikt worden om de ruwe locatie van gebruikers

De locatie van de gebruiker kan toch sowieso worden achterhaald, ongeacht of je een VPN gebruikt of niet? Ik heb tegenwoordig mijn twijfels bij het nut van een VPN omdat je in veel gevallen te veel toegang krijgt tot bepaalde resources, wat bij ZTNA iets minder zou moeten zijn. Ik werk zelf het liefst zonder VPN en ik focus meer op endpointbeveiliging en beveiliging van de traffic en data, dan vertrouwen op een VPN en het beveiligen van netwerken. Te meer omdat gebruikers vaak op onbeveiligde Wi-Fi netwerken zitten of op Wi-Fi netwerken waar je geen beheer over hebt.

[Reactie gewijzigd door ibmpc op 22 juli 2024 17:35]

[blorf]

Het risico is fundamenteel: je hebt niet 100% controle over de computer, dus ook niet over de beveiliging van je verbinding. Dat kan pas als je aangetoond root bent en niet iemand of iets anders.
Dit gaat gigantisch mis op het moment dat mobiele providers permissies verstrekken aan een besturingssyteem die verder gaan dan wat de eindgebruiker maximaal kan hebben, in ruil voor inzage in de netwerk-eigenschappen op OS-niveau van een aangesloten systeem.

[Reactie gewijzigd door blorf op 22 juli 2024 17:35]

[FrostyPeet]

Als je vaak op "openbare" wifi zit, kan ik je een travel router aanraden. Met die travel router maak je verbinding met de wifi, je eigen hardware zit aan de "achterkant" van de router. Een goede travelrouter heeft een firewall en een vpn client die moderne protocollen ondersteund. Ze zijn compact en je kan er een powerbank inpluggen voor de stroomvoorziening. De goede travelrouters hebben ook een usb poort waar je een 4G/5G usb dongel in steekt voor mobiel internet.

[Mausssie]

Is dit naar jouw idee heel veel veiliger dan gewoon een VPN app op je device hebben draaien?

[FrostyPeet]

De veiligheid zit er in dat je maar één apparaat hoeft in te stellen om verbinding te maken met een wifi/mobiel netwerk of een bekabelde internet aansluiting.

Je eigen hardware laat je via een utp kabel of wifi verbinding maken met de travel router. Je hoeft dus niet elk apparaat apart in te stellen en van een vpn client te voorzien, van het correcte wifi password/captcha portal etc. Je eigen hardware maakt automatisch opnieuw verbinding met de travel router. Je kan dus alle opgeslagen wifi passwords en ssid's wissen wissen van je hardware.

De travel router doet al het werk, zet eventueel een vpn verbinding op, heeft een auto kill switch, sommige hebben ook een tor client ingebakken. De goede travel routers hebben openwrt als besturingssysteem, wat open source is.

Een travel router gaat er van uit dat elk internet onveilig is, of dat nu een publieke wifi is of een (buitenlandse) mobiele aanbieder.

Het voorkomt een hoop "gedoe" als je voor bijvoorbeeld je werk "overal en nergens" zit en moet werken via internet.

Een bijkomend voordeel is als bijvoorbeeld je cruise schip wifi aanbied per apparaat, dat je travel router als één apparaat telt. Dat je "er achter" een aantal eigen apparaten hangt "ziet" de wifi aanbieder niet. Dit kan veel geld schelen. Of als je hotel slechts één apparaat toelaat, kan je achter de travel router ook een firestick / mobiele app "hangen" en dan lekker Netflix o.i.d. streamen op de hotel tv (hdmi kabel).

[SilentLucidity]

De titel suggereert fouten in de app, tenminste, het zou beiden kunnen. Het bedrijf heeft echter lekken in het OS gevonden, dus ook andere apps zijn dan waarschijnlijk kwetsbaar.

[Rieboet]

Ik voer regelmatig een dns leak test uit.
Bij Mullvad en andere vpn's zag ik inderdaad in mijn Android een dns leak bij WiFi verbindingen.
Maar met Mullvad vpn geen dns leak over GSM en ook niet bij de open vpn app met Mullvad configuratie bestand bij zowel GSM of WiFi.
Ik krijg overigens een snellere verbinding met Mullvad vpn naar mijn iot apparatuur dan zonder vpn.

[Terry A Davis]

Browsers hebben een cache. Firefox heeft bijvoorbeeld about:networking#dns daarom kan het gebeuren dat oude DNS gegevens gewoon blijven worden gebruikt. Hier is niets tegen te doen. Firefox is hier heel duidelijk in.

Een ip adres omzetten naar naam gebeurt meestal met dichts dichtstbijzijnde ip address van een server.

Pas na 3600 seconden kan je daadwerkelijk enige meer zekerheid ervaren op geen DNS leak.

Android cached DNS sowieso houd daar dan rekening mee als je een VPN als daadwerkelijk levensbedreigende situatie nodig hebt.

[Rieboet]

3600 seconden is één uur !
Jij bedoelt milliseconden.
Tnx voor je bericht.

[Xfade]

waarom hebben ze geen dns leak protection dan ?

[Sailor69]

Zou het erger zijn dan cookies die weten welke website je hebt bezocht. Ik vind het een vaag artikel.

[Vogel666]

Als een als diplomaat van een fundementalistische godsdienstig land betrapt wordt op het bezoek aanPornHub of Grinder....ja dan kan je best in de problemen komen...