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

Automatiseeritud nõusoleku vastavuse kontrollimine kõlab lihtsalt, kuni proovite seda ehitada. Naiivne lähenemine -- too lehekülg, kontrolli küpsiseid, otsi bännerit -- jätab enamiku olulisest märkamata. Nõusolekurikkumised on käitumuslikud, mitte struktuursed. Need avalduvad skriptide käivitamise ajastuses, võrgupäringute järjestuses, kasutajaliidese elementide reageerimises kasutaja suhtlusele ja oleku püsimises üle lehekülastuste. Ühtegi neist ei saa hinnata ilma päris brauseri käivitamata, lehega suhtlemata nagu inimene ja salvestamata, mis tegelikult võrgutasemel juhtub.

See postitus kirjeldab, kuidas me ehitasime GDPR Monitor'i taga oleva skaneerimismootori, inseneritehnilisi väljakutseid, mis tarbisid enamiku meie ajast, arhitektuurilisi otsuseid, mida tegime ja miks, ning piiranguid, mille suhtes oleme ausad. Kui te töötate veebinõuetele vastavuse, brauseri automatiseerimise või suure ulatusega veebimõõtmise alal, peaks siin midagi kasulikku olema.

Pipeline ülevaade

Iga skaneerimine läbib kuus etappi. Pipeline mõistmine on vajalik kontekst spetsiifiliste väljakutsete jaoks, mis järgnevad.

Etapp 1: brauseri käivitamine ja isoleerimine. Puhas Chromium eksemplar käivitub nulli olekuga -- ilma küpsiste, localStorage, vahemälu ega teenustetöötajateta. See on puhtaruumi garantii, mis muudab nõusolekueelse mõõtmise tähenduslikuks. Konfigureerima standardse vaatevälja, realistlikud User-Agent ja Accept-Language päised, mis vastavad sihtriigile, ning standardsed brauseri lipud. Iga skaneerimine saab oma brauseriprotsessi; skaneerimiste vahel pole oleku leket. Etapp 2: navigeerimine ja nõusolekueelne hetktõmmis. Skanner navigeerib siht-URL-ile, ootab lehe stabiilse oleku saavutamist (võrgu jõudeolekut, DOM-i stabiliseerumist) ja salvestab kõik toimunu: seatud küpsised, tehtud võrgupäringud (täieliku URL-i, ajastuse ja vastuse metaandmetega), kontakteeritud kolmandate osapoolte domeenid ja täisleheküljelise ekraanipildi. See hetktõmmis vastab põhiküsimusele: mida see veebisait tegi enne, kui kasutajal oli võimalus nõusolekut anda? Etapp 3: CMP tuvastamine ja bänneri identifitseerimine. Skanner üritab tuvastada nõusolekuhaldusplatvormi ja leida nõusolekubänneri, nõustumise nupu ja keeldumise nupu. See kasutab allpool üksikasjalikumalt kirjeldatud kihilist tuvastussüsteemi. Etapp 4: nõusoleku suhtlus. Skanner suhtleb bänneriga -- klõpsates nõustu standardvoo jaoks, klõpsates keeldu keeldumise voo testi jaoks. See ootab lehe stabiliseerumist pärast suhtlust, arvestades animatsioone, skriptide ümberhindamist ja viivitatud sildikäivitamist. Etapp 5: nõusolekujärgne hetktõmmis ja diferentsiaalne analüüs. Teine täielik hetktõmmis salvestab oleku pärast nõusoleku suhtlust. Nõusolekueelse ja nõusolekujärgse hetktõmmise võrdlus paljastab, mis muutus: uued küpsised, uued jälgimispäringud, nõusoleku olek CMP API-des. Etapp 6: analüüs, klassifitseerimine ja aruande genereerimine. Toorandmed suunatakse analüüsimoodulitesse: küpsiste klassifitseerimine meie andmebaasi vastu, jälgijate sobitamine teadaolevate mustrite vastu, küpsise eluea hindamine, bänneri ligipääsetavuse audit, Google Consent Mode valideerimine, sõrmejäljesignaali tuvastamine ja riskiskoor. Väljundiks on struktureeritud aruanne leidude, tõendusmaterjali artefaktide ja komposiitse riskiskooriga.

