80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Jokainen evästebanneri antaa saman hiljaisen lupauksen: klikkaa "Hylkää" ja seuranta loppuu. Banneri katoaa ja selaat rauhassa. Tämä on suostumusmallin perusta -- ajatus siitä, että käyttäjillä on merkityksellinen ja täytäntöönpanokelpoinen valinta.

Testasimme tämän lupauksen 28 891 EU-verkkosivustolla. 80,4 %:ssa niistä lupaus petetään. Seuranta jatkuu sen jälkeen, kun käyttäjä nimenomaisesti klikkaa hylkää. Evästeet säilyvät. Mainospikselit jatkavat laukeamista. Ja 1 642 sivustolla evästeet, jotka hylkäystoiminto alun perin poisti, palaavat seuraavalla sivunlatauksella -- malli, jota kutsumme nimellä consent respawn.

Tämä ei ole marginaalinen havainto muutamasta väärin konfiguroidusta sivustosta. Se viittaa järjestelmätason ongelmaan mekanismissa, johon sadat miljoonat EU-asukkaat luottavat yksityisyytensä suojelemiseksi.

Mitä "Hylkää" tarkoittaa oikeudellisesti

Oikeudellinen kehys on selkeä. ePrivacy-direktiivin artiklan 5(3) mukaan tietojen tallentaminen tai käyttö käyttäjän päätelaitteella edellyttää ennakkosuostumusta, poikkeuksena vain evästeet, jotka ovat ehdottomasti välttämättömiä palvelulle, jota käyttäjä on nimenomaisesti pyytänyt. GDPR:n artikla 7(3) lisää, että suostumuksen peruuttamisen on oltava yhtä helppoa kuin sen antamisen, ja rekisterinpitäjän on toimittava peruuttamisen mukaisesti.

EDPB:n ohjeet 05/2020 suostumuksesta GDPR:n nojalla täsmentävät, mitä tämä tarkoittaa hylkäyspainikkeille: jos verkkosivusto tarjoaa "Hyväksy kaikki" -vaihtoehdon, sen on tarjottava myös yhtä näkyvä ja helposti saavutettava vaihtoehto kieltäytyä. Ja kieltäytymisen on oltava tehokas -- sen on todella estettävä se käsittely, jonka suostumus olisi sallinut.

CJEU vahvisti tämän Planet49-tuomiossa (C-673/17): suostumus edellyttää selkeää myönteistä toimenpidettä, eivätkä esivalitut valintaruudut ole pätevä suostumus. Looginen seuraus on, että kieltäytymistä -- nimenomaista kielteistä toimenpidettä -- on kunnioitettava yhtä lopullisesti kuin hyväksymistä. Jos "Hyväksy"-painikkeen klikkaaminen käynnistää seurannan, "Hylkää"-painikkeen klikkaamisen on lopetettava se. Ei osittain. Ei väliaikaisesti. Täydellisesti ja pysyvästi.

Tätä laki sanoo. Datamme näyttää, mitä todella tapahtuu.

Kuinka testaamme hylkäysprosessin

Hylkäysprosessitestimme on suunniteltu vastaamaan mahdollisimman tarkasti todellisen käyttäjän kokemusta hylkäyspainikkeen klikkaamisesta, lisättynä kattavalla instrumentoinnilla. Tässä prosessi vaihe vaiheelta:

Vaihe 1: Puhdas selainistunto. Skanneri käynnistää puhtaan Chromium-instanssin -- ei evästeitä, ei paikallista tallennustilaa, ei välimuistissa olevia resursseja, ei selaushistoriaa. Tämä on aito ensimmäinen vierailija ilman aikaisempaa suostumustilaa. Vaihe 2: Navigoi ja tallenna tila ennen suostumusta. Skanneri lataa kohde-URL:n ja odottaa sivun vakautumista. Ennen mitään vuorovaikutusta se tallentaa jokaisen selaimen evästeen, jokaisen tehdyn verkkopyynnön ja jokaisen kolmannen osapuolen domain-yhteyden. Tämä on lähtötila ennen suostumusta -- mitä sivusto tekee ennen kuin käyttäjällä on mahdollisuus tehdä valinta. Vaihe 3: Suostumusbannerin tunnistaminen. Käyttäen tunnistuskirjastoamme, joka kattaa 45 tunnettua CMP:tä ja yleisiä heuristiikkoja, skanneri tunnistaa suostumusmekanismin ja paikantaa hylkäyspainikkeen. Tämä vaihe käyttää kerroksellista lähestymistapaa: ensin tarkistetaan tunnetut CMP-skriptitunnisteet ja niihin liittyvät DOM-rakenteet, sitten varataan yleinen tunnistus kiinteästi tai tarttuvasti sijottuneista elementeistä, jotka sisältävät suostumukseen liittyvää tekstiä ja painiketekstejä kuten "Hylkää kaikki", "Kieltäydy", "Kiellä" tai vastaavia käännöksiä. Vaihe 4: Klikkaa hylkää. Skanneri klikkaa hylkäyspainiketta ja odottaa sivun vakautumista. "Vakautuminen" tarkoittaa odottamista, kunnes keskeneräiset verkkopyynnöt valmistuvat, DOM-muutokset lakkaavat ja mahdolliset animaatiot tai siirtymät päättyvät. Käytämme runsaita aikakatkaisuja välttääksemme vääriä positiivisia hitaista CMP-toteutuksista. Vaihe 5: Tilannekuva hylkäyksen jälkeen. Skanneri tallentaa täydellisen tilan uudelleen: kaikki evästeet, kaikki verkkoaktiviteetti, kaikki kolmannen osapuolen domainit. Tätä tilannekuvaa verrataan lähtötilaan ennen suostumusta, jotta nähdään mikä muuttui. Vaihe 6: Lataa uudelleen ja tarkista respawn. Skanneri lataa sivun uudelleen ja odottaa sen vakautumista. Sitten se ottaa viimeisen tilannekuvan. Tämä vaihe on kriittinen: se paljastaa, onko hylkäystoiminto pysyvä (kunnioitettu sivulatausten välillä) vai aktivoituvatko evästeet ja seuranta uudelleen sivun latautuessa. Jos vaiheessa 5 poistetut evästeet ilmestyvät uudelleen vaiheessa 6, kyseessä on consent respawn.

Jokainen vaihe tuottaa aikaleimattua, arkistoitavaa todistusaineistoa: täydelliset evästeluettelot nimineen, arvoineen, domaineineen, vanhentumisaikoineen ja lippuineen; täydelliset verkkopyyntölokit URL-osoitteineen, menetelmineen, vastauskoodeineen ja ajoituksineen; sekä kokonaissivun kuvakaappaukset. Tämä todisteketju mahdollistaa minkä tahansa yksittäisen havainnon todentamisen ja kyseenalaistamisen.

Tulokset: 80,4 % epäonnistui

28 891 verkkosivustosta, joilla suoritimme onnistuneesti koko hylkäysprosessitestin:

• 5 650 (19,6 %) läpäisi. Hylkäyksen jälkeen ei-välttämättömät evästeet poistettiin, seurantapyynnöt lakkasivat ja hylkäys säilyi sivulatausten välillä.
• 23 241 (80,4 %) epäonnistui. Seuranta jatkui jossain muodossa sen jälkeen, kun käyttäjä nimenomaisesti klikkasi hylkää.

Epäonnistumiset eivät ole yhdenmukaisia. Ne jakautuvat erillisiin luokkiin, jotka menevät päällekkäin -- yksittäinen sivusto voi osoittaa useita vikatiloja samanaikaisesti.

Pysyvät evästeet: 10 848 sivustoa

10 848 sivustolla (37,5 % testatuista) ei-välttämättömät evästeet säilyivät selaimessa hylkäysprosessin jälkeen. Nämä ovat evästeitä, jotka on luokiteltu analytiikka-, markkinointi- tai seurantatarkoituksiin ja jotka olisi pitänyt poistaa tai estää hylkäystoiminnon jälkeen.

Yleisimmät pysyvät evästeet kuuluvat Google Analyticsille (`_ga`, `_gid`, `_gat`), Meta/Facebookille (`_fbp`, `fr`) ja erilaisille mainosalustoille. Monissa tapauksissa CMP onnistuu poistamaan osan evästeistä mutta epäonnistuu kaikkien poistamisessa -- mikä viittaa puutteelliseen integraatioon suostumuksenhallintatyökalun ja sivuston kolmannen osapuolen skriptien täyden luettelon välillä.

