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

Automatická kontrola dodržiavania súhlasu znie jednoducho, kým sa ju nepokúsite vybudovať. Naivný prístup -- načítať stránku, skontrolovať cookies, hľadať banner -- minie väčšinu toho, na čom záleží. Porušenia súhlasu sú behaviorálne, nie štrukturálne. Prejavujú sa v časovaní vykonávania skriptov, v sekvencii sieťových požiadaviek, v reakcii prvkov používateľského rozhrania na interakciu používateľa a v pretrvavaní stavu naprieč načítaniami stránky. Nič z toho nemôžete posúdiť bez spustenia reálneho prehliadača, interakcie so stránkou tak, ako by to robil človek, a zaznamenávania toho, čo sa skutočne deje na úrovni siete.

Tento príspevok popisuje, ako sme vybudovali skenovací engine za GDPR Monitor, inžinierske výzvy, ktoré spotrebovali väčšinu nášho času, architektonické rozhodnutia, ktoré sme urobili a prečo, a obmedzenia, ku ktorým sme úprimní. Ak pracujete na webovom súlade, automatizácii prehliadačov alebo meraniach webu vo veľkom meradle, mali by ste tu nájsť niečo užitočné.

Prehľad pipeline

Každé skenovanie prechádza šiestimi fázami. Pochopenie pipeline je nevyhnutný kontext pre konkrétne výzvy, ktoré nasledujú.

Fáza 1: Spustenie prehliadača a izolácia. Čerstvá inštancia Chromium sa spustí s nulovým stavom -- žiadne cookies, žiadny localStorage, žiadna vyrovnávacia pamäť, žiadni service workers. Toto je záruka čistej miestnosti, ktorá robí meranie pred súhlasom zmysluplným. Konfigurujeme štandardný viewport, realistický user-agent a hlavičky Accept-Language zodpovedajúce cieľovej krajine a štandardné príznaky prehliadača. Každé skenovanie dostáva svoj vlastný proces prehliadača; medzi skenovaniami nedochádza k úniku stavu. Fáza 2: Navigácia a snímka pred súhlasom. Skener naviguje na cieľovú URL, čaká, kým stránka dosiahne stabilný stav (sieťový kľud, ustálený DOM), a zachytáva všetko, čo sa stalo: nastavené cookies, vykonané sieťové požiadavky (s úplnou URL, časovaním a metadátami odpovede), kontaktované domény tretích strán a snímku celej stránky. Táto snímka odpovedá na základnú otázku: čo táto webová stránka urobila predtým, než mal používateľ akúkoľvek možnosť udeliť súhlas? Fáza 3: Detekcia CMP a identifikácia bannera. Skener sa pokúša identifikovať platformu na správu súhlasu a nájsť banner súhlasu, tlačidlo prijatia a tlačidlo odmietnutia. Používa na to viacvrstvový detekčný systém popísaný podrobne nižšie. Fáza 4: Interakcia so súhlasom. Skener interaguje s bannerom -- klikne na prijať pre štandardný tok, klikne na odmietnuť pre test toku odmietnutia. Čaká, kým sa stránka po interakcii ustáli, pričom zohľadňuje animácie, opätovné vyhodnotenie skriptov a oneskorené spúšťanie značiek. Fáza 5: Snímka po súhlase a diferenciálna analýza. Druhá úplná snímka zachytáva stav po interakcii so súhlasom. Porovnanie snímok pred súhlasom a po súhlase odhaľuje, čo sa zmenilo: nové cookies, nové sledovacie požiadavky, stav súhlasu v API CMP. Fáza 6: Analýza, klasifikácia a generovanie správy. Surové dáta sa privádzajú do analytických modulov: klasifikácia cookies oproti našej databáze, párovanie sledovačov oproti známym vzorom, hodnotenie životnosti cookies, audit prístupnosti bannera, validácia Google Consent Mode, detekcia signálov fingerprintingu a bodovanie rizika. Výstupom je štruktúrovaná správa so zisteniami, dôkazovými artefaktmi a kompozitným rizikovým skóre.