Iga etapp tekitab ajatempliga tõendusmaterjali, mis salvestatakse püsivalt. Igat leidu saab jälitada tagasi konkreetsete võrgupäringuteni, küpsistekirjeteni või ekraanipiltideni.

Väljakutse 1: CMP tuvastamine -- 45 platvormi, lõputud variatsioonid

Nõusoleku haldamine ei ole standardiseeritud. Pole universaalset HTML-atribuuti, kohustuslikku JavaScript API-t ega järjekindlat DOM-struktuuri, mis ütleks "see on nõusolekubänner." Meie tuvastamisteegis on 45 erinevat CMP-d, igaühel oma DOM-struktuur, skriptisignatuurid, JavaScripti globaalmuutujad ja suhtlusmustrid. Lisaks neile oli 34,7% meie 97 304 saidi uuringus tuvastatud bänneritest üldised või tuvastamata -- kohandatud rakendused, piirkondlikud pakkujad või minimaalsed lahendused, mis ei vastanud ühelegi teadaolevale CMP signatuurile.

Meie tuvastamine kasutab usalduspõhist, kihilist lähenemist:

Kiht 1: skriptisignatuuri tuvastamine

Skanner kontrollib teadaolevate CMP skriptide olemasolu URL-i mustri ja JavaScripti globaalmuutujate järgi. Cookiebot laeb näiteks aadressilt `consent.cookiebot.com` ja avaldab `window.Cookiebot`. OneTrust laeb aadressilt `cdn.cookielaw.org` ja avaldab `window.OneTrust`. Igal CMP-l on iseloomulikud laadimismustrid, mida saab tuvastada enne DOM-i uurimist.

See kiht on kiire ja kõrge usaldusväärsusega, kui see sobib. Kuid sellel on kriitiline piirang: see ütleb teile, milline CMP on lehel olemas, mitte tingimata milline CMP vastutab nõusolekubänneri eest. Sait võib laadida PiwikPRO analüütika jaoks (mis sisaldab CMP komponenti), kasutades samal ajal tarteaucitron'i tegeliku nõusoleku haldamiseks. Mõlema skripti tuvastamine on lihtne; teadmine, kumb kontrollib bännerit, on raskem.

Kiht 2: kontrollitud selektorite sobitamine

Iga teadaoleva CMP jaoks haldame kureeritud CSS-selektorite komplekti, mis tuvastavad usaldusväärselt bänneri konteineri, nõustumise nupu ja keeldumise nupu. Need on selektorid, mida oleme valideerinud iga CMP mitme versiooni ja konfiguratsiooni lõikes. Kui CMP tuvastatakse kihis 1 ja selle kontrollitud selektorid vastavad DOM-i elementidele, on meil kõrge usaldusväärsus nii CMP tuvastamise kui ka bänneri suhtluse sihtmärkide osas.

Kiht 3: ühilduvate selektorite sobitamine

Laiem selektorite komplekt, mis töötab CMP paljude versioonide lõikes, kuid on vähem täpne. Need käsitlevad juhtumeid, kus CMP on kohandatud, temaatiliselt kujundatud või käitab versiooni, mida meie kontrollitud selektorid ei kata. Need vahetavad täpsust katvuse vastu.

Kiht 4: üldised heuristikad

34,7% bännerite jaoks, mis ei ole seotud teadaoleva CMP-ga, langeme tagasi heuristilisele tuvastamisele. Skanner otsib:

• Fikseeritud positsiooni või kleepuva positsiooni elemente vaatevälja alumises või ülemises osas
• Elemente, mis sisaldavad nõusolekuga seotud võtmesõnu mitmes keeles ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" jne)
• Nuppe levinud nõusolekutoimingu siltidega ("Accept All", "Reject All", "Manage Preferences" ja samaväärsed)
• Nõusolekudialoogidele tüüpilisi struktuurseid mustreid: ülekattega taustad, modaalkonteinerid, sulgemise nupud

See kiht tabab paljusid kohandatud rakendusi, kuid on olemuslikult vähem usaldusväärne. Fikseeritud positsiooniga reklaamibänner või uudiskirja registreerimisaken võib näida struktuurselt sarnane nõusolekudialoogiga.

Kiht 5: CMP API sondeeritmine

