How We Built a System That Scans 100,000 Websites for Cookie Consent Violations

Automatisoitu suostumusvaatimustenmukaisuuden tarkistaminen kuulostaa suoraviivaiselta, kunnes yrittää rakentaa sen. Naiivi lähestymistapa -- hae sivu, tarkista evästeet, etsi banneri -- ohittaa suurimman osan siitä, mikä on merkityksellistä. Suostumusrikkomukset ovat käyttäytymiseen perustuvia, eivät rakenteellisia. Ne ilmenevät skriptien suorittamisen ajoituksessa, verkkopyyntöjen sekvenssissä, käyttöliittymäelementtien reaktiossa käyttäjän vuorovaikutukseen ja tilan pysyvyydessä sivulatausten välillä. Mitään tästä ei voi arvioida ilman todellisen selaimen ajamista, sivun kanssa vuorovaikuttamista kuten ihminen tekisi ja tallentamista, mitä verkkoliikennetasolla todella tapahtuu.

Tämä kirjoitus kuvaa, miten rakensimme GDPR Monitorin takana olevan skannausmoottorin, tekniset haasteet, jotka veivät suurimman osan ajastamme, tekemämme arkkitehtuuripäätökset ja niiden syyt, sekä rajoitukset, joista olemme rehellisiä. Jos työskentelet verkkovaatimustenmukaisuuden, selaimen automatisoinnin tai laajamittaisen verkon mittaamisen parissa, tästä pitäisi löytyä jotain hyödyllistä.

Pipeline-katsaus

Jokainen skannaus kulkee kuuden vaiheen läpi. Pipelinen ymmärtäminen on välttämätön konteksti seuraavaksi käsiteltäville erityishaasteille.

Vaihe 1: Selaimen käynnistys ja eristäminen. Puhdas Chromium-instanssi käynnistyy ilman mitään tilaa -- ei evästeitä, ei localStorage-tietoja, ei välimuistia, ei service workereita. Tämä on puhdas laboratorio -takuu, joka tekee suostumusta edeltävästä mittauksesta merkityksellisen. Konfiguroimme standardinäkymän, realistisen user-agentin ja kohdemaan mukaiset Accept-Language-otsakkeet sekä vakioselainliput. Jokainen skannaus saa oman selainprosessinsa; skannausten välillä ei ole tilavuotoja. Vaihe 2: Navigointi ja tilannekuva ennen suostumusta. Skanneri navigoi kohde-URL:iin, odottaa sivun saavuttavan vakaan tilan (verkko hiljaisena, DOM asettuneena) ja tallentaa kaiken tapahtuneen: asetetut evästeet, tehdyt verkkopyynnöt (täydellisinä URL-osoitteineen, ajoituksineen ja vastausmetadatoineen), kolmannen osapuolen domainit, joihin on otettu yhteyttä, sekä kokonaissivun kuvakaappauksen. Tämä tilannekuva vastaa peruskysymykseen: mitä tämä verkkosivusto teki ennen kuin käyttäjällä oli mahdollisuus antaa suostumus? Vaihe 3: CMP:n tunnistaminen ja bannerin paikantaminen. Skanneri pyrkii tunnistamaan suostumuksenhallintatyökalun ja paikantamaan suostumusbannerin, hyväksymispainikkeen ja hylkäyspainikkeen. Tähän käytetään alla yksityiskohtaisemmin kuvattua kerroksellista tunnistusjärjestelmää. Vaihe 4: Suostumusinteraktio. Skanneri on vuorovaikutuksessa bannerin kanssa -- klikkaa hyväksy vakioprosessissa, klikkaa hylkää hylkäysprosessitestissä. Se odottaa sivun asettumista vuorovaikutuksen jälkeen, huomioiden animaatiot, skriptien uudelleenarvioinnin ja viivästetyn tag-laukaisun. Vaihe 5: Tilannekuva suostumuksen jälkeen ja vertailuanalyysi. Toinen täydellinen tilannekuva tallentaa tilan suostumusinteraktion jälkeen. Ennen suostumusta ja suostumuksen jälkeen otettujen tilannekuvien vertailu paljastaa, mikä muuttui: uudet evästeet, uudet seurantapyynnöt, suostumustila CMP:n rajapinnoissa. Vaihe 6: Analyysi, luokittelu ja raportin luominen. Raakadata syöttää analyysimo-duuleihin: evästeiden luokittelu tietokantaamme vasten, seurainten vastaavuuden tarkistus tunnettuihin malleihin, evästeiden eliniän arviointi, bannerin saavutettavuusauditointi, Google Consent Mode -validointi, sormenjälkisignaalien tunnistus ja riskipisteytys. Tuloksena on jäsennelty raportti havaintoineen, todisteartefakteineen ja yhdistelmäriskipistein.