Každá fáza produkuje dôkazy s časovou pečiatkou, ktoré sú trvalo uložené. Akékoľvek zistenie možno spätne sledovať ku konkrétnym sieťovým požiadavkám, záznamom cookies alebo snímkam obrazovky.

Výzva 1: Detekcia CMP -- 45 platforiem, nekonečné variácie

Správa súhlasu nie je štandardizovaná. Neexistuje žiadny univerzálny HTML atribút, žiadne povinné JavaScript API, žiadna konzistentná štruktúra DOM, ktorá by hovorila „toto je banner súhlasu." V našej detekčnej knižnici je 45 odlišných CMP, každý so svojou vlastnou štruktúrou DOM, signatúrami skriptov, JavaScript globálnymi premennými a interakčnými vzormi. Okrem nich 34,7 % bannerov, ktoré sme detegovali v našej štúdii 97 304 stránok, bolo generických alebo neidentifikovaných -- vlastné implementácie, regionálni dodávatelia alebo minimálne riešenia, ktoré nezodpovedajú žiadnej známej CMP signatúre.

Naša detekcia používa viacvrstvový prístup založený na dôvere:

Vrstva 1: Detekcia signatúr skriptov

Skener kontroluje prítomnosť známych CMP skriptov podľa vzoru URL a globálnych JavaScript premenných. Cookiebot sa napríklad načítava z `consent.cookiebot.com` a sprístupňuje `window.Cookiebot`. OneTrust sa načítava z `cdn.cookielaw.org` a sprístupňuje `window.OneTrust`. Každý CMP má charakteristické vzory načítavania, ktoré možno detegovať pred skúmaním DOM.

Táto vrstva je rýchla a s vysokou dôverou, keď nájde zhodu. Má však kritické obmedzenie: povie vám, ktorý CMP je na stránke prítomný, nie nevyhnutne ktorý CMP je zodpovedný za banner súhlasu. Stránka môže načítať PiwikPRO pre analytiku (ktorá obsahuje komponent CMP) a zároveň používať tarteaucitron na skutočnú správu súhlasu. Detegovať oba skripty je jednoduché; vedieť, ktorý ovláda banner, je ťažšie.

Vrstva 2: Overené párovanie selektorov

Pre každý známy CMP udržiavame kurátorovanú sadu CSS selektorov, ktoré spoľahlivo identifikujú kontajner bannera, tlačidlo prijatia a tlačidlo odmietnutia. Tieto selektory sme overili naprieč viacerými verziami a konfiguráciami každého CMP. Keď je CMP detegovaný vo vrstve 1 a jeho overené selektory zodpovedajú prvkom v DOM, máme vysokú dôveru v identifikáciu CMP aj v ciele interakcie s bannerom.

Vrstva 3: Kompatibilné párovanie selektorov

Širšia sada selektorov, ktorá funguje naprieč mnohými verziami CMP, ale je menej presná. Zvláda prípady, keď bol CMP prispôsobený, pretematizovaný alebo beží vo verzii, ktorú naše overené selektory nepokrývajú. Obetujú presnosť za pokrytie.

Vrstva 4: Generické heuristiky

Pre 34,7 % bannerov, ktoré nie sú spojené so známym CMP, sa vraciame k heuristickej detekcii. Skener hľadá:

• Prvky s fixnou alebo sticky pozíciou v blízkosti spodnej alebo hornej časti viewportu
• Prvky obsahujúce kľúčové slová súvisiace so súhlasom vo viacerých jazykoch („cookies," „consent," „privacy," „akzeptieren," „accepter," „aceptar," atď.)
• Tlačidlá s bežnými popismi akcií súhlasu („Accept All," „Reject All," „Manage Preferences" a ekvivalenty)
• Štrukturálne vzory typické pre dialógy súhlasu: prekryvné pozadia, modálne kontajnery, tlačidlá zatvorenia

Táto vrstva zachytáva mnohé vlastné implementácie, ale je zo svojej podstaty menej spoľahlivá. Promočný banner s fixnou pozíciou alebo prihlásenie na newsletter môže vyzerať štrukturálne podobne ako dialóg súhlasu.

Vrstva 5: Testovanie API CMP

Niektoré CMP sprístupňujú JavaScript API -- predovšetkým IAB Transparency and Consent Framework (TCF) API cez `__tcfapi`. Testujeme tieto API, aby sme overili detekciu CMP aj prečítali programatický stav súhlasu, ktorý neskôr porovnávame s pozorovaným správaním prehliadača.

Model dôvery

Namiesto toho, aby sme detekciu považovali za binárnu (nájdené/nenájdené), priraďujeme skóre dôvery na základe toho, ktoré vrstvy sa zhodli a akou silou. Stránka, kde detegujeme CMP skript, nájdeme zhodu s overenými selektormi a nájdeme TCF API, dostáva vysokú dôveru. Stránka, kde sa aktivovali len generické heuristiky, dostáva nižšiu dôveru. Toto skóre dôvery vstupuje do našej klasifikácie rizika -- nižšia dôvera detekcie znamená, že zistenia budú s väčšou pravdepodobnosťou klasifikované ako nepreukazné, nie definitívne.

Model dôvery je dôvod, prečo chybná identifikácia CMP, hoci sa vyskytuje, systematicky neskresluje naše výsledky. Keď je detekcia nejednoznačná, povieme to, namiesto toho, aby sme vynútili klasifikáciu.

Výzva 2: Tok odmietnutia -- Prečo je „klikni a skontroluj" prekvapivo ťažké

Testovanie tlačidla odmietnutia znie jednoducho: nájdite ho, kliknite naň, skontrolujte, či cookies zmizli. V praxi je každý krok plný problémov s časovaním, asynchrónnym správaním a špecifikami jednotlivých platforiem.

Nájdenie tlačidla odmietnutia. Nie všetky tlačidlá odmietnutia sú označené „Odmietnuť." Môžu hovoriť „Decline All," „Refuse," „Only necessary cookies," „Manage settings" (vedúce k druhej vrstve, kde je možné odmietnutie) alebo ekvivalenty v desiatkach jazykov. Niektoré CMP umiestňujú možnosť odmietnutia na iné vizuálne miesto, v inej veľkosti alebo inej farbe oproti tlačidlu prijatia. Niektoré ju skrývajú za odkaz „More options" alebo „Customize." Náš skener udržiava viacjazyčnú sadu vzorov akcií odmietnutia a tiež deteguje možnosti odmietnutia v druhej vrstve, kde prvá vrstva ponúka len prijatie a prispôsobenie. Čakanie na správny moment. Po kliknutí na odmietnuť môže stránka prejsť významnými zmenami: banner sa zatvorí (často s animáciou), CMP spúšťa callbacky stavu súhlasu, správcovia značiek prehodnocujú svoje pravidlá a skripty sa môžu načítať alebo uvoľniť. Kontrola cookies príliš skoro zachytáva stav uprostred prechodu. Kontrola príliš neskoro minie prechodné sledovanie, ktoré sa spustí a rýchlo dokončí. Používame čakanie na viacero signálov: sieťový kľud, stabilita DOM a minimálny časový prah, naladený z empirického testovania naprieč stovkami konfigurácií CMP. Test opätovného načítania a obnova súhlasu. Krok opätovného načítania je to, čo odhalilo obnovu súhlasu ako fenomén. Nevydali sme sa ho hľadať -- náš pôvodný test toku odmietnutia kontroloval len okamžitý stav po odmietnutí. Počas vývoja sme si však všimli stránky, ktoré vyzerali čisto po odmietnutí, ale mali sledovacie cookies, keď sme skontrolovali znova po opätovnom načítaní stránky. Pôvodné ladenie predpokladalo problém s časovaním skenera. Ďalšie vyšetrovanie potvrdilo, že to bolo reálne: skripty tretích strán opätovne nastavovali cookies pri načítaní stránky bez ohľadu na stav súhlasu.

Pridali sme explicitnú detekciu obnovy do pipeline: po toku odmietnutia skener opätovne načíta stránku, počká na stabilitu a porovná inventár cookies so snímkou po odmietnutí. Akýkoľvek cookie, ktorý bol odstránený odmietnutím a znova sa objaví po opätovnom načítaní, je označený ako obnovený. Toto zachytilo 1 642 stránok so 4 932 obnovujúcimi sa cookies -- zistenie, ktoré by bolo neviditeľné bez kroku opätovného načítania.

Poll `waitForScriptIdentifiedCMP`. Niektoré CMP sa načítavajú asynchrónne a nevykresľujú svoj banner až niekoľko sekúnd po úvodnom načítaní stránky. Ak skener pokračuje ku kroku odmietnutia predtým, než sa CMP inicializoval, buď úplne mine banner, alebo interaguje s čiastočne načítaným UI. Implementovali sme mechanizmus pollovania, ktorý čaká na sprístupnenie JavaScript API CMP (napr. `__tcfapi` pre CMP založené na TCF, globálny `Cookiebot` pre Cookiebot) pred pokračovaním. Pridáva to latenciu na skenovanie, ale výrazne znižuje falošné negatívy z asynchrónneho načítavania CMP.

Výzva 3: Saturácia pipeline vo veľkom meradle

Skenovanie 97 304 webových stránok nie je práca pre jeden stroj. Každé skenovanie spúšťa proces Chromium, naviguje na webovú stránku, zachytáva a klasifikuje stovky sieťových požiadaviek, vytvára viaceré snímky obrazovky a spúšťa analytické moduly. Jedno skenovanie trvá 30-90 sekúnd v závislosti od zložitosti stránky. Pri 15 súbežných skenovaniach na worker sa správa zdrojov stáva primárnym inžinierskym problémom.

Architektúra semaforu

Používame model súbežnosti založený na semafore na obmedzenie počtu simultánnych procesov Chromium na worker. Každý worker má pevný semafor (15 slotov v našej produkčnej konfigurácii). Skenovanie získa slot pred spustením prehliadača a uvoľní ho po dokončení. Toto zabraňuje vyčerpaniu pamäte -- 15 inštancií Chromium s úplným zachytávaním požiadaviek už spotrebúva značnú RAM -- a poskytuje spätný tlak voči fronty Redis.

Výnimka pre požiadavku dokumentu

Na začiatku vývoja sme narazili na problém s priepustnosťou: naša logika zachytávania požiadaviek (ktorá kontroluje každú požiadavku na bezpečnosť SSRF -- blokuje požiadavky na súkromné rozsahy IP, interné siete a iné potenciálne nebezpečné ciele) pridávala latenciu ku každému načítaniu zdroja, vrátane hlavnej požiadavky dokumentu. Keďže URL dokumentu bola už validovaná pred začatím skenovania, pridali sme rýchlu obchádzku: požiadavky typu dokument na predvalidovanú cieľovú URL preskakujú úplný pipeline zachytávania. Táto zdanlivo malá optimalizácia mala významný dopad na celkovú priepustnosť, pretože požiadavka dokumentu blokuje všetko ostatné.

Predhrievanie DNS

Prvá požiadavka na novú doménu si vyžaduje vyhľadávanie DNS, čo na našej infraštruktúre mohlo pridať 50-200 ms na doménu. Keďže priemerná stránka kontaktuje 10,4 domén tretích strán (a niektoré až 171), čas rozlíšenia DNS sa výrazne akumuloval. Implementovali sme predhrievanie DNS pomocou lokálnej vyrovnávacej pamäte DNS rezolvera Unbound: pred každým skenovaním rozlíšime cieľovú doménu a zahrejeme vyrovnávaciu pamäť. Inštancia Unbound poskytuje odpovede z vyrovnávacej pamäte pre následné vyhľadávania v rámci skenovania, čím znižuje réžiu DNS na doménu na submilisekundovú.

Bezpečnosť SSRF vo veľkom meradle

Každá požiadavka zachytená skenerom je skontrolovaná oproti sade bezpečnostných pravidiel pred povolením pokračovať. Požiadavky na súkromné rozsahy IP (RFC 1918, RFC 4193, link-local, loopback) sú blokované. Toto zabraňuje škodlivej cieľovej stránke použiť skener ako SSRF vektor na sondovanie interných sietí.

Výzvou vo veľkom meradle bolo rozlíšenie skutočných blokovaní SSRF od saturácie semaforu. Keď je všetkých 15 slotov semaforu v používaní a skenovanie nemôže získať slot, výsledný timeout vyzerá povrchne podobne ako požiadavka blokovaná z bezpečnostných dôvodov. Pridali sme explicitnú kategorizáciu chýb na rozlíšenie „blokované, pretože cieľ sa rozlíšil na súkromnú IP" od „blokované, pretože skener je na kapacite." Toto bolo nevyhnutné pre prevádzkový monitoring a presnú klasifikáciu zlyhaní skenovania.

Výzva 4: Detekcia obchádzania botov

Počas štúdie sme identifikovali 137 webových stránok, ktoré zjavne zámerne skrývajú svoj banner súhlasu pred automatizovanými skenermi. Banner sa zobrazuje ľudským návštevníkom, ale je potlačený, keď stránka deteguje charakteristiky automatizovaného prehliadania.

Najčastejší mechanizmus, ktorý sme identifikovali, zahŕňa konfiguračnú možnosť `isAcceptAllForBots` WordPress pluginu RCB (Real Cookie Banner). Keď je aktivovaná, toto nastavenie deteguje automatizované prehliadače (cez `navigator.webdriver`, heuristiky user-agent alebo behaviorálne signály) a buď automaticky prijme súhlas v ich mene, alebo úplne skryje banner. Zámer, ako dokumentuje plugin, je zabrániť automatizovaným návštevníkom v zobrazení dialógu súhlasu, s ktorým nemôžu zmysluplne interagovať. Efekt je, že skenery dodržiavania -- a regulačné audity používajúce automatizované nástroje -- vidia stránku, ktorá vyzerá, že nemá žiadny mechanizmus súhlasu, zatiaľ čo ľudskí návštevníci vidia plný banner súhlasu.

Toto je problém transparentnosti. Ak je mechanizmus súhlasu webovej stránky viditeľný len pre ľudských návštevníkov, nemožno ho auditovať vo veľkom meradle. Tieto stránky označujeme v našich výsledkoch osobitne, pretože zistenie je kvalitatívne odlišné od „banner nebol detegovaný." Stránka banner má; rozhodla sa nám ho neukázať.

Obchádzanie botov detegujeme kombináciou signálov: prítomnosť známej konfigurácie detekcie botov v nastaveniach CMP (dostupných cez inšpekciu JavaScript), nezrovnalosti medzi tým, čo DOM zobrazuje a čo API CMP hlási, a v niektorých prípadoch porovnaním výsledkov automatizovaného skenovania s manuálnym overením.

Číslo 137 je určite podhodnotenie. Obchádzanie botov môžeme detegovať len vtedy, keď dokážeme identifikovať mechanizmus. Stránky používajúce sofistikovanejšiu alebo vlastnú detekciu botov môžu úspešne obísť náš skener aj našu detekciu obchádzania.

Výzva 5: Chybná identifikácia CMP

Stránka môže načítať viaceré skripty, ktoré vyzerajú ako platformy na správu súhlasu. PiwikPRO obsahuje komponent CMP, ale je primárne analytickou platformou. Niektoré WordPress stránky načítavajú Complianz spolu so samostatným analytickým pluginom, ktorý má funkcie podobné CMP. Podnikové stránky môžu mať zvyšky predchádzajúceho CMP, ktorý sa stále načítava vedľa aktuálneho.

Naivná detekcia -- „ak vidíme skript, je to CMP" -- produkuje falošné identifikácie, ktoré sa kaskádovito premietajú do nesprávnej interakcie s bannerom. Ak skener identifikuje PiwikPRO ako CMP a pokúsi sa použiť selektory bannera PiwikPRO, môže minúť skutočný banner tarteaucitron, ktorý ovláda súhlas na stránke.

Náš prístup založený na dôvere to rieši zoradením kandidátov CMP. Keď sú detegované viaceré potenciálne CMP:

1. Kontrolujeme, ktorý má viditeľný banner v DOM (skript prítomný, ale žiadny banner znamená pravdepodobne neaktívny alebo použitie iné ako CMP).

2. Kontrolujeme, ktorý sprístupňuje aktívne API CMP (napr. funkčný `__tcfapi` alebo ekvivalent).

3. Uprednostňujeme CMP, ktorého overené selektory zodpovedajú viditeľným prvkom DOM, pred tým, ktorý je detegovaný len podľa URL skriptu.

Táto heuristika nie je dokonalá, ale vyriešila najčastejšie prípady chybnej identifikácie, na ktoré sme narazili počas vývoja a testovania.

Obmedzenia

Žiadny automatizovaný skener dokonale nereplikuje každú ľudskú skúsenosť s prehliadaním. Toto sú známe obmedzenia:

Bannery závislé od GeoIP. Niektoré CMP, predovšetkým CookieYes, zobrazujú rôzne zážitky súhlasu na základe geolokácie IP návštevníka. Naše skenovania pochádzajú z konkrétnych sieťových lokácií v Európe. Stránka, ktorá zobrazuje banner súhlasu návštevníkom z Francúzska, ale nie návštevníkom mimo EÚ, bude zobrazovať rôzne výsledky v závislosti od pôvodu skenovania. Momentálne neskenujeme každú stránku z každej krajiny EÚ. Uzavretý shadow DOM. Niektoré CMP vykresľujú svoj banner vnútri uzavretého shadow DOM, ktorý je neprístupný štandardným DOM dopytom cez `document.querySelector`. CMP od Transcend používa tento prístup. Náš skener dokáže detegovať hostiteľský prvok shadow, ale nemôže skúmať jeho obsah na nájdenie tlačidiel prijatia/odmietnutia. Tieto stránky zvyčajne skončia v našich výsledkoch ako nepreukazné. Dynamické názvy tried a obfuskácia. Niektoré CMP, predovšetkým Admiral, používajú dynamicky generované názvy tried, ktoré sa menia pri každom načítaní stránky. Detekcia na základe selektorov pre ne zlyháva, pretože selektory nie sú stabilné naprieč návštevami. Vraciame sa ku generickým heuristikám, ale dôvera je nižšia. Single-page aplikácie. SPA, ktoré spravujú stav súhlasu úplne v klientskom JavaScript a načítavajú mechanizmus súhlasu po úvodných zmenách trás (nie pri úvodnom načítaní stránky), sa ťažšie posudzujú. Náš skener naviguje na URL a čaká na stabilizáciu stránky, ale nesimuluje navigáciu v rámci aplikácie. Banner súhlasu, ktorý sa objaví až po tom, čo používateľ naviguje v rámci SPA, môže byť vynechaný. Jazykové pokrytie. Naša detekcia tlačidla odmietnutia používa párovanie textu naprieč sadou podporovaných jazykov, ale nepokrývame každý jazyk EÚ rovnako. Banner v maltčine alebo estónčine môže mať popisky tlačidla odmietnutia, ktoré naše párovanie textu nerozpozná, čo vedie k vynechaniu testovania toku odmietnutia (hoci samotný banner môže byť stále detegovaný štrukturálnymi heuristikami). Okrajové prípady časovania. Skript, ktorý sa spustí 30 sekúnd po načítaní stránky, bude vynechaný skenom, ktorý čaká 15 sekúnd na sieťový kľud. Používame veľkorysé časové limity, ale dlhý chvost asynchrónneho správania je zo svojej podstaty ťažko zachytiteľný úplne.

Tieto obmedzenia prispievajú k našej 14,9 % miere nepreukazných výsledkov.

Infraštruktúra

Produkčná skenovacia infraštruktúra pozostáva z:

• Skenovací engine: Go aplikácia používajúca chromedp ako CDP klient pre automatizáciu Chromium. Go bol zvolený pre svoj model súbežnosti (gorutiny a kanály sa prirodzene mapujú na paralelnú orchestráciu skenovania), jeho výkonnostné charakteristiky a jednoduchosť nasadenia (jeden statický binárny súbor).
• Behové prostredie prehliadača: Headless Chromium spúšťaný na skenovanie cez CDP. Každé skenovanie dostáva čerstvý proces prehliadača s nulovým zdieľaným stavom.
• Fronta: Pracovná fronta založená na Redis distribuujúca URL na skenery workers. Redis zabezpečuje distribúciu úloh, sledovanie priebehu a obmedzovanie rýchlosti.
• Databáza: PostgreSQL pre trvalé výsledky skenov, zistenia, metadáta dôkazov a všetky štruktúrované dáta. Skeny, zistenia, cookies, požiadavky a analytické výstupy sú všetky uložené relačne.
• DNS cache: Lokálny rezolver Unbound poskytujúci cachované DNS vyhľadávania a SSRF-bezpečné rozlíšenie.
• Úložisko dôkazov: Snímky obrazovky, HAR súbory a PDF správy sú uložené ako trvalé artefakty prepojené so záznamami skenov.

Pre štúdiu 97 304 stránok sme spracovali 114 748 kandidátnych URL (97 304 úspešne dokončených) za približne 2,5 dňa s použitím 3 serverových inštancií paralelne bežiacich scanner workers. Každý server bežal viaceré worker procesy so 15 súbežnými skenovacími slotmi. Špičková priepustnosť bola zhruba 25-30 dokončených skenov za minútu na server.

Primárnym úzkym hrdlom nebol CPU ani pamäť, ale sieť: každé skenovanie generuje stovky odchádzajúcich požiadaviek (na cieľovú stránku a jej zdroje tretích strán) a agregovaná šírka pásma a počet pripojení naprieč všetkými súbežnými skenovaniami saturovali dostupnú sieťovú kapacitu skôr, než boli vyčerpané ostatné zdroje.

Otvorené výzvy a budúca práca

Niekoľko problémov zostáva nevyriešených alebo čiastočne vyriešených:

Lokalizácia bannerov súhlasu. Naše párovanie textu pokrýva hlavné jazyky EÚ, ale je neúplné pre menšie jazykové komunity. Rozšírenie pokrytia si vyžaduje nielen pridanie prekladov, ale aj overenie, že selektory a interakčné vzory správne fungujú s lokalizovanými verziami CMP. Longitudinálny monitoring. Naša súčasná architektúra je optimalizovaná na skenovanie v konkrétnom čase. Detekcia zmien v správaní súhlasu v čase -- zlepšila sa stránka po vynucovaní? Opravil update CMP triedu zlyhaní toku odmietnutia? -- vyžaduje opakované skenovania s diferenciálnou analýzou, čo je architektonicky odlišné od jednorázového hodnotenia. Benchmarking dodržiavania CMP. Máme dáta na posúdenie mier dodržiavania podľa CMP (je Cookiebot spojený s lepším dodržiavaním než OneTrust?), ale oddelenie kvality CMP od kvality konfigurácie prevádzkovateľom stránky je metodologicky zložité. CMP, ktorý je častejšie nasadzovaný veľkými podnikmi s dedikovanými tímami pre súkromie, bude v súhrne vyzerať lepšie, aj keď samotný nástroj nie je o nič súladnejší. Overenie stavu súhlasu v reálnom čase. Súčasný skener pracuje v dávkovom režime. Integrácia overovania súhlasu do CI/CD pipeline alebo monitorovania v reálnom čase vyžaduje rýchlejší, ľahší režim skenovania, ktorý obetuje určitú hĺbku dôkazov za rýchlosť. Toto skúmame.

API

Rovnaký skenovací engine popísaný v tomto príspevku je dostupný cez verejné API GDPR Monitor. Požiadavky na skenovanie môžete odosielať programaticky, dotazovať sa na výsledky a získavať štruktúrované zistenia a dôkazové artefakty. API vracia rovnaké dáta, aké zobrazuje naše UI: snímky pred súhlasom, inventáre cookies, výsledky detekcie CMP, výsledky toku odmietnutia, rizikové skóre a kompletné reťazce dôkazov.

Ak budujete nástroje dodržiavania, integrujete kontroly súkromia do CI/CD pipeline, vediete vlastný výskum alebo budujete monitoring do programu ochrany súkromia, API poskytuje prístup k behaviorálnej analýze súhlasu bez potreby budovať a udržiavať vlastnú infraštruktúru automatizácie Chromium.

---

Vyskúšajte sami. API dokumentácia je dostupná na gdprprivacymonitor.eu/developers/api. Odošlite jednu URL alebo integrujte automatizovaný monitoring súkromia do vášho workflow.