Mõned CMP-d avaldavad JavaScripti API-sid -- eelkõige IAB Transparency and Consent Framework (TCF) API `__tcfapi` kaudu. Me sondeerime neid API-sid nii CMP tuvastamise kinnitamiseks kui ka programmilise nõusolekuoleku lugemiseks, mida hiljem võrdleme täheldatud brauserikäitumisega.

Usaldusmudel

Selle asemel, et tuvastamist kohelda binaarsena (leitud/ei leitud), anname usaldusskoore selle põhjal, millised kihid sobisid ja kui tugevalt. Sait, kus tuvastame CMP skripti, sobitame kontrollitud selektorid ja leiame TCF API, saab kõrge usalduse. Sait, kus käivitusid ainult üldised heuristikad, saab madalama usalduse. See usaldusskoor toidab meie riskiklassifikatsiooni -- madalam tuvastamise usaldusväärsus tähendab, et leiud klassifitseeritakse tõenäolisemalt ebaselgetena kui lõplikena.

Usaldusmudel on põhjus, miks CMP valetuvastamine, kuigi see esineb, ei kalluta süstemaatiliselt meie tulemusi. Kui tuvastamine on ebaselge, ütleme seda, selle asemel et klassifikatsiooni sundida.

Väljakutse 2: keeldumise voog -- miks "klõpsa ja kontrolli" on üllatavalt raske

Keeldumise nupu testimine kõlab lihtsalt: leia see, klõpsa sellele, kontrolli, kas küpsised on kadunud. Praktikas on iga samm täis ajastusprobleeme, asünkroonset käitumist ja platvormispetsiifilisi iseärasusi.

Keeldumise nupu leidmine. Mitte kõik keeldumise nupud pole märgistatud "Reject." Need võivad öelda "Decline All", "Refuse", "Only necessary cookies", "Manage settings" (viies teisele kihile, kus keeldumine on võimalik) või samaväärseid kümnetes keeltes. Mõned CMP-d paigutavad keeldumise valiku teise visuaalsesse asukohta, erineva suurusega või erinevas värvis nõustumise valikust. Mõned peidavad selle "More options" või "Customize" lingi taha. Meie skanner haldab mitmekeelset keeldumistoimingu mustrite komplekti ja tuvastab ka teise kihi keeldumise valikuid, kus esimene kiht pakub ainult nõustumist ja kohandamist. Õige hetke ootamine. Pärast keeldumisele klõpsamist võib leht läbida märkimisväärseid muutusi: bänner sulgetakse (sageli animatsiooniga), CMP käivitab nõusolekuoleku tagasikutsed, sildihaldureid hindavad oma reeglid ümber ning skripte võidakse laadida või eemaldada. Küpsiste liiga varajane kontrollimine tabab üleminekuoleku. Liiga hiline kontrollimine jätab märkamata ajutise jälgimise, mis käivitub ja lõpeb kiiresti. Kasutame mitmesignaalilist ootamist: võrgu jõudeolekut, DOM-i stabiilsust ja minimaalset viivituspõrandat, mis on häälestatud empiiriliselt testides sadade CMP konfiguratsioonide lõikes. Uuesti laadimise test ja consent respawn. Uuesti laadimise samm paljastas consent respawn fenomeni. Me ei asunud seda otsima -- meie algne keeldumise voo test kontrollis ainult vahetut keeldumisjärgset olekut. Kuid arenduse käigus märkasime saite, mis näisid keeldumise järel puhtad, kuid millel olid jälgimisküpsised, kui kontrollisime uuesti pärast lehe uuesti laadimist. Esialgne silumine eeldas skanneri ajastusviga. Edasine uurimine kinnitas, et see oli reaalne: kolmandate osapoolte skriptid taasseadsid küpsiseid lehekülastusel olenemata nõusolekuolekust.

Lisasime pipeline'ile sõnaselge taasilmumise tuvastamise: pärast keeldumise voogu laeb skanner lehe uuesti, ootab stabiliseerumist ja võrdleb küpsiste inventuuri keeldumisjärgse hetktõmmisega. Iga küpsis, mis eemaldati keeldumisega ja ilmub uuesti pärast uuesti laadimist, märgistatakse taasilmujana. See tabas 1 642 saiti 4 932 taasilmuva küpsisega -- leid, mis oleks olnud ilma uuesti laadimise sammuta nähtamatu.