Näiden evästeiden säilyminen hylkäyksen jälkeen ei ole pelkästään esteettinen ongelma. Jokainen niistä on pysyvä tunniste, joka yhdistää käyttäjän nykyisen istunnon aiempiin ja tuleviin vierailuihin. `_ga`-eväste on esimerkiksi yksilöllinen asiakastunniste, jota Google Analytics käyttää käyttäjän käyttäytymisen pitkittäisprofiilin rakentamiseen istuntojen välillä. Jos se säilyy hylkäyksen jälkeen, käyttäjän selaamista seurataan ja kootaan riippumatta hänen ilmaisemastaan kieltäytymisestä.

Pysyvät seuraimet: 14 547 sivustoa

14 547 sivustolla (50,3 % testatuista) seurantapalvelut pysyivät aktiivisina hylkäyksen jälkeen -- tarkoittaen, että selain jatkoi pyyntöjen tekemistä tunnetuille seurantadomaineille senkin jälkeen, kun käyttäjä klikkasi hylkäyspainiketta.

Tämä on erillinen vikatila evästeisiin verrattuna. Seurain voi olla aktiivinen ilman evästettä: pikselipyynnöt, beacon-kutsut ja skriptilataukset kaikki välittävät tietoa (vähintään käyttäjän IP-osoitteen, viittaussivun ja ajoitustiedot) kolmannen osapuolen palvelimille riippumatta siitä, onko eväste tallennettu. Tätä kutsutaan joskus "evästeettömäksi seurannaksi" ja se yleistyy jatkuvasti selainten tiukentaessa kolmannen osapuolen evästeiden rajoituksia.

Ero eväslelukeman (10 848) ja seurantaohjelmien lukeman (14 547) välillä on merkittävä. Se tarkoittaa, että noin 3 700 sivustolla hylkäystoiminto poisti evästeet onnistuneesti mutta ei estänyt seurantapyyntöjen jatkumista. CMP hoiti evästeiden siivoamisen mutta ei estänyt skriptejä, jotka tuottavat seurantaliikennettä alun perin. Tämä osoittaa yleisen arkkitehtuuriongelman: CMP on konfiguroitu hallitsemaan evästeitä (poistamaan ne hylkäyksessä, estämään ne latauksessa) mutta ei hallitsemaan skriptien suorittamista.

Consent respawn: 1 642 sivustoa, 4 932 evästettä

Consent respawn on huolestuttavin tunnistamamme malli. 1 642 verkkosivustolla evästeet, jotka hylkäystoiminto onnistuneesti poisti, ilmestyivät uudelleen sivun uudelleenlatauksen jälkeen. Näillä sivustoilla 4 932 yksittäistä evästettä osoitti tätä respawn-käyttäytymistä.

Consent respawn ei ole yhden CMP:n tai konfiguraation bugi. Se on rakenteellinen ongelma siinä, miten suostumus on toteutettu koko verkkopinossa.

Kuinka eväste palaa poistamisen jälkeen. Kun käyttäjä klikkaa hylkää, oikein konfiguroitu CMP tekee kaksi asiaa: se poistaa olemassa olevat ei-välttämättömät evästeet (asettamalla niiden vanhentumisajan menneisyyteen) ja päivittää suostumustietueen (yleensä itse eväste tai localStorage-merkintä), joka kertoo CMP:n estologiikalle estää ei-välttämättömien skriptien suorittaminen tulevilla sivulatauksilla. Jos molemmat toimivat, käyttäjä on puhdas: ei seurantaevästeitä, ei seurantaskriptejä.

Consent respawn tapahtuu, kun poistaminen onnistuu mutta estäminen epäonnistuu. Yleisin skenaario:

1. CMP poistaa `_ga`-evästeen, kun käyttäjä klikkaa hylkää.

2. CMP asettaa suostumustilan evästeen, johon tallennetaan, että käyttäjä on kieltäytynyt analytiikasta.

3. Seuraavalla sivulatauksella CMP tarkistaa suostumustilansa ja tietää, että käyttäjä kieltäytyi.

4. Mutta: Google Analytics -skriptitagi on upotettu suoraan sivupohjaan (tag managerin ulkopuolelle) tai se ladataan tag managerin säännöllä, joka ei tarkista suostumustilaa.

5. GA-skripti latautuu, havaitsee ettei `_ga`-evästettä ole, ja luo uuden.

6. Käyttäjän hylkäyspäätös on kumottu.

Tämän mallin variaatioihin kuuluvat: kolmannen osapuolen skriptit, jotka ladataan kovakoodatuilla `