Jokainen vaihe tuottaa aikaleimattua todistusaineistoa, joka tallennetaan pysyvästi. Mikä tahansa havainto voidaan jäljittää tiettyihin verkkopyyntöihin, eväste-merkintöihin tai kuvakaappauksiin.

Haaste 1: CMP:n tunnistaminen -- 45 alustaa, loputon vaihtelu

Suostumuksenhallinta ei ole standardoitu. Ei ole universaalia HTML-attribuuttia, pakollista JavaScript-rajapintaa eikä johdonmukaista DOM-rakennetta, joka sanoisi "tämä on suostumusbanneri." Tunnistuskirjastossamme on 45 erillistä CMP:tä, joista jokaisella on oma DOM-rakenteensa, skriptitunnisteensa, JavaScript-globaalinsa ja interaktiomallinsa. Näiden lisäksi 34,7 % 97 304 sivuston tutkimuksessamme havaituista bannereista oli yleisiä tai tunnistamattomia -- mukautettuja toteutuksia, alueellisia toimittajia tai minimaalisia ratkaisuja, jotka eivät vastaa mitään tunnettua CMP-tunnistetta.

Tunnistuksemme käyttää luottamuspohjaista, kerroksellista lähestymistapaa:

Kerros 1: Skriptitunnisteiden havaitseminen

Skanneri tarkistaa tunnettujen CMP-skriptien läsnäolon URL-mallin ja JavaScript-globaalien muuttujien perusteella. Cookiebot esimerkiksi latautuu osoitteesta `consent.cookiebot.com` ja paljastaa `window.Cookiebot`-globaalin. OneTrust latautuu osoitteesta `cdn.cookielaw.org` ja paljastaa `window.OneTrust`-globaalin. Jokaisella CMP:llä on ominaiset latausmallit, jotka voidaan havaita ennen DOM:n tarkastelua.

Tämä kerros on nopea ja korkean luottamuksen vastaavuus. Mutta sillä on kriittinen rajoitus: se kertoo, mikä CMP on läsnä sivulla, ei välttämättä mikä CMP vastaa suostumuksen bannerista. Sivusto voi ladata PiwikPROn analytiikkaa varten (joka sisältää CMP-komponentin) käyttäen samalla tarteaucitronia varsinaiseen suostumuksenhallintaan. Molempien skriptien havaitseminen on helppoa; sen tietäminen, kumpi hallitsee banneria, on vaikeampaa.

Kerros 2: Varmistettu selektorivastaavuus

Jokaiselle tunnetulle CMP:lle ylläpidämme kuratoitua joukkoa CSS-selektoreita, jotka luotettavasti tunnistavat bannerin säilön, hyväksymispainikkeen ja hylkäyspainikkeen. Nämä ovat selektoreita, jotka olemme validoineet useiden kunkin CMP:n versioiden ja konfiguraatioiden yli. Kun CMP tunnistetaan kerroksessa 1 ja sen varmistetut selektorit vastaavat DOM:n elementtejä, meillä on korkea luottamus sekä CMP:n tunnistamiseen että bannerin interaktiokohteisiin.

Kerros 3: Yhteensopiva selektorivastaavuus

Laajempi joukko selektoreita, jotka toimivat monissa CMP:n versioissa mutta ovat vähemmän tarkkoja. Nämä käsittelevät tapauksia, joissa CMP on mukautettu, teemoitettu tai käyttää versiota, jota varmistetut selektorimme eivät kata. Ne vaihtavat tarkkuutta kattavuuteen.