`waitForScriptIdentifiedCMP` pollitsemine. Mõned CMP-d laevad asünkroonselt ega renderda oma bännerit enne mitut sekundit pärast esialgset lehe laadimist. Kui skanner jätkab keeldumise sammuga enne CMP initsialiseerimist, jätab see bänneri kas täielikult märkamata või suhtleb osaliselt laetud kasutajaliidesesga. Rakendasime pollitsemismehhanismi, mis ootab CMP JavaScripti API kättesaadavaks muutumist (nt `__tcfapi` TCF-põhiste CMP-de jaoks, `Cookiebot` globaalmuutuja Cookieboti jaoks) enne jätkamist. See lisab latentsust skaneerimise kohta, kuid vähendab oluliselt valepositiivseid asünkroonsest CMP laadimisest.

Väljakutse 3: pipeline küllastumine suures ulatuses

97 304 veebisaidi skaneerimine ei ole ühe masina töö. Iga skaneerimine käivitab Chromium protsessi, navigeerib veebisaidile, püüab kinni ja klassifitseerib sadu võrgupäringuid, teeb mitu ekraanipilti ja käivitab analüüsimoodulid. Üksik skaneerimine võtab 30-90 sekundit olenevalt saidi keerukusest. 15 samaaegse skaneerimisega töötaja kohta muutub ressursihaldus peamiseks inseneritehniliseks mureks.

Semafoori arhitektuur

Kasutame semafoori-põhist samaaegsuse mudelit samaaegsete Chromium protsesside arvu piiramiseks töötaja kohta. Igal töötajal on fikseeritud semafor (15 pesa meie tootmiskonfiguratsioonis). Skaneerimine omandab pesa enne brauseri käivitamist ja vabastab selle lõpetamisel. See takistab mälu ammendumist -- 15 Chromium eksemplari täieliku päringute püüdmisega tarbivad juba märkimisväärset RAM-i -- ja tagab vasturõhu Redis järjekorra vastu.

Dokumendipäringu erand

Arenduse varajases faasis puutusime kokku läbilaskvusprobleemiga: meie päringute püüdmise loogika (mis kontrollib iga päringut SSRF ohutuse tagamiseks -- blokeerides päringud privaat-IP vahemikele, sisevõrkudele ja muudele potentsiaalselt ohtlikele sihtmärkidele) lisas latentsust igale ressursi laadimisele, kaasa arvatud põhidokumendi päringule. Kuna dokumendi URL on juba enne skaneerimise algust valideeritud, lisasime kiirtee ümbersõidu: dokumenditüüpi päringud eelvalideeritud siht-URL-ile jätavad täieliku püüdmise pipeline vahele. See näiliselt väike optimeerimine avaldas olulist mõju üldisele läbilaskvusele, sest dokumendi päring blokeerib kõike muud.

DNS-i eelsoojendamine

Esimene päring uuele domeenile toob kaasa DNS-otsingu, mis meie infrastruktuuris võis lisada 50-200 ms domeeni kohta. Keskmise saidi kontakteerumisel 10,4 kolmanda osapoole domeeniga (ja mõnel kuni 171-ga) akumuleerus DNS-lahenduse aeg oluliselt. Rakendasime DNS-i eelsoojendamise kohaliku Unbound DNS-vahemälu lahendaja abil: enne iga skaneerimist lahendame sihtdomeeni ja soojendame vahemälu. Unbound eksemplar teenindab vahemällu salvestatud vastuseid järgnevatele otsingutele skaneerimise jooksul, vähendades domeenipõhist DNS-koormat alla millisekundi.

SSRF ohutus suures ulatuses

Iga skanneri poolt peatatud päring kontrollitakse ohutusreeglite vastu enne edasilaset. Päringud privaat-IP vahemikele (RFC 1918, RFC 4193, link-local, loopback) blokeeritakse. See takistab pahatahtlikul sihtlehel kasutamast skannerit SSRF vektorina sisevõrkude uurimiseks.

Väljakutseks suures ulatuses oli eristada tõelisi SSRF blokeeringuid semafoori küllastumisest. Kui kõik 15 semafooripesa on kasutuses ja skaneerimine ei saa pesa omandada, näeb tulenev ajalõpp pealiskaudselt sarnane välja ohutuse põhjustel blokeeritud päringuga. Lisasime sõnaselge veakategoriseerimise, et eristada "blokeeritud, sest sihtmärk lahendus privaatsele IP-le" ja "blokeeritud, sest skanner on täisvõimsusel." See oli hädavajalik operatiivse jälgimise ja täpse skaneerimise ebaõnnestumise klassifikatsiooni jaoks.

