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

Automatická kontrola dodržování souhlasu zní jednoduše, dokud se ji nepokusíte vybudovat. Naivní přístup -- stáhnout stránku, zkontrolovat cookies, podívat se na banner -- mine většinu toho, na čem záleží. Porušení souhlasu jsou behaviorální, nikoli strukturální. Projevují se v časování spouštění skriptů, v sekvenci síťových požadavků, v reakci prvků uživatelského rozhraní na interakci uživatele a v přetrvávání stavu napříč načteními stránky. Nic z toho nelze posoudit bez spuštění skutečného prohlížeče, interakce se stránkou způsobem, jakým by to udělal člověk, a zaznamenání toho, co se skutečně děje na úrovni sítě.

Tento příspěvek popisuje, jak jsme vybudovali skenovací engine za GDPR Monitorem, inženýrské výzvy, které spotřebovaly většinu našeho času, architektonická rozhodnutí, která jsme učinili a proč, a omezení, o kterých jsme upřímní. Pokud pracujete na webovém dodržování předpisů, automatizaci prohlížeče nebo rozsáhlém měření webu, mělo by zde být něco užitečného.

Přehled pipeline

Každý sken prochází šesti fázemi. Pochopení pipeline je nezbytný kontext pro konkrétní výzvy, které následují.

Fáze 1: Spuštění prohlížeče a izolace. Čerstvá instance Chromium se spustí s nulovým stavem -- žádné cookies, žádný localStorage, žádná cache, žádní service workers. Toto je záruka čistého prostředí, která činí měření před souhlasem smysluplným. Konfigurujeme standardní viewport, realistické hlavičky user-agent a Accept-Language odpovídající cílové zemi a standardní příznaky prohlížeče. Každý sken dostane vlastní proces prohlížeče; mezi skeny nedochází k úniku stavu. Fáze 2: Navigace a snímek před souhlasem. Skener přejde na cílovou URL, počká, až stránka dosáhne stabilního stavu (síťový klid, ustálený DOM), a zachytí vše, co se stalo: nastavené cookies, provedené síťové požadavky (s kompletní URL, časováním a metadaty odpovědi), kontaktované domény třetích stran a snímek celé stránky. Tento snímek odpovídá na základní otázku: co tato webová stránka udělala, než měl uživatel jakoukoli příležitost udělit souhlas? Fáze 3: Detekce CMP a identifikace banneru. Skener se pokusí identifikovat platformu pro správu souhlasu a lokalizovat consent banner, tlačítko přijetí a tlačítko odmítnutí. Využívá se vrstvený detekční systém podrobně popsaný níže. Fáze 4: Interakce souhlasu. Skener interaguje s bannerem -- klikne na přijetí pro standardní tok, klikne na odmítnutí pro test toku odmítnutí. Počká na ustálení stránky po interakci, přičemž zohledňuje animace, přehodnocení skriptů a zpožděné spouštění tagů. Fáze 5: Snímek po souhlasu a diferenční analýza. Druhý kompletní snímek zachytí stav po interakci souhlasu. Porovnání snímků před a po souhlasu odhalí, co se změnilo: nové cookies, nové sledovací požadavky, stav souhlasu v API CMP. Fáze 6: Analýza, klasifikace a generování reportu. Surová data putují do analytických modulů: klasifikace cookies proti naší databázi, párování trackerů se známými vzorci, hodnocení životnosti cookies, audit přístupnosti banneru, validace Google Consent Mode, detekce signálů fingerprintingu a rizikové skóre. Výstupem je strukturovaný report se zjištěními, důkazními artefakty a souhrnným rizikovým skóre.

Každá fáze produkuje důkazy s časovým razítkem, které jsou trvale uloženy. Jakékoli zjištění lze vysledovat zpět ke konkrétním síťovým požadavkům, záznamům cookies nebo snímkům obrazovky.

Výzva 1: Detekce CMP -- 45 platforem, nekonečné variace

Správa souhlasu není standardizovaná. Neexistuje žádný univerzální HTML atribut, žádné povinné JavaScript API, žádná konzistentní DOM struktura, která říká "toto je consent banner". V naší detekční knihovně je 45 odlišných CMP, každý s vlastní DOM strukturou, podpisy skriptů, JavaScript globálními proměnnými a vzorci interakce. Navíc 34,7 % bannerů, které jsme detekovali v naší studii 97 304 stránek, bylo generických nebo neidentifikovaných -- vlastní implementace, regionální dodavatelé nebo minimální řešení, která neodpovídají žádnému známému podpisu CMP.