Kerros 4: Yleiset heuristiikat

34,7 %:lle bannereista, joita ei ole yhdistetty tunnettuun CMP:hen, turvaudumme heuristiseen tunnistukseen. Skanneri etsii:

• Kiinteästi tai tarttuvasti sijoitettuja elementtejä näkymän ala- tai yläosassa
• Elementtejä, jotka sisältävät suostumukseen liittyviä avainsanoja useilla kielillä ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" jne.)
• Painikkeita, joissa on yleisiä suostumustoimintatekstejä ("Accept All", "Reject All", "Manage Preferences" ja vastaavat)
• Suostumusdialogeille tyypillisiä rakenteellisia malleja: peittotaustat, modaalikontainerit, sulkemispainikkeet

Tämä kerros nappaa monia mukautettuja toteutuksia mutta on luonteeltaan vähemmän luotettava. Kiinteästi sijoitettu mainosbanneri tai uutiskirjeen tilauslomake voi näyttää rakenteellisesti samanlaiselta kuin suostumusdialogi.

Kerros 5: CMP-rajapinnan kokeilu

Jotkut CMP:t paljastavat JavaScript-rajapintoja -- erityisesti IAB Transparency and Consent Framework (TCF) -rajapinnan `__tcfapi`:n kautta. Koettelemme näitä rajapintoja sekä CMP-tunnistuksen vahvistamiseksi että ohjelmallisen suostumustilan lukemiseksi, jota myöhemmin vertaamme havaittuun selaimen käyttäytymiseen.

Luottamusmalli

Sen sijaan, että käsittelisimme tunnistuksen binäärisenä (löytyi/ei löytynyt), annamme luottamuspisteet sen perusteella, mitkä kerrokset vastasivat ja kuinka vahvasti. Sivusto, jolla havaitsemme CMP-skriptin, löydämme varmistetut selektorivastaavuudet ja TCF-rajapinnan, saa korkean luottamuksen. Sivusto, jolla vain yleiset heuristiikat laukesivat, saa alemman luottamuksen. Tämä luottamuspistemäärä syötetään riskiluokitteluumme -- alempi tunnistusluottamus tarkoittaa, että havainnot luokitellaan todennäköisemmin ratkaisemattomiksi kuin lopullisiksi.

Luottamusmalli on syy siihen, miksi CMP:n virhetunnistus, vaikka sitä esiintyy, ei systemaattisesti vääristä tuloksiamme. Kun tunnistus on epäselvä, sanomme niin, emmekä pakota luokittelua.

Haaste 2: Hylkäysprosessi -- miksi "klikkaa ja tarkista" on yllättävän vaikeaa

Hylkäyspainikkeen testaaminen kuulostaa yksinkertaiselta: etsi se, klikkaa sitä, tarkista onko evästeet poissa. Käytännössä jokainen vaihe on täynnä ajoitusongelmia, asynkronista käyttäytymistä ja alustakohtaisia erityispiirteitä.