Väljakutse 4: botituvastuse vältimine

Uuringu käigus tuvastasime 137 veebisaiti, mis näivad tahtlikult peitvat oma nõusolekubännerit automatiseeritud skannerite eest. Bänner teenindatakse inimkülastajatele, kuid surutakse alla, kui sait tuvastab automatiseeritud sirvimise tunnused.

Kõige levinum mehhanism, mille tuvastasime, hõlmab RCB (Real Cookie Banner) WordPress'i plugina `isAcceptAllForBots` konfiguratsioonivalikut. Kui see on lubatud, tuvastab see seade automatiseeritud brauserid (`navigator.webdriver`, User-Agent heuristikad või käitumuslikud signaalid) ja kas nõustub automaatselt nende nimel või peidab bänneri täielikult. Kavatsus, nagu plugina dokumentatsioon kirjeldab, on takistada automatiseeritud külastajatel saada nõusolekudialoogi, millega nad ei saa sisukalt suhelda. Mõju on see, et vastavusskannerid -- ja regulatoorsed audiitorid, kes kasutavad automatiseeritud tööriistu -- näevad saiti, millel näib puuduvat nõusolekumehhanism, kuigi inimkülastajad näevad täielikku nõusolekubännerit.

See on läbipaistvusprobleem. Kui veebisaidi nõusolekumehhanism on nähtav ainult inimkülastajatele, ei saa seda suures ulatuses auditeerida. Me märgistame need saidid oma tulemustes eraldi, sest leid on kvalitatiivselt erinev "bännerit ei tuvastatud" leiust. Saidil on bänner; ta valib selle meile mitte näidata.

Me tuvastame botituvastuse vältimist signaalide kombinatsiooni kaudu: teadaolevate botituvastuse konfiguratsioonide olemasolu CMP seadetes (juurdepääsetav JavaScripti inspektsiooni kaudu), lahknevused selle vahel, mida DOM näitab ja mida CMP API raporteerib, ning mõnel juhul automatiseeritud skaneerimistulemuste võrdlemisel käsitsi kontrollimisega.

137 arv on kindlasti alaloendu. Me saame tuvastada botituvastuse vältimist ainult siis, kui suudame tuvastada mehhanismi. Saidid, mis kasutavad keerukamaid või kohandatud botituvastusi, võivad edukalt vältida nii meie skannerit kui ka meie vältimise tuvastamist.

Väljakutse 5: CMP valetuvastamine

Sait võib laadida mitu skripti, mis näevad välja nagu nõusolekuhaldusplatvormid. PiwikPRO sisaldab CMP komponenti, kuid on peamiselt analüütikakomplekt. Mõned WordPress'i saidid laevad Complianz'i kõrvuti eraldi analüütikapluginas, millel on CMP-laadsed funktsioonid. Ettevõtte saidid võivad laadida eelmise CMP jäänuseid praeguse kõrvale.

Naiivne tuvastamine -- "kui me näeme skripti, on see CMP" -- toodab valetuvastusi, mis kanduvad edasi valesse bänneri suhtlusse. Kui skanner tuvastab PiwikPRO CMP-na ja üritab kasutada PiwikPRO bänneri selektoreid, võib ta jätta märkamata tegeliku tarteaucitron bänneri, mis kontrollib nõusolekut saidil.

Meie usalduspõhine lähenemine käsitleb seda CMP kandidaatide järjestamise kaudu. Kui tuvastatakse mitu potentsiaalset CMP-d:

1. Kontrollime, kummal on DOM-is nähtav bänner (skript on olemas, kuid bännerit pole, tähendab tõenäoliselt mitteaktiivset või mitte-CMP kasutust).

2. Kontrollime, kumb avaldab aktiivse CMP API (nt toimiv `__tcfapi` või samaväärne).

3. Eelistame CMP-d, mille kontrollitud selektorid vastavad nähtavatele DOM-elementidele, üle selle, mis on tuvastatud ainult skripti URL-i järgi.