Naše detekce využívá přístup založený na důvěryhodnosti s více vrstvami:

Vrstva 1: Detekce podpisů skriptů

Skener kontroluje přítomnost známých skriptů CMP podle vzoru URL a globálních proměnných JavaScriptu. Cookiebot například načítá z `consent.cookiebot.com` a vystavuje `window.Cookiebot`. OneTrust načítá z `cdn.cookielaw.org` a vystavuje `window.OneTrust`. Každý CMP má charakteristické vzory načítání, které lze detekovat před zkoumáním DOM.

Tato vrstva je rychlá a vysoce důvěryhodná, když najde shodu. Má ale zásadní omezení: řekne vám, který CMP je na stránce přítomen, ne nutně který CMP je zodpovědný za consent banner. Stránka může načítat PiwikPRO pro analytiku (která zahrnuje komponentu CMP) a přitom používat tarteaucitron pro skutečnou správu souhlasu. Detekce obou skriptů je snadná; zjistit, který ovládá banner, je těžší.

Vrstva 2: Ověřené párování selektorů

Pro každý známý CMP udržujeme kurátorovanou sadu CSS selektorů, které spolehlivě identifikují kontejner banneru, tlačítko přijetí a tlačítko odmítnutí. Jde o selektory, které jsme ověřili napříč více verzemi a konfiguracemi každého CMP. Když je CMP detekován ve vrstvě 1 a jeho ověřené selektory odpovídají elementům v DOM, máme vysokou důvěru jak v identifikaci CMP, tak v cíle interakce s bannerem.

Vrstva 3: Kompatibilní párování selektorů

Širší sada selektorů, která funguje napříč mnoha verzemi CMP, ale je méně přesná. Tato vrstva řeší případy, kdy byl CMP přizpůsoben, tematicky upraven nebo běží ve verzi, kterou naše ověřené selektory nepokrývají. Vyměňuje přesnost za pokrytí.

Vrstva 4: Generické heuristiky

Pro 34,7 % bannerů, které nejsou spojeny se známým CMP, se vracíme k heuristické detekci. Skener hledá:

• Fixně nebo sticky pozicované elementy v blízkosti spodní nebo horní části viewportu
• Elementy obsahující klíčová slova související se souhlasem ve více jazycích ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" atd.)
• Tlačítka s běžnými popisky akcí souhlasu ("Accept All", "Reject All", "Manage Preferences" a ekvivalenty)
• Strukturální vzorce typické pro dialogy souhlasu: překryvová pozadí, modální kontejnery, zavírací tlačítka

Tato vrstva zachytí mnoho vlastních implementací, ale je ze své podstaty méně spolehlivá. Fixně pozicovaný propagační banner nebo přihlášení k newsletteru může vypadat strukturálně podobně jako dialog souhlasu.

Vrstva 5: Probing API CMP

Některé CMP vystavují JavaScript API -- především IAB Transparency and Consent Framework (TCF) API přes `__tcfapi`. Tyto API prozkoumáváme jak pro ověření detekce CMP, tak pro přečtení programatického stavu souhlasu, který později porovnáváme s pozorovaným chováním prohlížeče.

Model důvěryhodnosti

Místo toho, abychom detekci považovali za binární (nalezeno/nenalezeno), přiřazujeme skóre důvěryhodnosti na základě toho, které vrstvy odpovídaly a jak silně. Stránka, kde detekujeme skript CMP, odpovídají ověřené selektory a nalezneme TCF API, získá vysokou důvěryhodnost. Stránka, kde se spustily pouze generické heuristiky, získá nižší důvěryhodnost. Toto skóre důvěryhodnosti vstupuje do naší klasifikace rizik -- nižší důvěryhodnost detekce znamená, že zjištění budou s větší pravděpodobností klasifikována jako neprůkazná spíše než definitivní.

Model důvěryhodnosti je důvodem, proč chybná identifikace CMP, ač se vyskytuje, systematicky nezkresluje naše výsledky. Když je detekce nejednoznačná, řekneme to, místo abychom vynucovali klasifikaci.

Výzva 2: Tok odmítnutí -- proč je "klikni a zkontroluj" překvapivě těžké