Hylkäyspainikkeen löytäminen. Kaikki hylkäyspainikkeet eivät ole merkitty "Hylkää". Ne voivat sanoa "Kieltäydy kaikista", "Kiellä", "Vain välttämättömät evästeet", "Hallinnoi asetuksia" (johtaen toiseen kerrokseen, jossa hylkäys on mahdollista) tai vastaavia kymmenillä kielillä. Jotkut CMP:t sijoittavat hylkäysvaihtoehdon eri visuaaliseen sijaintiin, eri kokoon tai eri väriin kuin hyväksymisvaihtoehdon. Jotkut piilottavat sen "Lisää vaihtoehtoja" tai "Mukauta" -linkin taakse. Skannerimme ylläpitää monikielistä joukkoa hylkäystoimintamalleja ja tunnistaa myös toisen kerroksen hylkäysvaihtoehdot, joissa ensimmäinen kerros tarjoaa vain hyväksy ja mukauta. Oikean hetken odottaminen. Hylkäyksen klikkaamisen jälkeen sivu voi kokea merkittäviä muutoksia: banneri poistuu (usein animaatiolla), CMP laukaisee suostumustilan takaisinkutsuja, tag managerit uudelleenarvioivat sääntönsä ja skriptejä saatetaan ladata tai poistaa. Evästeiden tarkistaminen liian aikaisin nappaa keskeneräisen siirtymätilan. Tarkistaminen liian myöhään ohittaa ohimenevän seurannan, joka laukeaa ja valmistuu nopeasti. Käytämme monisignaalista odotusta: verkko hiljaisena, DOM vakaa ja vähimmäisviivekynnys, joka on viritetty empiirisen testauksen perusteella satojen CMP-konfiguraatioiden yli. Uudelleenlataustesti ja consent respawn. Uudelleenlataustesti oli se, joka paljasti consent respawnin ilmiönä. Emme lähteneet etsimään sitä -- alkuperäinen hylkäysprosessitestimme tarkisti vain välittömän tilan hylkäyksen jälkeen. Mutta kehityksen aikana huomasimme sivustoja, jotka näyttivät puhtailta hylkäyksen jälkeen mutta joilla oli seurantaevästeitä, kun tarkistimme uudelleen sivun uudelleenlatauksen jälkeen. Alustava virheenetsintä oletti skannerin ajoitusongelmaa. Tarkempi tutkimus vahvisti sen olevan todellista: kolmannen osapuolen skriptit asettavat evästeitä sivun latautuessa suostumustilasta riippumatta.

Lisäsimme nimenomaisen respawn-tunnistuksen pipelineen: hylkäysprosessin jälkeen skanneri lataa sivun uudelleen, odottaa vakautta ja vertaa evästeinventaariota hylkäyksen jälkeiseen tilannekuvaan. Mikä tahansa eväste, joka poistettiin hylkäyksessä ja ilmestyy uudelleen uudelleenlatauksen jälkeen, merkitään respawniksi. Tämä havaitsi 1 642 sivustoa, joilla 4 932 evästettä palautui -- havainto, joka olisi ollut näkymätön ilman uudelleenlatausvaihetta.

`waitForScriptIdentifiedCMP`-kysely. Jotkut CMP:t latautuvat asynkronisesti eivätkä renderöi banneriaan ennen kuin useita sekunteja alkuperäisen sivulatauksen jälkeen. Jos skanneri etenee hylkäysvaiheeseen ennen CMP:n alustamista, se joko ohittaa bannerin kokonaan tai on vuorovaikutuksessa osittain ladatun käyttöliittymän kanssa. Toteutimme kyselymekanismin, joka odottaa CMP:n JavaScript-rajapinnan saataville tuloa (esim. `__tcfapi` TCF-pohjaisille CMP:ille, `Cookiebot`-globaali Cookiebotille) ennen etenemistä. Tämä lisää viivettä skannausta kohden mutta vähentää merkittävästi vääriä negatiivisia asynkronisesta CMP-lataamisesta.

Haaste 3: Pipelinen kyllästyminen mittakaavassa

97 304 verkkosivuston skannaaminen ei ole yhden koneen työ. Jokainen skannaus käynnistää Chromium-prosessin, navigoi verkkosivustolle, sieppaa ja luokittelee satoja verkkopyyntöjä, ottaa useita kuvakaappauksia ja ajaa analyysimo-duuleja. Yksittäinen skannaus kestää 30-90 sekuntia sivuston monimutkaisuudesta riippuen. 15 samanaikaisen skannauksen työntekijäkohtaisella tasolla resurssien hallinnasta tulee ensisijainen tekninen huolenaihe.

Semafori-arkkitehtuuri

Käytämme semaforipohjaista rinnakkaisuusmallia rajoittamaan samanaikaisten Chromium-prosessien määrää per työntekijä. Jokaisella työntekijällä on kiinteä semafori (15 paikkaa tuotantokonfiguraatiossamme). Skannaus varaa paikan ennen selaimen käynnistämistä ja vapauttaa sen valmistuttuaan. Tämä estää muistin loppumisen -- 15 Chromium-instanssia täydellä pyyntöjen sieppauksella kuluttaa jo merkittävästi RAM-muistia -- ja tarjoaa vastapaineen Redis-jonoa vasten.