See heuristika ei ole täiuslik, kuid lahendas levinumad valetuvastamise juhtumid, millega arenduse ja testimise käigus kokku puutusime.

Piirangud

Ükski automatiseeritud skanner ei kopeeri täiuslikult iga inimese sirvimiskogemust. Need on teadaolevad piirangud:

GeoIP-sõltuvad bännerid. Mõned CMP-d, eriti CookieYes, teenindavad erinevaid nõusolekukogemusi külastaja IP-geolokatsiooni alusel. Meie skaneerimised pärinevad konkreetsetest võrguasukohtadest Euroopas. Sait, mis näitab nõusolekubännerit Prantsusmaa külastajatele, kuid mitte väljaspool EL-i asuvatele külastajatele, näitab erinevaid tulemusi sõltuvalt skaneerimise päritolust. Me ei skaneeri praegu iga saiti igast EL-i riigist. Suletud vari-DOM. Mõned CMP-d renderdavad oma bänneri suletud vari-DOM-i sisse, mis on standardsetele DOM-päringutele kättesaamatu `document.querySelector` kaudu. Transcend'i CMP kasutab seda lähenemist. Meie skanner suudab tuvastada varihost-elemendi, kuid ei saa kontrollida selle sisu nõustumise/keeldumise nuppude leidmiseks. Need saidid lõpevad meie tulemustes tavaliselt ebamäärastena. Dünaamilised klassinimed ja obfuskeerimine. Mõned CMP-d, eriti Admiral, kasutavad dünaamiliselt genereeritud klassinimesid, mis muutuvad igal lehekülastusel. Selektoripõhine tuvastamine ebaõnnestub nende puhul, sest selektorid ei ole külastuste lõikes stabiilsed. Me langeme tagasi üldistele heuristikatele, kuid usaldusväärsus on madalam. Ühelehelised rakendused. SPA-d, mis haldavad nõusolekuolekut täielikult kliendipoolses JavaScriptis ja laevad nõusolekumehhanismi pärast esialgseid marsruudimuutusi (mitte esialgsel lehekülastusel), on raskemini hinnatavad. Meie skanner navigeerib URL-ile ja ootab lehe stabiliseerumist, kuid ei simuleeri rakendusesisest navigeerimist. Nõusolekubänner, mis ilmub alles pärast kasutaja SPA-sisest navigeerimist, võidakse märkamata jätta. Keeleline katvus. Meie keeldumise nupu tuvastamine kasutab teksti sobitamist toetatud keelte komplekti lõikes, kuid me ei kata iga EL-i keelt võrdselt. Malta keeles või eesti keeles olev bänner võib omada keeldumise nupu silte, mida meie teksti sobitamine ei tunne ära, viies keeldumise voo testimise kaotamiseni (kuigi bännerit ennast võidakse struktuuriliste heuristikate abil siiski tuvastada). Ajastuse äärejuhtumid. Skript, mis käivitub 30 sekundit pärast lehe laadimist, jääb tabamata skaneerimise puhul, mis ootab 15 sekundit võrgu jõudeolekut. Kasutame heldetelt ajalõppe, kuid asünkroonse käitumise pikk saba on olemuslikult raske täielikult tabada.

Need piirangud aitavad kaasa meie 14,9% ebaselgele määrale.

Infrastruktuur

Tootmise skaneerimisinfrastruktuur koosneb:

• Skaneerimismootor: Go rakendus, mis kasutab chromedp-d CDP kliendina Chromium automatiseerimiseks. Go valiti selle samaaegsuse mudeli (gorutiinid ja kanalid kaardistuvad loomulikult paralleelsele skaneerimise orkestreerimisele), jõudlusomaduste ja paigalduse lihtsuse tõttu (üksik staatiline binaar).
• Brauseri käitusaeg: Peata Chromium, mis käivitatakse skaneerimise kohta CDP kaudu. Iga skaneerimine saab värske brauseriprotsessi ilma jagatud olekuta.
• Järjekord: Redis-põhine tööjärjekord, mis jaotab URL-e skanneritöötajatele. Redis tegeleb tööde jaotamise, edenemise jälgimise ja kiiruspiiranguga.
• Andmebaas: PostgreSQL püsivate skaneerimistulemuste, leidude, tõendite metaandmete ja kõigi struktureeritud andmete jaoks. Skaneerimised, leiud, küpsised, päringud ja analüüsiväljundid on kõik salvestatud relatsiooniliselt.
• DNS-vahemälu: Kohalik Unbound lahendaja, mis pakub vahemällu salvestatud DNS-otsinguid ja SSRF-ohutut lahendamist.
• Tõendite hoidla: Ekraanipildid, HAR-failid ja PDF-aruanded salvestatakse püsivate artefaktidena, mis on seotud skaneerimiskirjetega.

