Privacy
Inleiding
“Op het internet weet niemand dat je een hond bent.” Hoewel het enigszins waar is dat je anoniem kunt proberen blijven om het internet als dusdanig te gebruiken, kan het redelijk moeilijk zijn om je persoonlijke gegevens volledig privé te houden.
Een hele industrie is toegewijd aan het online volgen van gebruikers, om gedetailleerde gebruikersprofielen te bouwen voor doeleinden als gerichte advertenties, fraudedetectie, prijsdifferentiatie, of zelfs kredietscores. Het delen van locatiegegevens met websites kan erg nuttig blijken in het dagelijkse leven, maar kan ook toelaten dat bedrijven elke stap die je zet zien. Zelfs als een dienst de privégegevens van een gebruiker zorgvuldig behandelt, biedt het louter opslaan van persoonlijke gegevens de kans aan hackers om diensten te kraken en miljoenen persoonlijke gegevens online te lekken.
Recente wetgevende initiatieven zoals de AVG in Europa, CCPA in Californië, LGPD in Brazilië, of de PDP-wet in India streven er allemaal naar om van bedrijven te eisen dat ze persoonlijke gegevens beschermen en privacy standaard implementeren, inclusief online. Grote technologiebedrijven zoals Google, Facebook en Amazon hebben al gigantische boetes gekregen voor vermeende privacyinbreuken.
Deze nieuwe wetten hebben gebruikers veel meer inspraak gegeven in hoe comfortabel ze zich voelen bij het delen van persoonlijk gegevens. Je hebt waarschijnlijk al op een heel aantal cookietoestemmingsbanners geklikt die deze keuze toelaten. Daarenboven implementeren webbrowsers technologische oplossingen om privacy te verbeteren, van het blokkeren van cookies van derden over het verbergen van gevoelige gegevens tot innovatieve manieren om legitiem gebruik van persoonlijke attributen te balanceren met de privacy van individuen.
In dit hoofdstuk geven we overzicht van de huidige staat van privacy op het web. We beschouwen eerst hoe gebruikersprivacy geschaad kan worden: we bespreken hoe websites je profileren door online tracking, en hoe ze toegang krijgen tot jouw gevoelige gegevens. We kijken dan naar de impact van tools die gebruikers in staat stellen om hun privacy te beschermen. Daarna gaan we dieper in op de manieren waarop websites gevoelige gegevens beschermen en jou een keuze geven via privacyvoorkeurssignalen. We eindigen met een vooruitblik op de inspanningen die browsers leveren om jouw privacy in de toekomst te vrijwaren.
Hoe website jou profileren: online tracking
Het HTTP-protocol is inherent toestandsloos, dus standaard is er geen manier voor een website om te weten of twee bezoeken op twee verschillende websites, of zelfs twee bezoeken op dezelfde website, van dezelfde gebruiker komen. Zulke informatie zou echter nuttig kunnen zijn voor websites om meer gepersonaliseerde gebruikerservaringen te bouwen, en voor derden die profielen van gebruikersgedrag over websites heen opbouwen om inhoud op het web te financieren via gerichte advertenties of om diensten te verlenen zoals fraudedetectie.
Helaas berust het verkrijgen van deze informatie momenteel vaak op online tracking, waarrond vele grote en kleine bedrijven hun handel hebben opgebouwd. Dit heeft zelf geleid tot oproepen om gerichte advertenties te verbieden, aangezien ingrijpende tracking niet verenigbaar is met gebruikersprivacy. Gebruikers willen mogelijk niet dat eender wie hun sporen op het web kan volgen—in het bijzonder als ze websites rond gevoelige onderwerpen bezoeken. We zullen kijken naar de voornaamste bedrijven en technologieën die het onlinetrackingecosysteem vormen.
Tracking door derden
Online tracking wordt vaak gedaan via bibliotheken van derden. Deze bibliotheken voorzien gewoonlijk een (nuttige) dienst, maar sommigen genereren daarbij ook een uniek identificatienummer voor elke gebruiker, dat dan gebruikt kan worden om gebruikers over websites heen te volgen en profileren. Het WhoTracksMe-project is toegewijd aan het ontdekken van de meest wijdverspreide online trackers. We gebruiken WhoTracksMe’s classificatie van trackers maar beperken ons tot vier categorieën, omdat deze het meest waarschijnlijk diensten omvatten waar tracking deel uitmaakt van hun voornaamste doel: advertenties, pornoadvertenties, siteanalytics en sociale media.
We zien dat domeinen die eigendom zijn van Google alomtegenwoordig zijn op de onlinetrackingmarkt. Google Analytics, dat websiteverkeer rapporteert, is aanwezig op bijna twee derde van alle websites. Rond de 30% van websites bevatten Facebook-bibliotheken, terwijl andere trackers minder dan 10% halen.
site_analytics wordt gebruikt op respectievelijk 73,53% en 70,46%, advertising op 68,83% en 67,99%, social_media op 12,89% en 11,66%, en ten slotte pornvertising op 0,56% en 0,60%.Over het algemeen bevatten 82,08% van mobiele sites en 83,33% van desktopsites minstens één tracker, meestal voor siteanalytics of advertentiedoeleinden.
Drie op vier websites hebben minder dan 10 trackers, maar er is een lange staart van sites met veel meer trackers: één desktopsite contacteert 133 (!) verschillende trackers.
Cookies van derden
De voornaamste technische aanpak om identificatienummers voor gebruikers op te slaan en op te vragen over sites heen is via cookies die blijvend opgeslagen worden in jouw browser. Merk op dat hoewel cookies van derden vaak gebruikt worden voor tracking over sites heen, ze ook gebruikt kunnen worden voor niet-trackingdoeleinden, zoals het delen van gegevens voor een widget van een derde over sites heen. We zochten naar de cookies die het vaakst voorkwamen tijdens het browsen van het web, en de domeinen die ze plaatsen.
doubleclick.net wordt gebruikt op 30,49% van desktoppagina’s en 28,72% van mobiele pagina’s, facebook.com respectievelijk op 23.07 en 21,43%, youtube.com op 10,02% en 8,83%, google.com op 8,62% en 8,45%, yandex.ru op 4,42% en 5,17%, pubmatic.com op 3,82% en 4,73%, rlcdn.com op 4,01% en 3,99%, openx.net op 3,57% en 4,42%, adsrvr.org op 4,00% en 3,90%, en ten slotte yahoo.com op 3,80% en 3,70%.Googles dochteronderneming DoubleClick staat op de eerste plaats door cookies te zetten op 31,4% van desktopwebsites en 28,7% van mobiele websites. Een andere voorname speler is Facebook, die cookies opslaat op 21,4% van mobiele websites. De meeste andere topdomeinen die cookies zetten zijn verwant aan online advertenties.
test_cookie voor doubleclick.net wordt gebruikt door 30,20% van desktopsites en 28,66% van mobiele sites, fr voor facebook.com door respectievelijk 23,04% en 20,96%, IDE voor doubleclick.net door 18,03% en 16,96%, NID voor google.com door 4,92% en 5,09%, yandexuid voor yandex.ru door 4,38% en 5,14%, yuidss voor yandex.ru door 4,38% en 5,14%, i voor yandex.ru door 4,34% en 5,09%, ymex voor yandex.ru door 4,32% en 5,08%, yabs-sid voor yandex.ru door 4,32% en 5,08%, TDID voor adsrvr.org door 3,71% en 3,89%.Als we kijken naar de specifieke cookies die deze websites zetten, is de meest voorkomende cookie van een tracker de test_cookie van doubleclick.net. De volgende meest voorkomende cookies zijn verwant aan advertenties en blijven veel langer aanwezig op het toestel van een gebruiker: Facebooks fr-cookie blijft gedurende 90 dagen, terwijl DoubleClicks IDE-cookie voor 13 maanden in Europa en 2 jaar elders blijft.
Nu Lax de standaardwaarde van het SameSite-cookieattribuut wordt, moeten sites die cookies van derden willen blijven delen dit attribuut expliciet op None zetten. Voor derden hebben 85% op mobiel en 64% op desktop dit reeds gedaan, mogelijk voor trackingdoeleinden. Je kan meer over het SameSite-cookieattribuut lezen in het Beveiligingshoofdstuk.
Fingerprinting
Met de opkomst van privacybeschermende tools zoals adblockers en initiatieven van grote browsers zoals Firefox, Safari, en vanaf 2023 ook Chrome om cookies van derden uit te faseren, zijn trackers op zoek naar meer hardnekkige en verdoken manieren om gebruikers over sites heen te volgen.
Een van die technieken is browser fingerprinting (letterlijk: “vingerafdrukken”). Een website verzamelt gegeven over een gebruikerstoestel, zoals de user agent, schermresolutie en geïnstalleerde lettertypes, en gebruikt de vaak unieke combinatie van deze waarden om een vingerafdruk te creëren. Deze vingerafdruk wordt opnieuw gecreëerd elke keer wanneer een gebruiker de website bezoekt en kan dan vergeleken worden om de gebruiker te identificeren. Hoewel deze methode gebruikt kan worden voor fraudedetectie, wordt ze ook gebruikt om terugkerende gebruikers aanhoudend te volgen, of om gebruikers te volgen over sites heen.
Het detecteren van fingerprinting is complex: het is effectief door een combinatie van methodeoproepen en event listeners die ook gebruikt kunnen worden voor niet-trackingdoeleinden. In plaats van op deze individuele methoden te focussen, focussen we daarom op vijf populaire bibliotheken die het eenvoudig maken voor een website om fingerprinting te implementeren.
Op basis van het percentage van websites dat deze diensten van derden gebruikt, kunnen we zien dat de meest gebruikte bibliotheek, Fingerprint.js, 19 keer meer gebruikt wordt op desktop dan de tweede populairste bibliotheek. Het algemene percentage van websites dat een externe bibliotheek gebruikt voor fingerprinting is echter vrij klein.
CNAME-tracking
Verdergaand met technieken die blokkades op tracking door derden omzeilen, is CNAME-tracking een nieuwe aanpak waar een eerstepartijsubdomein het gebruik van een derdepartijdienst maskeert door een CNAME-record op DNS-niveau te gebruiken. Vanuit het standpunt van de browser gebeurt alles in een eerstepartijcontext, dus geen van de tegenmaatregelen voor derde partijen worden toegepast. Grote trackingbedrijven zoals Adobe en Orale bieden al CNAME-trackingoplossingen aan hun klanten aan. Voor de resultaten voor CNAME-gebaseerde tracking in dit hoofdstuk refereren we naar onderzoek uitgevoerd door een van de auteurs van die hoofdstuk (en anderen) waar zij een methode hebben ontwikkeld om CNAME-gebaseerde tracking te detecteren, op basis van DNS-gegevens en verzoekgegevens van HTTP Archive.
Het populairste bedrijf dat CNAME-gebaseerde tracking uitvoert is Adobe, dat aanwezig is op 0,59% van desktopwebsites en 0,41% van mobiele websites. Ook opmerkelijk qua grootte is Pardot, met respectievelijk 0,41% en 0,26%.
Deze getallen mogen kleine percentages lijken, maar die mening verandert wanneer we de gegevens opdelen op basis van websitepopulariteit.
Wanneer we kijken naar de rang van de websites die CNAME-gebaseerde tracking gebruiken, zien we dat 5,53% van de top 1.000 websites op mobiel een CNAME-tracker bevatten. In de top 100.000 zakt dit tot 2,78% van de websites en wanneer we naar de volledige gegevens kijken zakt dit tot 0,52%.
com-achtervoegsel gebruiken CNAME-tracking, voor edu is dit respectievelijk 0,18% en 0,10%, voor jp it’s 0,03% en 0,04%, voor org 0,04% en 0,03%, voor co.jp 0,03% en 0,02%, voor ca 0,02% en 0,01%, voor de 0,02% en 0,02%, voor ru 0,01% en 0,01%, voor com.au 0,02% en 0,01%, en ten slotte voor edu.au 0,02% en 0,01%.Afgezien van het .com-achtervoegsel, heeft een groot aantal van de websites die CNAME-gebaseerde tracking gebruikt een .edu-domein. Een opmerkelijk aantal CNAME-trackers is ook aanwezig op .jp- en .org-websites.
CNAME-gebaseerde tracking kan een tegenmaatregel zijn wanneer de gebruiker mogelijk beschermen tegen volgen door derden heeft ingeschakeld. Aangezien weinig trackerblokkerende tools en browsers al een verdediging tegen CNAME-tracking hebben geïmplementeerd, is het sterk aanwezig op een aantal websites tot op heden.
(Re)targeting
Advertisement retargeting refereert naar de praktijk om bij te houden welke producten een gebruiker bekeken maar niet gekocht heeft, en op te volgen met advertenties voor deze producten op verschillende websites. In plaats van te kiezen voor een agressieve marketingstrategie terwijl een gebruiker de website bezoekt, kiest de website ervoor om de gebruiker te overhalen om het product te kopen door deze voortdurend te herinneren aan het merk en product.
Een aantal trackers bieden een oplossing aan voor retargeting. De meest gebruikte, Google Remarketing Tag, is aanwezig op 26,92% van de websites op desktop en 26,64% van de websites op mobiel, ver boven alle andere diensten die elk door minder dan 1,25% van websites gebruikt worden.
Hoe websites jouw gevoelige gegevens behandelen
Sommige websites vragen toegang tot specifieke functies en browser-API’s die een impact kunnen hebben op de privacy van een gebruiker, bijvoorbeeld door het gebruiken van locatiegegevens, de microfoon, de camera, enz. Deze functies hebben meestal zeer nuttige toepassingen, zoals het ontdekken van nabijgelegen interessante locaties of het toelaten aan mensen om met elkaar te communiceren. Hoewel deze functie enkel worden geactiveerd wanneer een gebruiker toestemming geeft, is er een risico op het onthullen van gevoelige gegevens als een gebruiker niet volledig begrijpt hoe deze bronnen worden gebruikt, of als een website zich misdraagt.
We keken naar hoe vaak websites toegang vragen tot gevoelige bronnen. Daarnaast is er telkens wanneer een dienst gevoelige gegevens opslaat het gevaar dat hackers deze gegevens stelen en lekken. We zullen kijken naar recente gegevenslekken die aantonen dat dit gevaar reëel is.
Toestelsensoren
Sensoren kunnen nuttig zijn om een website interactiever te maken maar kunnen ook misbruikt worden voor het fingerprinten van gebruikers. Gebaseerd op het gebruik van JavaScript event listeners, wordt de oriëntatie van het toestel het meest opgevraagd, zowel op mobiel als op desktop. Merk op dat we zochten naar de aanwezigheid van event listeners op websites, maar we weten niet of deze code effectief werd uitgevoerd. Het gebruik van toestelsensoren is in deze sectie daarom een bovengrens.
deviceOrientation wordt gevonden op 3,32% van de desktopsites en 3,23% van de mobiele sites, deviceReady op 1,12% en 1,23%, devicemotion op 0,65% en 0,66%, deviceChange op 0,03% en 0,02%, en ten slotte deviceproximity op 0,03% en 0,02%.Mediatoestellen
De MediaDevices API kan gebruikt worden om toegang te krijgen tot aangesloten media-invoerbronnen zoals camera’s, microfoon en het delen van een scherm.
MediaDevicesEnumerateDevices-API gebruikte.
Op 7,23% van de desktopwebsites en 5,33% van de mobiele websites wordt de enumerateDevices()-methode opgeroepen, die een lijst teruggeeft van de aangesloten invoerbronnen.
Geolocation-as-a-service
Geolocatiediensten voorzien GPS- en andere locatiegegevens (zoals IP-adres) van een gebruiker en kunnen gebruikt worden door trackers om relevantere inhoud weer te geven aan de gebruiker, naast andere zaken. We analyseren daarom het gebruik van “geolocation-as-a-service”-technologieën op websites, gebaseerd op bibliotheken gedetecteerd met Wappalyzer.
We zien dat de populairste dienst, ipify, wordt gebruikt op 0,09% van de desktopwebsites en 0,07% van de mobiele websites. Het lijkt er dus op dat weinig websites locatiediensten gebruiken.
GeolocationGetCurrentPosition wordt gebruikt door 0,59% van de desktopsites en 0,63% van de mobiele sites, GeolocationSecureOrigin door respectievelijk 0,59% en 0,62%, GeolocationInsecureOrigin door 0,01% en 0,02%, GeolocationWatchPosition door 0,02% en 0,02%, GeolocationSecureOriginIframe door 0,02% en 0,02%, GeolocationDisabledByFeaturePolicy door 0,02% en 0,01%, en ten slotte GeolocationInsecureOriginIframe door 0,00% en 0,01%.Geolocatiegegevens kunnen ook opgevraagd worden door websites via een webbrowser-API. We zien dat 0,59% van de websites op een desktopclient en 0,63% van de websites op een mobiele client de huidige positie van een gebruiker opvragen (gebaseerd op Blinkfuncties).
Gegevenslekken
Slecht beveiligingsbeheer binnen een bedrijf kan een {significante impact hebben op de privégegevens van hun klanten. Have I Been Pwned laat aan gebruikers toe om te controleren of hun e-mailadres of telefoonnummer gelekt werd in een gegevenslek. Op het moment van schrijven heeft Have I Been Pwned 562 gegevenslekken bijgehouden, waarin 640 miljoen gegevens gelekt werden. Alleen al in 2020 werden 40 diensten gekraakt en de persoonlijke gegevens van miljoenen gebruikers gelekt. Drie van deze lekken werden gemarkeerd als gevoelig, wat verwijst naar de mogelijkheid om een negatieve impact te hebben op de gebruiker als iemand de gegevens van die gebruikers in het gegevenslek zou vinden. Een voorbeeld van een gevoelig gegevenslek is “Carding Mafia”, een platform waar gestolen kredietkaarten worden verhandeld.
Merk op dat 40 gegevenslekken in het voorbije jaar een ondergrens is, aangezien veel gegevenslekken pas ontdekt of publiek gemaakt worden verschillende maanden nadat ze hebben plaatsgevonden.
Elk gegevenslek dat Have I Been Pwned bijhoudt lekt e-mailadressen, aangezien gebruikers zo opvragen of hun gegevens gelekt zijn. Gelekte e-mailadressen zijn reeds een enorm privacyrisico, aangezien veel gebruikers hun volledige naam of gegevens gebruiken om hun e-mailadres aan te maken. Daarenboven wordt veel andere zeer gevoelige informatie gelekt in sommige gegevenslekken, zoals de genders van gebruikers, bankrekeningnummers of zelfs volledige fysieke adressen.
Hoe websites jouw gevoelige gegevens beschermen
Wanneer je op het web browset, zijn er bepaalde gegevens die je mogelijk privé wilt houden: de webpagina’s die je bezoekt, eventuele gevoelige gegevens die je in formulieren invult, je locatie, enzovoort. In het Beveiligingshoofdstuk kan je leren hoe 91,1% van de mobiele sites HTTPS hebben geactiveerd om jouw gegevens te beschermen tegen snuffelen terwijl die het internet doorkruisen. Hier zullen focussen op hoe websites browsers verder kunnen opleggen om privacy te verzekeren voor gevoelige bronnen.
Permissions Policy / Feature Policy
De Permissions Policy (“toestemmingsbeleid”, voorheen Feature Policy of “functiebeleid” genoemd) laat websites toe om te definiëren welke webfuncties ze van plan zijn te gebruiken, en welke functies expliciet door de gebruiker goedgekeurd dienen te worden wanneer ze bijvoorbeeld door derden worden gevraagd. Dit geeft websites controle over de functies waartoe scripts van derden toegang kunnen vragen. Een Permissions Policy kan bijvoorbeeld door een website gebruikt worden om te verzekeren dat geen enkele derde partij op hun website toegang vraagt tot de microfoon. Dit beleid laat aan ontwikkelaars toe om fijnmazig te kiezen welke web-API’s ze van plan zijn te gebruiken, door ze met het allow-attribuut te specificeren.
geolocation wordt gebruikt door 2.222 desktopsites en 2.323 mobiele sites, microphone door respectievelijk 2.199 en 2.310, camera door 2.082 en 2.197, payment door 1.748 en 1.879, usb door 1.354 en 1.492, gyroscope door 1.145 en 1.025, magnetometer door 1.141 en 1.024, interest-cohort door 1.037 en 1.019, fullscreen door 940 en 873, accelerometer door 892 en 852.De meest gebruikte instructies in verband met de Feature Policy worden hierboven getoond. Op 3.049 websites op mobiel en 2.901 websites op desktop wordt het gebruik van de microfoonfunctie gespecificeerd. Een zeer kleine subset van onze gegevens, wat toont dat dit vooralsnog een nichetechnologie is. Andere functies die vaak beperkt worden zijn geolocatie, camera en betalingen.
Om een dieper begrip te krijgen over hoe de instructies gebruikt worden, keken we naar de 3 meest gebruikte instructies en de verdeling van de waarden die aan deze instructies toegekend worden.
microphone wordt gezet to self voor 0,08% van de mobiele sites, het wordt gezet op none voor 0,49% van de sites, en wordt gezet op * voor 0,03% van de sites. geolocation wordt gezet op self voor 0,17% van de mobiele sites, het wordt gezet op none voor 0,34% van de sites, en wordt gezet op * voor 0,05% van de sites. camera wordt gezet op self voor 0,09% van de mobiele sites, het wordt gezet op none voor 0,46% van de sites, en wordt gezet op * voor 0,03% van de sites.none is de meest gebruikte waarde. Dit specificeert dat de functie uitgeschakeld is in de topniveau- en geneste browsingcontexten. De tweede meest gebruikte waarde self wordt gebruikt om aan te geven dat de functie toegelaten is in het huidige document en binnen dezelfde oorsprong, terwijl * volledige toegang toelaat over oorsprongen heen.
Referrer Policy
HTTP-verzoeken kunnen een optionele Referer-header (“verwijzer”) bevatten, die de oorsprong of webpagina-URL aangeven waarvan een verzoek gemaakt werd. De Referer-header kan aanwezig zijn in verschillende types verzoeken:
- Navigatieverzoeken, wanneer een gebruiker op een link klikt.
- Verzoeken voor subbronnen, wanneer een browser afbeeldingen, iframes, scripts en andere bronnen die een pagina nodig heeft opvraagt.
Voor navigaties en iframes, kunnen deze gegevens ook opgevraagd worden via JavaScript door document.referrer te gebruiken.
De Referer-waarde kan goede inzichten bieden. Maar wanneer de volledige URL inclusief het pad en de vraagstring in de Referer over oorsprongen heen gestuurd wordt, kan dit privacyverhinderend zijn: URL’s kunnen privé-informatie bevatten—soms zelfs identificerende of gevoelige informatie. Het stilletjes lekken hiervan over oorsprongen heen kan de privacy van gebruikers aantasten en beveiligingsrisico’s inhouden. De HTTP-header Referrer-Policy laat ontwikkelaars toe om te beperken welke verwijzergegevens toegankelijk wordt gemaakt aan verzoeken vanop hun website, om dit risico te verminderen.
Een eerste punt om te noteren is dat de meeste sites niet expliciet een Referrer Policy zetten. Maar 11,12% van de desktopwebsites en 10,38% van de mobiele websites definiëren expliciet een Referrer Policy. De rest ervan (de overige 88,88% op desktop en 89,62% op mobiel) zullen terugvallen op het standaardbeleid van de browser. De meeste grote browsers hebben recent strict-origin-when-cross-origin als standaardbeleid geïntroduceerd, zoals Chrome in augustus 2020 en Firefox in maart 2021. strict-origin-when-cross-origin verwijdert het pad en vraagfragmenten van de URL op verzoeken over oorsprongen heen, wat beveiligings- en privacyrisico’s vermindert.
no-referrer-when-downgrade wordt gebruikt op 3,63% van de desktopsites en 3,31% van de mobiele sites, strict-origin-when-cross-origin op respectievelijk 1,95% en 1,56%, always op 1,08% en 0,82%, unsafe-url op 0,47% en 0,52%, same-origin op 0,51% en 0,44%, origin op 0,39% en 0,51%, no-referrer op 0,34% en 0,31%, origin-when-cross-origin op 0,31% en 0,29%, strict-origin op 0,26% en 0,23%, en ten slotte no-referrer, strict-origin-when-cross-origin op 0,09% en 0,08%.De meest voorkomende Referrer Policy die expliciet gezet wordt is no-referrer-when-downgrade. Deze wordt gezet op 3,38% van de websites op mobiele clients en 3,81% van de websites op desktopclients. no-referrer-when-downgrade is niet privacyverbeterend. Met dit beleid worden volledige URL’s van de pagina’s die een gebruiker bezoekt op een gegeven site gedeeld in HTTPS-verzoeken over oorsprongen heen (de overgrote meerderheid van verzoeken), wat deze informatie toegankelijk maakt voor andere partijen (oorsprongen).
Daarenboven zetten ongeveer 0,5% van de websites de waarde van de Referrer Policy op unsafe-url, wat toelaat dat de oorsprong, gastheer en vraagstring met elk verzoek gestuurd worden, ongeacht het beveiligingsniveau van de ontvanger. In dit geval zou een verwijzer in klaartekst verzonden kunnen worden, wat potentieel privégegevens lekt. Wat verontrustend is, is dat er websites die actief geconfigureerd zijn om dit gedrag toe te laten.
Merk op: Websites kunnen de verwijzerinformatie ook als een URL-parameter naar de bestemmingssite sturen. We hebben het gebruik van dat mechanisme in dit rapport niet gemeten.
User-Agent Client Hints
Wanneer een webbrowser een HTTP-verzoek maakt, zal het een User-Agent-header meesturen die informatie voorziet over de browser, het toestel en de netwerkmogelijkheden van de client. Dit kan echter misbruikt worden om gebruikers te profileren of uniek te identificeren door fingerprinting.
User-Agent Client Hints voorzien toegang tot dezelfde informatie als de User-Agent-string, maar op een meer privacybeschermende manier. Dit zal op zijn beurt aan browsers toelaten om uiteindelijk de hoeveelheid informatie die standaard door de User-Agent-string teruggegeven wordt ter verminderen, zoals Chrome voorstelt met een geleidelijk plan voor User Agent Reduction (“User Agent-vermindering”).
Servers kunnen hun ondersteuning voor deze Client Hints aangeven door de Accept-CH-header te specificeren. Deze header lijst de attributen op die de server vraagt van de client om een toestel- of netwerkspecifieke bron terug te geven. Over het algemeen voorzien Client Hints een manier voor servers om enkel de minimaal nodige informatie te verkrijgen op inhoud op een efficiënte manier terug te geven.
Op dit moment hebben echter weinig sites Client Hints geïmplementeerd. We zien ook een groot verschil tussen het gebruik van Client Hints op populair en minder populaire websites. 3,67% van de top 1.000 populairste websites op mobiel vragen Client Hints op. In de top10.000 websites daalt het implementatiepercentage tot 1,44%.
Hoe websites jou een privacykeuze geven: Privacyvoorkeurssignalen
In het licht van de recente introductie van privacyreguleringen, zoals die vermeld in de introductie, zijn websites verplicht om expliciete gebruikerstoestemming te vragen om persoonlijke gegevens te verzamelen voor niet-essentiële functies zoals marketing en analytics.
Websites zijn daarom cookietoestemmingsbanners, privacybeleiden en andere mechanismen (die doorheen de tijd geëvolueerd zijn) beginnen gebruiken om gebruikers te informeren over welke gegevens deze sites verwerken, en om ze een keuze te geven. In dit deel kijken we naar hoe vaak deze tools voorkomen.
Platformen voor toestemmingsbeheer
Platformen voor toestemmingsbeheer (“Consent Management Platforms” of ook CMP’s) zijn bibliotheken van derden die websites kunnen insluiten om een cookietoestemmingsbanner aan hun gebruikers aan te bieden. We zagen dat rond de 7% van websites een platform voor toestemmingsbeheer gebruikten.
De populairste bibliotheken zijn CookieYes en Osano, maar we vonden meer dan 20 verschillende bibliotheken die aan websites toelaten om cookietoestemmingsbanners in te sluiten. Elke bibliotheek was maar aanwezig op een klein deel van websites, minder dan 2% elk.
Toestemmingsframeworks van het IAB
Het Transparency and Consent Framework (TCF) is een initiatief van het Interactive Advertising Bureau Europe (IAB) om een industriestandaard aan te bieden voor het communiceren van gebruikerstoestemming naar adverteerders. Het framework bestaat uit een Global Vendor List, waarin aanbieders het rechtmatige doel van de verwerkte gegevens kunnen specificeren, en een lijst van CMP’s die als een tussenpartij tussen aanbieders en uitgevers handelen. Elke CMP is verantwoordelijk voor het communiceren van de wettelijke basis en het opslaan van de toestemmingsoptie die de gebruiker in de browser gegeven heeft. We verwijzen naar de opgeslagen cookie als de toestemmingsstring (“consent string”).
TCF is bedoeld om een mechanisme te zijn dat aan de AVG voldoet in Europa, hoewel een recente beslissing door de Belgische Gegevensbeschermingsautoriteit concludeerde dat dit systeem nog steeds de AVG overtreedt. Wanneer de CCPA in voege trad in Californië, ontwikkelde IAB Tech Lab US de technische specificaties voor U.S. Privacy (USP), op basis van dezelfde concepten.
Hierboven tonen we de verdeling van het gebruik van beide versies van TCF en van USP. Merk op dat onze gegevensverzameling in de VS gebaseerd is, en dat we daarom niet verwachten dat veel websites TCF geïmplementeerd hebben. Minder dan 2% van de websites gebruiken eender welke versie van TCF, terwijl twee keer zo veel websites het US Privacy-framework gebruiken.
In de 10 populairste platformen voor toestemmingsbeheer die deel uitmaken van het framework, vinden we bovenaan Quantcast met 0,34% op mobiel. Andere populaire oplossingen zijn Didomi met 0,24%, en Wikia, met 0,30%.
In het USP-framework, worden de privacyinstellingen van de website en gebruiker geëncodeerd in een privacystring.
1--- wordt gebruikt door 0,87% van de desktopwebsites en 0,80% van de mobiele websites, 1YNY is respectievelijk 0,72% en 0,64%, 1YNN is 0,07% en 0,06%, en blank is 0,01% en 0,00%.De meest voorkomende privacystring is 1---. Dit geeft aan dat de CCPA niet van toepassing is op de website en dat de website daarom niet verplicht is om de gebruiker de mogelijkheid te geven om zich af te melden. CCPA is enkel van toepassing op bedrijven waarvan de voornaamste handelspraktijk het verkopen van persoonlijke gegevens omvat, of op bedrijven die gegevens verwerken en een jaarlijkse omzet van meer dan 25 miljoen dollar hebben. De tweede meest voorkomende string is 1YNY. Dit geeft aan dat de website “kennisgeving en de mogelijkheid heeft gegeven om zich af te melden voor de verkoop van gegevens”, maar dat de gebruiker zich niet heeft afgemeld voor de verkoop van hun persoonlijke gegevens.
Privacybeleid
Tegenwoordig hebben de meeste websites een privacybeleid, waar gebruikers kunnen lezen welke types informatie over hen worden bijgehouden en verwerkt.
Door te zoeken naar trefwoorden zoals “privacybeleid”, “cookiebeleid” en meer, in een aantal talen, zien we dat 39,70% van de mobiele websites, en 43,02% van de desktopsites naar een of ander privacybeleid verwijzen. Hoewel het voor sommige websites niet nodig is dat ze zulk een beleid hebben, verwerken veel websites persoonlijke gegevens en zouden deze daarom een privacybeleid moeten hebben om volledig transparant te zijn naar hun gebruikers toe.
Do Not Track - Global Privacy Control
De Do Not Track (DNT) HTTP-header kan gebruikt worden om naar websites te communiceren dat een gebruiker niet gevolgd wenst te worden. We kunnen het aantal websites dat de huidige waarde voor DNT lijkt op te vragen hier beneden zien, gebaseerd op de aanwezigheid van de Navigator.doNotTrack JavaScript-oproep.
NavigatorDoNotTrack-functie te gebruiken. 17,37% van de desktopsites en 17,39% van de mobiele sites vragen dit op.Ongeveer hetzelfde percentage pagina’s op mobiel en desktop gebruiken DNT. In de praktijk respecteert echter bijna geen enkele website effectief het verzoek tot afmelden via DNT. De Tracking Protection Working Group, die DNT specificeert, sloot in 2018, vanwege een “gebrek aan steun”. Safari stopte dan met het ondersteunen van DNT om potentieel misbruik voor fingerprinting te voorkomen.
DNT’s opvolger Global Privacy Control (GPC) werd uitgebracht in oktober 2020 en is bedoeld om een beter afdwingbaar alternatief te voorzien, met de hoop dat deze dan ook betere aanvaarding ziet. Dit privacyvoorkeurssignaal wordt geïmplementeerd met één enkele bit in alle HTTP-verzoeken. We hebben nog geen opname geobserveerd, maar we kunnen verwachten dat dit in de toekomst zal verbeteren, aangezien grote browsers nu GPC beginnen te implementeren.
Hoe browsers hun privacyaanpak evolueren
Gegeven het streven om de privacy van gebruikers beter te beschermen terwijl ze op het web surfen, implementeren grote browsers nieuwe functies die de gevoelige gegevens van gebruikers beter zouden moeten beschermen. We hebben al manieren besproken waarop browsers meer privacybeschermende standaardinstellingen voor Referrer-Policy-headers en SameSite-cookies zijn beginnen afdwingen.
Verder trachten Firefox en Safari tracking te blokkeren door respectievelijk Verbeterde bescherming tegen volgen en Intelligente trackingpreventie.
Naast het blokkeren van trackers, heeft Chrome de Privacy Sandbox gelanceerd om nieuwe webstandaarden te ontwikkelen die privacyvriendelijkere functionaliteit voor verscheidene doeleinden voorzien, zoals advertenties en fraudebescherming. We zullen deze opkomende technologieën, die ontworpen zijn om de mogelijkheid voor sites om gebruikers te volgen te verminderen, nader bekijken.
Privacy Sandbox
Om feedback vanuit het ecosysteem te verkrijgen, worden vroege en experimentele versies van Privacy Sandbox-APIs initieel beschikbaar gemaakt door middel van functievlaggen voor tests door individuele ontwikkelaars, en dan in Chrome via oorsprongsproeven (“origin trials”). Sites kunnen deelnemen in deze oorsprongsproeven}om experimentele webplatformfuncties te testen, en commentaar te geven naar de webstandaardengemeenschap over de gebruiksvriendelijkheid, uitvoerbaarheid en effectiviteit van een functie, vooraleer ze voor alle websites standaard beschikbaar wordt gemaakt.
Disclaimer: Oorsprongsproeven zijn enkel beschikbaar voor een beperkte tijd. De getallen hieronder geven de toestand van Privacy Sandbox oorsprongsproeven weer op het moment van schrijven, in oktober 2021.
FLoC
Een van de meest spraakmakende experimenten uit de Privacy Sandbox was Federated Learning of Cohorts, of kort FLoC. De oorsprongsproef voor FLoC eindigde in juli 2021.
Selectie van advertenties op basis van interesses wordt vaak gebruikt op het web. FLoC voorzag een API die voorzag in dit specifieke gebruiksscenario zonder de noodzaak om individuele gebruikers te identificeren en volgen. FLoC heeft wat tegenwind gehad: Firefox en andere Chromium-gebaseerde browsers hebben geweigerd om het te implementeren, en de Electronic Frontier Foundation heeft de bezorgdheid geuit dat het mogelijk nieuwe privacyrisico’s kon introduceren. FLoC was echter een eerste experiment. Toekomstige iteraties van de API zouden deze bezorgdheden kunnen verminderen en breder gebruikt kunnen worden.
In plaats van unieke identificatienummers aan gebruikers toe te wijzen, bepaalde de browser met FLoC de cohorte van een gebruiker: een groep met duizenden mensen die gelijkaardige pagina’s bezochten en daarom mogelijk interessant zijn voor dezelfde adverteerders.
Aangezien FLoC een experiment was, was het niet breed uitgerold. In de plaats daarvan konden websites dit testen door deel te nemen aan een oorsprongsproef. We vonden 62 en 64 websites die FLoC testten op respectievelijk desktop en mobiel.
Dit is hoe het eerste FLoC-experiment werkte: terwijl een gebruiker doorheen het web bewoog, gebruikte hun browser het FLoC-algoritme om hun interessecohorte te bepalen, die dezelfde was voor duizenden browsers met een gelijkaardige recente browsergeschiedenis. De browser herberekende zijn cohorte regelmatig, op het toestel van de gebruiker, zonder individuele browsinggegevens te delen met de browserontwikkelaar of andere partijen. Tijdens het bepalen van zijn cohorte koos een browser uit cohorten die geen gevoelige categorieën onthulden.
Individuele gebruikers en websites kunnen aangeven dat ze niet meegenomen willen worden bij de berekening van de cohort.
We zien dat 4,10% van de top 1.000 websites zich hebben afgemeld voor FLoC. Over alle websites heen heeft minder dan 1% zich afgemeld.
Andere Privacy Sandbox-experimenten
Binnen Googles Privacy Sandbox-initiatieven zijn een aantal experimenten in verscheidene stadia van ontwikkeling.
De Attribution Reporting API (voorheen Conversion Measurement genoemd) maakt het mogelijk om te meten wanneer gebruikersinteractie met een advertentie leidt tot een conversie—bijvoorbeeld, wanneer een klik op een advertenties uiteindelijk leidt tot een aankoop. We zagen de eerste oorsprongsproef (die eindigde in oktober 2021) geactiveerd op 10 oorsprongen.
FLEDGE (First “Locally-Executed Decision over Groups” Experiment) tracht gerichte advertenties aan te pakken. De API kan in huidige versies van Chrome lokaal door individuele ontwikkelaars getest worden maar er is geen oorsprongsproef in oktober 2021.
Trust Tokens laat aan een website toe om een beperkte hoeveelheid informatie over te brengen van de ene browsingcontext naar een andere om fraude te helpen bestrijden, zonder passieve tracking. We zagen de eerste oorsprongsproef (die zal eindigen in mei 2022) geactiveerd op 7 oorsprongen die waarschijnlijk ingesloten zijn op een aantal websites als dienstverleners.
CHIPS (Cookies Having Independent Partitioned State) laat aan websites toe om cookies over sites heen als “gepartitioneerd” aan te duiden, wat ze in een aparte cookie jar per topniveausite steekt. (Firefox heeft reeds de gelijkaardige Total Cookie Protection-functie voor cookiepartitionering geïntroduceerd.) In oktober 2021 was er geen oorsprongsproef voor CHIPS.
Fenced Frames beschermt toegang door frames tot gegevens van de pagina die ze insluit. In oktober 2021 was er geen oorsprongsproef.
SameParty gebruikt op 38 desktopsites en 73 mobiele sites, voor derdepartijcookies op 2.527 desktopsites en 1.805 mobiele sites.
Ten slotte laten First-Party Sets aan website-eigenaars toe om een verzameling van afzonderlijke domeinen te definiëren die eigenlijk aan dezelfde entiteit behoren. Eigenaars kunnen dan een SameParty-attribuut zetten op cookies die over sitecontexten heen verzonden zouden moeten worden, zolang de sites tot dezelfde first-party set behoren. Een eerste oorsprongsproef eindigde in september 2021. We zagen het SameParty-attribuut op een duizendtal cookies.
Besluit
De privacy van gebruikers blijft kwetsbaar op het web vandaag de dag: meer dan 80% van alle websites hebben een of andere vorm van tracking geactiveerd, en nieuwe trackingmechanismen zoals CNAME-tracking worden ontwikkeld. Sommige sites verwerken ook gevoelige gegevens zoals geolocaties, en als ze niet voorzichtig zijn, kunnen potentiële gegevenslekken ertoe leiden dat de persoonlijke gegevens van gebruikers onthuld worden.
Gelukkig heeft verhoogde bewustwording over de nood aan privacy op het web geleid tot concrete actie. Websites hebben nu toegang tot functie die hen toelaten om toegang tot gevoelige bronnen te beschermen. Wetgeving over de hele wereld dwingt expliciete gebruikerstoestemming af voor het delen van persoonlijke gegevens. Websites implementeren een privacybeleid en cookiebanners om daaraan te voldoen. Ten slotte zijn browsers innovatieve technologieën aan het voorstellen en ontwikkelen om doeleinden zoals advertenties en fraudedetectie op een privacyvriendelijkere manier te blijven ondersteunen.
Uiteindelijk zouden gebruikers gemachtigd moeten worden om inspraak te hebben in hoe hun persoonlijke gegevens worden behandeld. Ondertussen zouden browsers en website-eigenaars de technische mogelijkheden moeten ontwikkelen en uitrollen om te verzekeren dat de privacy van gebruikers beschermd wordt. Door privacy te verweven doorheen onze interacties met het web, kunnen gebruikers zich zekerder voelen dat hun persoonlijke gegevens goed beschermd worden.