Dokumenttipyynnön poikkeus

Kehityksen alkuvaiheessa törmäsimme läpäisyongelmaan: pyyntöjen sieppauslogiikkamme (joka tarkastaa jokaisen pyynnön SSRF-turvallisuuden -- estää pyynnöt yksityisiin IP-alueisiin, sisäisiin verkkoihin ja muihin mahdollisesti vaarallisiin kohteisiin) lisäsi viivettä jokaiseen resurssien lataukseen, mukaan lukien pääasiakirjapyyntöön. Koska asiakirjan URL on jo validoitu ennen skannauksen alkua, lisäsimme nopean ohitusreitin: asiakirjatyyppiset pyynnöt esivalidoituun kohde-URL:iin ohittavat täyden sieppauspipelinen. Tämä näennäisesti pieni optimointi vaikutti merkittävästi kokonaisläpäisyyn, koska asiakirjapyyntö estää kaiken muun.

DNS-eslämmitys

Ensimmäinen pyyntö uudelle domainille aiheuttaa DNS-haun, joka infrastruktuurissamme saattaa lisätä 50-200 ms per domain. Keskimääräisen sivuston ottaessa yhteyttä 10,4 kolmannen osapuolen domainiin (ja joidenkin jopa 171:een), DNS-resoluutioaika kasautui merkittävästi. Toteutimme DNS-esilämmityksen paikallisen Unbound DNS -resolverivälimuistin avulla: ennen jokaista skannausta resolvoimme kohdedomain ja lämmitämme välimuistin. Unbound-instanssi palvelee välimuistista vastauksia myöhemmille hauille skannauksen sisällä, vähentäen domain-kohtaisen DNS-ylikuorman alle millisekuntiin.

SSRF-turvallisuus mittakaavassa

Jokainen skannerin sieppaama pyyntö tarkistetaan turvallisuussääntöjoukkoa vasten ennen kuin sen annetaan edetä. Pyynnöt yksityisiin IP-alueisiin (RFC 1918, RFC 4193, link-local, loopback) estetään. Tämä estää haitallista kohdesivustoa käyttämästä skanneria SSRF-vektorina sisäisten verkkojen luotaamiseen.

Haaste mittakaavassa oli todellisten SSRF-estojen erottaminen semafori-kyllästymisestä. Kun kaikki 15 semaforipaikkaa ovat käytössä eikä skannaus voi varata paikkaa, tuloksena oleva aikakatkaisu näyttää pinnallisesti samanlaiselta kuin turvallisuussyistä estetty pyyntö. Lisäsimme nimenomaisen virheluokittelun erottamaan "estetty koska kohde resolvoitui yksityiseen IP:hen" ja "estetty koska skanneri on kapasiteetissa." Tämä oli olennaista operatiiviselle seurannalle ja tarkkalle skannausvirheiden luokittelulle.

Haaste 4: Bottien väistelynnunnistus

Tutkimuksen aikana tunnistimme 137 verkkosivustoa, jotka näyttävät tarkoituksellisesti piilottavan suostumuksenbannerinsa automaattisilta skannereilta. Banneri tarjoillaan ihmiskävijöille mutta piilotetaan, kun sivusto havaitsee automatisoidun selaamisen tunnusmerkit.

Yleisin tunnistamamme mekanismi liittyy RCB (Real Cookie Banner) WordPress-lisäosan `isAcceptAllForBots`-konfiguraatiovalintaan. Käytössä ollessaan tämä asetus tunnistaa automatisoidut selaimet (`navigator.webdriver`-ominaisuuden, user-agent-heuristiikkojen tai käyttäytymissignaalien kautta) ja joko automaattisesti hyväksyy suostumuksen niiden puolesta tai piilottaa bannerin kokonaan. Tarkoitus, kuten lisäosan dokumentaatiossa kerrotaan, on estää automatisoitujen vierailijoiden saamasta suostumusdialogia, jonka kanssa ne eivät voi mielekkäästi olla vuorovaikutuksessa. Vaikutus on, että vaatimustenmukaisuusskannerit -- ja automaattisia työkaluja käyttävät sääntelyauditoijat -- näkevät sivuston, jolla ei vaikuta olevan suostumusmekanismia, kun ihmiskävijät näkevät täyden suostumusbannerin.