97 304 saidi uuringu jaoks töötlesime 114 748 kandidaat-URL-i (97 304 lõpetati edukalt) ligikaudu 2,5 päeva jooksul, kasutades 3 serverit, mis käitasid skanneritöötajaid paralleelselt. Iga server käitas mitut tööprotsessi 15 samaaegse skaneerimispesaga igaühes. Tippläbilaskvus oli ligikaudu 25-30 lõpetatud skaneerimist minutis serveri kohta.

Peamine pudelikael ei olnud protsessor ega mälu, vaid võrk: iga skaneerimine genereerib sadu väljaminevaid päringuid (sihtlehele ja selle kolmandate osapoolte ressurssidele) ning kogu samaagsete skaneerimiste koondribalaius ja ühenduste arv küllastas saadaolevat võrguvõimekust enne teiste ressursside ammendumist.

Lahendamata väljakutsed ja tulevane töö

Mitmed probleemid jäävad lahendamata või osaliselt lahendatuks:

Nõusolekubänneri lokaliseerimine. Meie teksti sobitamine katab suuremaid EL-i keeli, kuid on väiksemate keelekogukondade jaoks puudulik. Katvuse laiendamine nõuab mitte ainult tõlgete lisamist, vaid ka valideerimist, et selektorid ja suhtlusmustrid töötavad õigesti lokaliseeritud CMP versioonidega. Pikaajaline jälgimine. Meie praegune arhitektuur on optimeeritud hetkseisu skaneerimiseks. Nõusolekukäitumise muutuste tuvastamine ajas -- kas sait paranes pärast jõustamist? Kas CMP uuendus parandas keeldumise voo ebaõnnestumiste klassi? -- nõuab korduvaid skaneerimisi diferentsiaalse analüüsiga, mis on arhitektuuriliselt erinev ühekordisest hindamisest. CMP vastavuse võrdlustestid. Meil on andmed CMP-põhiste vastavusmäärade hindamiseks (kas Cookiebot on seotud parema vastavusega kui OneTrust?), kuid CMP kvaliteedi eristamine saidi operaatori konfiguratsiooni kvaliteedist on metoodiliselt keeruline. CMP, mida sageli rakendavad suured ettevõtted pühendunud privaatsusmeeskondadega, näeb koondandmetes parem välja isegi siis, kui tööriist ise ei ole nõuetele vastavam. Reaalajaline nõusolekuoleku kontrollimine. Praegune skanner töötab partii režiimis. Nõusoleku kontrolli integreerimine CI/CD pipeline'idesse või reaalajalisse jälgimisse nõuab kiiremat, kergemat skaneerimisrežiimi, mis ohverdab osa tõendusmaterjali sügavusest kiiruse nimel. Me uurime seda.

API

Sama skaneerimismootor, mida selles postituses kirjeldati, on saadaval GDPR Monitor'i avaliku API kaudu. Saate esitada skaneerimispäringuid programmiliselt, küsitleda tulemusi ja hankida struktureeritud leide ja tõendusmaterjali artefakte. API tagastab samad andmed, mida meie kasutajaliides kuvab: nõusolekueelsed hetktõmmised, küpsiste inventuurid, CMP tuvastamise tulemused, keeldumise voo tulemused, riskiskoorid ja täielikud tõendusketid.

Kui te ehitate vastavustööriistu, integreerite privaatsuskontrolle CI/CD pipeline'idesse, viite läbi oma uurimistööd või ehitate jälgimist privaatsusprogrammi, pakub API juurdepääsu käitumuslikule nõusolekuanalüüsile ilma vajaduseta ehitada ja hooldada oma Chromium automatiseerimise infrastruktuuri.

---

Proovige ise. API dokumentatsioon on saadaval aadressil gdprprivacymonitor.eu/developers/api. Esitage üksik URL või integreerige automatiseeritud privaatsuse jälgimine oma töövoolu.