Testování tlačítka odmítnutí zní jednoduše: najít ho, kliknout na něj, zkontrolovat, zda jsou cookies pryč. V praxi je každý krok plný problémů s časováním, asynchronním chováním a specifiky jednotlivých platforem.

Nalezení tlačítka odmítnutí. Ne všechna tlačítka odmítnutí jsou označena "Odmítnout". Mohou říkat "Decline All", "Refuse", "Only necessary cookies", "Manage settings" (vedoucí do druhé vrstvy, kde je odmítnutí možné) nebo ekvivalenty v desítkách jazyků. Některé CMP umísťují možnost odmítnutí na jiné vizuální místo, v jiné velikosti nebo v jiné barvě než možnost přijetí. Některé ji skrývají za odkaz "Více možností" nebo "Přizpůsobit". Náš skener udržuje vícejazyčnou sadu vzorců akcí odmítnutí a také detekuje možnosti odmítnutí v druhé vrstvě, kde první vrstva nabízí pouze přijetí a přizpůsobení. Čekání na správný okamžik. Po kliknutí na odmítnutí může stránka projít významnými změnami: banner se zavře (často s animací), CMP spustí callbacky stavu souhlasu, tag managery přehodnotí svá pravidla a skripty mohou být načteny nebo odstraněny. Příliš brzká kontrola cookies zachytí přechodový stav. Příliš pozdní kontrola mine přechodné sledování, které se spustí a rychle dokončí. Používáme čekání na více signálů: síťový klid, stabilitu DOM a minimální spodní hranici prodlevy, vyladěnou z empirického testování na stovkách konfigurací CMP. Test opětovného načtení a consent respawn. Krok opětovného načtení je tím, co odhalilo consent respawn jako fenomén. Nehledali jsme ho záměrně -- náš původní test toku odmítnutí kontroloval pouze bezprostřední stav po odmítnutí. Ale během vývoje jsme si všimli stránek, které vypadaly čistě po odmítnutí, ale měly sledovací cookies, když jsme je zkontrolovali znovu po opětovném načtení stránky. Počáteční ladění předpokládalo problém s časováním skeneru. Další vyšetřování potvrdilo, že je to reálné: skripty třetích stran znovu nastavují cookies při načtení stránky bez ohledu na stav souhlasu.

Do pipeline jsme přidali explicitní detekci respawnu: po toku odmítnutí skener znovu načte stránku, počká na stabilitu a porovná inventář cookies se snímkem po odmítnutí. Jakýkoli cookie, který byl odmítnutím odstraněn a po opětovném načtení se znovu objeví, je označen jako respawn. Tím jsme zachytili 1 642 stránek s 4 932 respawnujícími cookies -- zjištění, které by bez kroku opětovného načtení bylo neviditelné.

Poll `waitForScriptIdentifiedCMP`. Některé CMP se načítají asynchronně a nevykreslí svůj banner až několik sekund po prvním načtení stránky. Pokud skener přistoupí ke kroku odmítnutí dříve, než se CMP inicializuje, buď banner úplně mine, nebo interaguje s částečně načteným UI. Implementovali jsme mechanismus pollingu, který čeká na zpřístupnění JavaScript API CMP (např. `__tcfapi` pro CMP založené na TCF, globální proměnná `Cookiebot` pro Cookiebot) před pokračováním. To přidává latenci na sken, ale výrazně snižuje falešně negativní výsledky z asynchronního načítání CMP.

Výzva 3: Saturace pipeline ve velkém měřítku

Skenování 97 304 webových stránek není práce pro jeden stroj. Každý sken spustí proces Chromium, přejde na webovou stránku, zachytí a klasifikuje stovky síťových požadavků, pořídí více snímků obrazovky a spustí analytické moduly. Jeden sken trvá 30-90 sekund v závislosti na složitosti stránky. Při 15 souběžných skenech na worker se správa zdrojů stává primárním inženýrským problémem.

Architektura semaforů

Používáme model souběžnosti založený na semaforech k omezení počtu simultánních procesů Chromium na worker. Každý worker má pevný semafor (15 slotů v naší produkční konfiguraci). Sken získá slot před spuštěním prohlížeče a uvolní jej po dokončení. To zabraňuje vyčerpání paměti -- 15 instancí Chromium s kompletním zachycováním požadavků již spotřebovává značné množství RAM -- a poskytuje zpětný tlak proti frontě Redis.

Výjimka pro požadavek na dokument