Tämä on läpinäkyvyysongelma. Jos verkkosivuston suostumusmekanismi näkyy vain ihmiskävijöille, sitä ei voi auditoida laajamittaisesti. Merkitsemme nämä sivustot erikseen tuloksissamme, koska havainto on laadullisesti erilainen kuin "banneria ei havaittu." Sivustolla on banneri; se valitsee olla näyttämättä sitä meille.

Tunnistamme bottien väistelyn signaalien yhdistelmällä: tunnettujen bottientunnistuskonfiguraatioiden läsnäolo CMP-asetuksissa (saatavilla JavaScript-tarkastelun kautta), ristiriidat DOM:n näyttämän ja CMP:n rajapinnan raportoiman välillä, sekä joissakin tapauksissa vertaamalla automatisoituja skannaustuloksia manuaaliseen todentamiseen.

137:n luku on varmasti aliarvio. Voimme tunnistaa bottien väistelyn vain kun voimme tunnistaa mekanismin. Sivustot, jotka käyttävät kehittyneempää tai mukautettua bottientunnistusta, saattavat onnistuneesti väistää sekä skannerimme että väistelyn tunnistuksemme.

Haaste 5: CMP:n virhetunnistus

Sivusto voi ladata useita skriptejä, jotka näyttävät suostumuksenhallintatyökaluilta. PiwikPRO sisältää CMP-komponentin mutta on ensisijaisesti analytiikkaohjelmisto. Jotkut WordPress-sivustot lataavat Complianzin erillisen analytiikkalisäosan rinnalla, jolla on CMP:n kaltaisia ominaisuuksia. Yrityssivustoilla voi olla edellisen CMP:n jäänteitä yhä latautumassa nykyisen rinnalla.

Naiivi tunnistus -- "jos näemme skriptin, se on CMP" -- tuottaa virhetunnistuksia, jotka kertautuvat väärään banneri-interaktioon. Jos skanneri tunnistaa PiwikPROn CMP:ksi ja yrittää käyttää PiwikPROn bannerselektoreita, se voi ohittaa todellisen tarteaucitron-bannerin, joka hallitsee suostumusta sivustolla.

Luottamuspohjainen lähestymistapamme käsittelee tämän CMP-ehdokkaiden luokittelulla. Kun useita mahdollisia CMP:itä havaitaan:

1. Tarkistamme, kummalla on näkyvä banneri DOM:ssa (skripti läsnä mutta ei banneria tarkoittaa todennäköisesti inaktiivista tai ei-CMP-käyttöä).

2. Tarkistamme, kumpi paljastaa aktiivisen CMP-rajapinnan (esim. toimiva `__tcfapi` tai vastaava).

3. Suosimme CMP:tä, jonka varmistetut selektorit vastaavat näkyviä DOM-elementtejä, yli sen, joka tunnistetaan vain skripti-URL:n perusteella.

Tämä heuristiikka ei ole täydellinen, mutta se ratkaisi yleisimmät virhetunnistustapaukset, joita kohtasimme kehityksen ja testauksen aikana.

Rajoitukset

Mikään automaattinen skanneri ei toista täydellisesti jokaista ihmisen selauskokemusta. Nämä ovat tunnetut rajoitukset:

GeoIP-riippuvaiset bannerit. Jotkut CMP:t, erityisesti CookieYes, tarjoilevat erilaisia suostumuskokemuksia vierailijan IP-paikannuksen perusteella. Skannauksemme ovat peräisin tietyistä Euroopan verkkosijainnista. Sivusto, joka näyttää suostumusbannerin ranskalaisille kävijöille mutta ei EU:n ulkopuolisille, näyttää erilaisia tuloksia skannauksen alkuperästä riippuen. Emme tällä hetkellä skannaa jokaista sivustoa jokaisesta EU-maasta. Suljettu shadow DOM. Jotkut CMP:t renderöivät bannerinsa suljetun shadow DOM:n sisällä, johon ei pääse käsiksi standardeilla DOM-kyselyillä `document.querySelector`-funktion kautta. Transcendin CMP käyttää tätä lähestymistapaa. Skannerimme voi havaita shadow host -elementin mutta ei voi tarkastella sen sisältöä löytääkseen hyväksy/hylkää-painikkeita. Nämä sivustot päätyvät tyypillisesti ratkaisemattomiksi tuloksissamme. Dynaamiset luokkanimet ja obfuskaatio. Jotkut CMP:t, erityisesti Admiral, käyttävät dynaamisesti generoituja luokkanimiä, jotka vaihtuvat jokaisella sivulatauksella. Selektoripohjainen tunnistus epäonnistuu näissä, koska selektorit eivät ole vakaita vierailujen välillä. Turvaudumme yleisiin heuristiikkoihin, mutta luottamus on alhaisempi. Yksisivuiset sovellukset. SPA-sovellukset, jotka hallitsevat suostumustilaa kokonaan asiakaspuolen JavaScriptissä ja lataavat suostumusmekanismin alkuperäisten reittivaihdosten jälkeen (eivät alkuperäisellä sivulatauksella), ovat vaikeampia arvioida. Skannerimme navigoi URL:iin ja odottaa sivun vakautumista, mutta se ei simuloi sovelluksen sisäistä navigointia. Suostumusbanneri, joka ilmestyy vasta käyttäjän navigoidessa SPA:n sisällä, saatetaan ohittaa. Kielikattavuus. Hylkäyspainikkeen tunnistuksemme käyttää tekstivastaavuutta tuettujen kielten joukon yli, mutta emme kata jokaista EU-kieltä tasapuolisesti. Maltankielisellä tai vironkielisellä bannerilla voi olla hylkäyspainikkeentekstejä, joita tekstivastaavuutemme ei tunnista, mikä johtaa hylkäysprosessin testauksen ohittamiseen (vaikka banneri itsessään saatetaan silti tunnistaa rakenteellisilla heuristiikoilla). Ajoituksen reunatapaukset. Skripti, joka laukeaa 30 sekuntia sivulatauksen jälkeen, ohitetaan skannauksessa, joka odottaa 15 sekuntia verkon hiljaisuutta. Käytämme runsaita aikakatkaisuja, mutta asynkronisen käyttäytymisen pitkä häntä on luontaisesti vaikea kaapata kokonaan.

Nämä rajoitukset myötävaikuttavat 14,9 %:n ratkaisemattomien osuuteemme.

Infrastruktuuri

Tuotantoskannausinfrastruktuuri koostuu seuraavista:

• Skannausmoottori: Go-sovellus, joka käyttää chromedp:tä CDP-asiakkaana Chromiumin automatisointiin. Go valittiin sen rinnakkaisuusmallin (goroutiinit ja kanavat vastaavat luonnollisesti rinnakkaisen skannauksen orkestrointia), suorituskyvyn ja käyttöönoton yksinkertaisuuden (yksittäinen staattinen binääri) vuoksi.
• Selainajoympäristö: Headless Chromium, joka käynnistetään skannauskohtaisesti CDP:n kautta. Jokainen skannaus saa tuoreen selainprosessin ilman jaettua tilaa.
• Jono: Redis-pohjainen työjono, joka jakaa URL:eja skannaustyöntekijöille. Redis hoitaa töiden jakelun, edistymisen seurannan ja nopeusrajoituksen.
• Tietokanta: PostgreSQL kestäville skannaustuloksille, havainnoille, todistusmetadatalle ja kaikelle jäsennellylle datalle. Skannaukset, havainnot, evästeet, pyynnöt ja analyysitulokset tallennetaan kaikki relaatiomuodossa.
• DNS-välimuisti: Paikallinen Unbound-resolveri, joka tarjoaa välimuistitetut DNS-haut ja SSRF-turvallisen resoluution.
• Todisteiden tallennus: Kuvakaappaukset, HAR-tiedostot ja PDF-raportit tallennetaan kestävinä artefakteina, jotka on linkitetty skannaustietueisiin.