Na počátku vývoje jsme narazili na problém s propustností: naše logika zachycování požadavků (která kontroluje každý požadavek z hlediska bezpečnosti SSRF -- blokuje požadavky na privátní rozsahy IP, interní sítě a další potenciálně nebezpečné cíle) přidávala latenci ke každému načtení prostředků, včetně hlavního požadavku na dokument. Protože URL dokumentu je již validována před zahájením skenu, přidali jsme rychlou cestu: požadavky typu dokument na předvalidovanou cílovou URL přeskočí kompletní pipeline zachycování. Tato zdánlivě malá optimalizace měla významný dopad na celkovou propustnost, protože požadavek na dokument blokuje vše ostatní.

DNS pre-warming

První požadavek na novou doménu vyžaduje DNS lookup, který na naší infrastruktuře mohl přidat 50-200 ms na doménu. Při průměrném počtu 10,4 domén třetích stran na stránku (a některých kontaktujících až 171) se čas DNS rozlišení výrazně kumuloval. Implementovali jsme DNS pre-warming pomocí lokální cache DNS resolveru Unbound: před každým skenem rozlišíme cílovou doménu a zahřejeme cache. Instance Unbound poskytuje cachované odpovědi pro následné lookupy v rámci skenu, čímž snižuje režii DNS na doménu pod milisekundu.

Bezpečnost SSRF ve velkém měřítku

Každý požadavek zachycený skenerem je před povolením pokračování kontrolován proti sadě bezpečnostních pravidel. Požadavky na privátní rozsahy IP (RFC 1918, RFC 4193, link-local, loopback) jsou blokovány. To zabraňuje tomu, aby škodlivá cílová stránka použila skener jako SSRF vektor k prozkoumání interních sítí.

Výzvou ve velkém měřítku bylo rozlišení skutečných blokací SSRF od saturace semaforů. Když je všech 15 slotů semaforu využito a sken nemůže získat slot, výsledný timeout vypadá povrchně podobně jako požadavek blokovaný z bezpečnostních důvodů. Přidali jsme explicitní kategorizaci chyb pro rozlišení "blokováno, protože cíl se rozlišil na privátní IP" od "blokováno, protože skener je na plné kapacitě". To bylo nezbytné pro operační monitoring a přesnou klasifikaci selhání skenů.

Výzva 4: Detekce vyhýbání se botům

Během studie jsme identifikovali 137 webových stránek, které zřejmě záměrně skrývají svůj consent banner před automatizovanými skenery. Banner je doručen lidským návštěvníkům, ale potlačen, když stránka detekuje charakteristiky automatizovaného prohlížení.

Nejčastější mechanismus, který jsme identifikovali, zahrnuje konfigurační volbu `isAcceptAllForBots` WordPress pluginu RCB (Real Cookie Banner). Při zapnutí toto nastavení detekuje automatizované prohlížeče (přes `navigator.webdriver`, heuristiky user-agent nebo behaviorální signály) a buď automaticky přijme souhlas jejich jménem, nebo banner úplně skryje. Záměrem, jak uvádí dokumentace pluginu, je zabránit automatizovaným návštěvníkům v zobrazení dialogu souhlasu, se kterým nemohou smysluplně interagovat. Efektem je, že skenery dodržování předpisů -- a regulační auditoři používající automatizované nástroje -- vidí stránku, která se zdá nemít žádný mechanismus souhlasu, zatímco lidští návštěvníci vidí kompletní consent banner.

To je problém transparentnosti. Pokud je mechanismus souhlasu webové stránky viditelný pouze pro lidské návštěvníky, nelze jej auditovat ve velkém měřítku. Tyto stránky v našich výsledcích označujeme samostatně, protože zjištění je kvalitativně odlišné od "banner nebyl detekován". Stránka má banner; rozhodla se nám ho neukázat.

Vyhýbání se botům detekujeme kombinací signálů: přítomnost známé konfigurace detekce botů v nastavení CMP (dostupná přes inspekci JavaScriptu), nesrovnalosti mezi tím, co DOM ukazuje, a tím, co API CMP hlásí, a v některých případech porovnáním výsledků automatizovaného skenu s manuálním ověřením.

Číslo 137 je určitě podhodnocením. Vyhýbání se botům můžeme detekovat pouze tehdy, když dokážeme identifikovat mechanismus. Stránky používající sofistikovanější nebo vlastní detekci botů mohou úspěšně uniknout jak našemu skeneru, tak naší detekci vyhýbání.

Výzva 5: Chybná identifikace CMP

Stránka může načítat více skriptů, které vypadají jako platformy pro správu souhlasu. PiwikPRO zahrnuje komponentu CMP, ale je primárně analytickou sadou. Některé stránky WordPress načítají Complianz spolu se samostatným analytickým pluginem, který má funkce podobné CMP. Firemní stránky mohou mít pozůstatky předchozího CMP stále se načítající vedle aktuálního.

Naivní detekce -- "pokud vidíme skript, je to CMP" -- produkuje falešné identifikace, které se kaskádují do nesprávné interakce s bannerem. Pokud skener identifikuje PiwikPRO jako CMP a pokusí se použít selektory banneru PiwikPRO, může minout skutečný banner tarteaucitron, který na stránce ovládá souhlas.

Náš přístup založený na důvěryhodnosti toto řeší řazením kandidátů CMP. Když je detekováno více potenciálních CMP:

1. Kontrolujeme, který má viditelný banner v DOM (skript přítomen, ale žádný banner znamená pravděpodobně neaktivní nebo ne-CMP použití).

2. Kontrolujeme, který vystavuje aktivní CMP API (např. funkční `__tcfapi` nebo ekvivalent).

3. Upřednostňujeme CMP, jehož ověřené selektory odpovídají viditelným elementům DOM, před tím, který je detekován pouze URL skriptu.

Tato heuristika není dokonalá, ale vyřešila nejčastější případy chybné identifikace, na které jsme narazili během vývoje a testování.

Omezení

Žádný automatizovaný skener dokonale nereplikuje každou lidskou zkušenost s prohlížením. Toto jsou známá omezení:

Bannery závislé na GeoIP. Některé CMP, zejména CookieYes, doručují různé zkušenosti se souhlasem na základě IP geolokace návštěvníka. Naše skeny pocházejí ze specifických síťových lokací v Evropě. Stránka, která zobrazuje consent banner návštěvníkům z Francie, ale ne návštěvníkům ze zemí mimo EU, zobrazí různé výsledky v závislosti na původu skenu. V současnosti neskenujeme každou stránku z každé země EU. Uzavřený shadow DOM. Některé CMP vykreslují svůj banner uvnitř uzavřeného shadow DOM, který je nepřístupný standardním DOM dotazům přes `document.querySelector`. CMP od Transcend používá tento přístup. Náš skener může detekovat hostitelský element shadow, ale nemůže prozkoumat jeho obsah k nalezení tlačítek přijetí/odmítnutí. Tyto stránky obvykle skončí v našich výsledcích jako neprůkazné. Dynamické názvy tříd a obfuskace. Některé CMP, zejména Admiral, používají dynamicky generované názvy tříd, které se mění při každém načtení stránky. Detekce založená na selektorech u nich selhává, protože selektory nejsou stabilní napříč návštěvami. Vracíme se ke generickým heuristikám, ale důvěryhodnost je nižší. Jednostránkové aplikace. SPA, které spravují stav souhlasu výhradně v JavaScriptu na straně klienta a načítají mechanismus souhlasu po počátečních změnách trasy (spíše než při počátečním načtení stránky), je obtížnější posoudit. Náš skener přejde na URL a čeká na stabilizaci stránky, ale nesimuluje navigaci uvnitř aplikace. Consent banner, který se objeví až poté, co uživatel naviguje v rámci SPA, může být opomenut. Jazykové pokrytí. Naše detekce tlačítka odmítnutí využívá párování textu napříč sadou podporovaných jazyků, ale nepokrýváme všechny jazyky EU rovnoměrně. Banner v maltštině nebo estonštině může mít popisky tlačítka odmítnutí, které naše párování textu nerozpozná, což vede k vynechání testování toku odmítnutí (ačkoli samotný banner může být stále detekován strukturálními heuristikami). Okrajové případy časování. Skript, který se spustí 30 sekund po načtení stránky, bude opomenut skenem, který čeká 15 sekund na síťový klid. Používáme velkorysé timeouty, ale dlouhý konec asynchronního chování je ze své podstaty obtížné kompletně zachytit.

Tato omezení přispívají k naší 14,9% míře neprůkazných výsledků.

Infrastruktura

Produkční skenovací infrastruktura se skládá z:

• Skenovací engine: Aplikace v Go používající chromedp jako CDP klient pro automatizaci Chromium. Go bylo zvoleno pro svůj model souběžnosti (goroutines a kanály se přirozeně mapují na paralelní orchestraci skenů), své výkonnostní charakteristiky a jednoduchost nasazení (jeden statický binární soubor).
• Runtime prohlížeče: Headless Chromium spouštěný per-sken přes CDP. Každý sken dostane čerstvý proces prohlížeče s nulovým sdíleným stavem.
• Fronta: Pracovní fronta podporovaná Redis distribující URL do skenovacích workerů. Redis řeší distribuci úloh, sledování průběhu a rate limiting.
• Databáze: PostgreSQL pro trvalé výsledky skenů, zjištění, metadata důkazů a všechna strukturovaná data. Skeny, zjištění, cookies, požadavky a výstupy analýz jsou uloženy relačně.
• DNS cache: Lokální Unbound resolver poskytující cachované DNS lookupy a rozlišení bezpečné z hlediska SSRF.
• Úložiště důkazů: Snímky obrazovky, soubory HAR a PDF reporty jsou ukládány jako trvalé artefakty propojené se záznamy skenů.

Pro studii 97 304 stránek jsme zpracovali 114 748 kandidátních URL (97 304 úspěšně dokončeno) za přibližně 2,5 dne pomocí 3 serverových instancí běžících paralelně s pracovními procesy skeneru. Každý server běžel s více pracovními procesy s 15 souběžnými skenovacími sloty. Špičková propustnost byla přibližně 25-30 dokončených skenů za minutu na server.

Primárním úzkým hrdlem nebyl CPU ani paměť, ale síť: každý sken generuje stovky odchozích požadavků (na cílovou stránku a její zdroje třetích stran) a agregátní šířka pásma a počet spojení napříč všemi souběžnými skeny nasytily dostupnou síťovou kapacitu dříve, než byly vyčerpány ostatní zdroje.

Otevřené výzvy a budoucí práce

Několik problémů zůstává nevyřešených nebo částečně vyřešených:

Lokalizace consent banneru. Naše párování textu pokrývá hlavní jazyky EU, ale je neúplné pro menší jazykové komunity. Rozšíření pokrytí vyžaduje nejen přidání překladů, ale validaci, že selektory a vzorce interakce fungují správně s lokalizovanými verzemi CMP. Longitudinální monitoring. Naše současná architektura je optimalizovaná pro bodové skenování v čase. Detekce změn v chování souhlasu v průběhu času -- zlepšila se stránka po vymáhání? Opravila aktualizace CMP třídu selhání toku odmítnutí? -- vyžaduje opakované skeny s diferenční analýzou, což je architektonicky odlišné od jednorázového posouzení. Benchmarking dodržování podle CMP. Máme data k posouzení míry dodržování na CMP (je Cookiebot spojen s lepším dodržováním než OneTrust?), ale oddělení kvality CMP od kvality konfigurace provozovatelem stránky je metodologicky složité. CMP, který je častěji nasazován velkými podniky s dedikovanými týmy pro ochranu soukromí, bude v agregátu vypadat lépe, i když samotný nástroj není o nic víc v souladu. Ověření stavu souhlasu v reálném čase. Současný skener funguje v dávkovém režimu. Integrace ověření souhlasu do CI/CD pipeline nebo monitoringu v reálném čase vyžaduje rychlejší, lehčí režim skenování, který obětuje určitou hloubku důkazů za rychlost. Toto zkoumáme.

API

Stejný skenovací engine popsaný v tomto příspěvku je dostupný přes veřejné API GDPR Monitoru. Můžete programaticky odesílat požadavky na skeny, dotazovat se na výsledky a získávat strukturovaná zjištění a důkazní artefakty. API vrací stejná data, která zobrazuje naše uživatelské rozhraní: snímky před souhlasem, inventáře cookies, výsledky detekce CMP, výsledky toku odmítnutí, riziková skóre a kompletní řetězce důkazů.

Pokud budujete nástroje pro dodržování předpisů, integrujete kontroly soukromí do CI/CD pipeline, provádíte vlastní výzkum nebo zabudováváte monitoring do programu ochrany soukromí, API poskytuje přístup k behaviorální analýze souhlasu bez nutnosti budovat a udržovat vlastní infrastrukturu automatizace Chromium.

---

Vyzkoušejte sami. API dokumentace je dostupná na gdprprivacymonitor.eu/developers/api. Odešlete jednu URL nebo integrujte automatizovaný monitoring soukromí do svého pracovního postupu.