97 304 sivuston tutkimuksessa käsittelimme 114 748 ehdokasURL:ia (97 304 valmistui onnistuneesti) noin 2,5 päivässä käyttäen 3 palvelininstanssia, joissa skannaustyöntekijät ajoivat rinnakkain. Jokaisella palvelimella oli useita työntekijäprosesseja, joissa kussakin oli 15 samanaikaista skannauspaikkaa. Huippuläpäisy oli noin 25-30 valmistunutta skannausta minuutissa palvelinta kohden.

Ensisijainen pullonkaula ei ollut prosessori tai muisti vaan verkko: jokainen skannaus tuottaa satoja lähteviä pyyntöjä (kohdesivustolle ja sen kolmannen osapuolen resursseille), ja kaikkien samanaikaisten skannausten yhteenlaskettu kaistanleveys ja yhteysmäärä kyllästivät käytettävissä olevan verkkokapasiteetin ennen kuin muut resurssit olivat loppuneet.

Avoimet haasteet ja tuleva työ

Useita ongelmia on edelleen ratkaisematta tai osittain ratkaistuja:

Suostumusbannerin lokalisointi. Tekstivastaavuutemme kattaa suuret EU-kielet mutta on puutteellinen pienempien kieliyhteisöjen osalta. Kattavuuden laajentaminen edellyttää käännösten lisäämisen lisäksi selektorien ja interaktiomallien toimivuuden vahvistamista lokalisoitujen CMP-versioiden kanssa. Pitkittäisseuranta. Nykyinen arkkitehtuurimme on optimoitu pisteittäiseen skannaukseen. Suostumuskäyttäytymisen muutosten tunnistaminen ajan myötä -- paraniko sivusto täytäntöönpanon jälkeen? Korjasiko CMP-päivitys luokan hylkäysprosessivirheitä? -- edellyttää toistuvia skannauksia vertailuanalyysillä, mikä on arkkitehturisesti erilaista kuin kertakäyttöinen arviointi. CMP-vaatimustenmukaisuuden vertailuanalyysi. Meillä on data CMP-kohtaisten vaatimustenmukaisuusasteiden arvioimiseen (onko Cookiebot yhdistetty parempaan vaatimustenmukaisuuteen kuin OneTrust?), mutta CMP:n laadun erottaminen sivuston ylläpitäjän konfiguraation laadusta on metodologisesti monimutkaista. CMP, jota useammin ottavat käyttöön suuret yritykset omistetuilla tietosuojatiimeillä, näyttää kokonaisuudessa paremmalta, vaikka itse työkalu ei olisi vaatimustenmukaisempi. Reaaliaikainen suostumustilan todentaminen. Nykyinen skanneri toimii eräajotilassa. Suostumuksen todentamisen integrointi CI/CD-putkiin tai reaaliaikaiseen seurantaan edellyttää nopeampaa, kevyempää skannaustilaa, joka uhraa osan todisteiden syvyydestä nopeuden hyväksi. Tutkimme tätä.

API

Sama skannausmoottori, joka kuvataan tässä kirjoituksessa, on saatavilla GDPR Monitorin julkisen API:n kautta. Voit lähettää skannauspyyntöjä ohjelmallisesti, kysellä tuloksia ja hakea jäsenneltyjä havaintoja ja todisteartefakteja. API palauttaa saman datan, jonka käyttöliittymämme näyttää: tilannekuvat ennen suostumusta, evästeluettelot, CMP-tunnistustulokset, hylkäysprosessin tulokset, riskipisteet ja täydelliset todisteketjut.

Jos rakennat vaatimustenmukaisuustyökaluja, integrolt yksityisyystarkistuksia CI/CD-putkiin, teet omaa tutkimustasi tai rakennat seurantaa tietosuojaohjelmaan, API tarjoaa pääsyn käyttäytymispohjaiseen suostumusanalyysiin ilman tarvetta rakentaa ja ylläpitää omaa Chromium-automaatioinfrastruktuuria.

---

Kokeile itse. API-dokumentaatio on saatavilla osoitteessa gdprprivacymonitor.eu/developers/api. Lähetä yksittäinen URL tai integroi automaattinen yksityisyysseuranta työnkulkuusi.