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

Automatiseret kontrol af samtykke-compliance lyder ligetil, indtil man forsoger at bygge det. Den naive tilgang -- hent en side, tjek for cookies, kig efter et banner -- overser det meste af det, der har betydning. Samtykkeovertraedelser er adfaerdsmaessige, ikke strukturelle. De manifesterer sig i timingen af scriptudforelse, raekkefolgen af netvaerksanmodninger, UI-elementers respons pa brugerinteraktion og statens vedholdenhed pa tvaers af sideindlaesninger. Man kan ikke vurdere noget af dette uden at kore en rigtig browser, interagere med siden som et menneske ville, og registrere hvad der faktisk sker pa netvaerksniveau.

Dette indlaeg beskriver, hvordan vi byggede scanningmotoren bag GDPR Monitor, de tekniske udfordringer der opslugte det meste af vores tid, de arkitekturmaessige beslutninger vi traf og hvorfor, samt de begraensninger vi er aerlige omkring. Hvis du arbejder med webcompliance, browserautomatisering eller storstilet webmaling, burde der vaere noget nyttigt her.

Pipelineoversigten

Hver scanning passerer gennem seks stadier. At forsta pipelinen er nodvendig kontekst for de specifikke udfordringer, der folger.

Stadie 1: Browserstart og isolering. En frisk Chromium-instans starter med nul tilstand -- ingen cookies, ingen localStorage, ingen cache, ingen service workers. Dette er den renrumsgaranti, der gor maling for samtykke meningsfuld. Vi konfigurerer en standard viewport, realistisk user-agent og Accept-Language-headers matchende mallandet samt standardbrowserflag. Hver scanning far sin egen browserproces; der er ingen tilstandslaekage mellem scanninger. Stadie 2: Navigation og snapshot for samtykke. Scanneren navigerer til mal-URL'en, venter pa at siden nar en stabil tilstand (netvaerk inaktivt, DOM afgjort) og fanger alt, hvad der er sket: cookies sat, netvaerksanmodninger foretaget (med fuld URL, timing og svarmetadata), tredjepartsdomaener kontaktet og et helsidesskraermbillede. Dette snapshot besvarer det grundlaeggende sporgsmal: hvad gjorde denne hjemmeside, for brugeren overhovedet havde mulighed for at give samtykke? Stadie 3: CMP-detektion og banneridentifikation. Scanneren forsoger at identificere samtykkeplatformen og lokalisere samtykkebanneret, acceptknappen og afvisningsknappen. Dette bruger et lagdelt detektionssystem, der beskrives i detaljer nedenfor. Stadie 4: Samtykkeinteraktion. Scanneren interagerer med banneret -- klikker accept for standardflowet, klikker afvis for testen af afvisningsflowet. Den venter pa, at siden falder til ro efter interaktion, under hensyntagen til animationer, scriptgenevaluering og forsinket tagaffyring. Stadie 5: Snapshot efter samtykke og differentiel analyse. Et andet komplet snapshot fanger tilstanden efter samtykkeinteraktion. Sammenligning af snapshots for og efter samtykke afslorer, hvad der aendrede sig: nye cookies, nye sporingsanmodninger, samtykkestatus i CMP-API'er. Stadie 6: Analyse, klassifikation og rapportgenerering. Ra data fodes ind i analysemoduler: cookieklassifikation mod vores database, trackermatchning mod kendte monstre, evaluering af cookielevetid, tilgaengelighedsaudit af banneret, Google Consent Mode-validering, fingeraftryksignaldetektion og risikoscoring. Outputtet er en struktureret rapport med fund, bevismateriale og en sammensat risikoscore.

Hvert stadie producerer tidsstemplet bevismateriale, der lagres varigt. Ethvert fund kan spores tilbage til specifikke netvaerksanmodninger, cookie-poster eller skraermbilleder.

Udfordring 1: CMP-detektion -- 45 platforme, uendelige variationer

Samtykkehandtering er ikke standardiseret. Der er ingen universel HTML-attribut, ingen obligatorisk JavaScript-API, ingen konsistent DOM-struktur, der siger "dette er et samtykkebanner." Der er 45 distinkte CMP'er i vores detektionsbibliotek, hver med sin egen DOM-struktur, scriptsignaturer, JavaScript-globale variabler og interaktionsmonstre. Udover disse var 34,7 % af de bannere, vi detekterede i vores undersogelse af 97.304 sider, generiske eller uidentificerede -- tilpassede implementeringer, regionale leverandorer eller minimale losninger, der ikke matcher nogen kendt CMP-signatur.

Vores detektion bruger en tillidsbaseret, lagdelt tilgang:

Lag 1: Scriptsignaturdetektion

Scanneren tjekker for tilstedevaerelsen af kendte CMP-scripts efter URL-monster og JavaScript-globale variabler. Cookiebot indlaeser for eksempel fra `consent.cookiebot.com` og eksponerer `window.Cookiebot`. OneTrust indlaeser fra `cdn.cookielaw.org` og eksponerer `window.OneTrust`. Hver CMP har karakteristiske indlaesningsmonstre, der kan detekteres, for man undersoger DOM'en.

Dette lag er hurtigt og har hoj tillid, nar det matcher. Men det har en kritisk begraensning: det fortaeller dig, hvilken CMP der er til stede pa siden, ikke nodvendigvis hvilken CMP der er ansvarlig for samtykkebanneret. En side kan indlaese PiwikPRO til analyse (som inkluderer en CMP-komponent), mens den bruger tarteaucitron til faktisk samtykkehandtering. At detektere begge scripts er let; at vide hvilken der kontrollerer banneret er svaerere.

Lag 2: Verificeret selektormatchning

For hver kendt CMP vedligeholder vi et kurateret saet CSS-selektorer, der palideligt identificerer bannercontaineren, acceptknappen og afvisningsknappen. Disse er selektorer, vi har valideret pa tvaers af flere versioner og konfigurationer af hver CMP. Nar en CMP detekteres i lag 1, og dens verificerede selektorer matcher elementer i DOM'en, har vi hoj tillid til bade CMP-identifikationen og bannerinteraktionsmalene.

Lag 3: Kompatibel selektormatchning

Et bredere saet selektorer, der fungerer pa tvaers af mange versioner af en CMP, men er mindre praecise. Disse handterer tilfaelde, hvor en CMP er blevet tilpasset, tematiseret eller korer en version, der ikke er daekket af vores verificerede selektorer. De bytter praecision for daekning.

Lag 4: Generiske heuristikker

For de 34,7 % af bannere, der ikke er forbundet med en kendt CMP, falder vi tilbage til heuristisk detektion. Scanneren kigger efter:

• Fastpositionerede eller sticky-positionerede elementer naer bunden eller toppen af viewporten
• Elementer der indeholder samtykkerelaterede nogleord pa flere sprog ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" osv.)
• Knapper med almindelige samtykkehandlingslabels ("Accept All", "Reject All", "Manage Preferences" og aekvivalenter)
• Strukturelle monstre typiske for samtykkedialoger: overlay-baggrunde, modale containere, luk-knapper

Dette lag fanger mange tilpassede implementeringer, men er iboende mindre palideligt. Et fastpositioneret kampagnebanner eller nyhedsbrevstilmelding kan ligne en samtykkedialog strukturelt.

Lag 5: CMP API-probing

Nogle CMP'er eksponerer JavaScript-API'er -- mest bemaerkelsesvaerdigt IAB Transparency and Consent Framework (TCF) API via `__tcfapi`. Vi prober for disse API'er for bade at verificere CMP-detektion og laese den programmatiske samtykkestatus, som vi senere sammenligner med observeret browseradfaerd.

Tillidsmodellen

I stedet for at behandle detektion som binaer (fundet/ikke fundet) tildeler vi tillidsscore baseret pa, hvilke lag der matchede, og hvor staerkt. En side, hvor vi detekterer et CMP-script, matcher verificerede selektorer og finder en TCF API, far hoj tillid. En side, hvor kun generiske heuristikker slog ud, far lavere tillid. Denne tillidsscore fodes ind i vores risikoklassifikation -- lavere detektionstillid betyder, at fund er mere tilbojelige til at blive klassificeret som inkonklusive frem for definitive.

Tillidsmodellen er grunden til, at CMP-fejlidentifikation, selvom den forekommer, ikke systematisk skaevvrider vores resultater. Nar detektionen er tvetydig, siger vi det, i stedet for at tvinge en klassifikation.

Udfordring 2: Afvisningsflowet -- hvorfor "klik og tjek" er overraskende svaert

At teste en afvisningsknap lyder simpelt: find den, klik pa den, tjek om cookies er vaek. I praksis er hvert trin plaget af timingproblemer, asynkron adfaerd og platformspecifikke saerheder.

At finde afvisningsknappen. Ikke alle afvisningsknapper er maerket "Afvis". De kan sige "Decline All", "Refuse", "Only necessary cookies", "Manage settings" (der forer til et andet lag, hvor afvisning er mulig) eller aekvivalenter pa et vilkarligt antal sprog. Nogle CMP'er placerer afvisningsmuligheden pa en anden visuel placering, i en anden storrelse eller i en anden farve end acceptmuligheden. Nogle skjuler den bag et "More options"- eller "Customize"-link. Vores scanner vedligeholder et flersproget saet af afvisningshandlingsmonstre og detekterer ogsa afvisningsmuligheder i andet lag, hvor forste lag kun tilbyder accept og tilpasning. At vente pa det rette ojeblik. Efter klik pa afvis kan siden gennemga betydelige aendringer: banneret forsvinder (ofte med animation), CMP'en affyrer samtykkestatuscallbacks, tag managere genevaluerer deres regler, og scripts kan blive indlaest eller fjernet. At tjekke cookies for tidligt fanger mellemtilstanden. At tjekke for sent overser forbigaende sporing, der affyrer og afsluttes hurtigt. Vi bruger en multisignalventetid: netvaerksinaktivitet, DOM-stabilitet og et minimumsforsinkelsesgrundlag, afstemt fra empirisk testning pa tvaers af hundredvis af CMP-konfigurationer. Genindlaesningstesten og consent respawn. Genindlaesningstrinnet var det, der afslorede consent respawn som et faenomen. Vi satte ikke ud for at finde det -- vores oprindelige test af afvisningsflowet tjekede kun den umiddelbare tilstand efter afvisning. Men under udviklingen bemaerkede vi sider, der sa rene ud efter afvisning, men havde sporingscookies, nar vi tjekkede igen efter en sidegenindlaesning. Indledende fejlfinding antog et timingproblem i scanneren. Yderligere undersogelse bekraeftede, at det var virkeligt: tredjepartsscripts der gensatte cookies ved sideindlaesning uanset samtykkestatus.

Vi tilfoejede eksplicit respawndetektion til pipelinen: efter afvisningsflowet genindlaeser scanneren siden, venter pa stabilitet og sammenligner cookieoversigten med snapshot efter afvisning. Enhver cookie, der blev fjernet ved afvisning og dukker op igen efter genindlaesning, markeres som en respawn. Dette fangede 1.642 sider med 4.932 respawnende cookies -- et fund der ville have vaeret usynligt uden genindlaesningstrinnet.

`waitForScriptIdentifiedCMP`-pollingen. Nogle CMP'er indlaeser asynkront og renderer ikke deres banner, for flere sekunder efter den indledende sideindlaesning. Hvis scanneren fortsaetter til afvisningstrinnet, for CMP'en er initialiseret, overser den enten banneret helt eller interagerer med en delvist indlaest brugerflade. Vi implementerede en pollingmekanisme, der venter pa, at CMP'ens JavaScript-API bliver tilgaengelig (f.eks. `__tcfapi` for TCF-baserede CMP'er, `Cookiebot`-global for Cookiebot), for den fortsaetter. Dette tilfojer latenstid pr. scanning, men reducerer markant falske negativer fra asynkron CMP-indlaesning.

Udfordring 3: Pipelinemaetning i stor skala

At scanne 97.304 hjemmesider er ikke et job for en maskine. Hver scanning starter en Chromium-proces, navigerer til en hjemmeside, opfanger og klassificerer hundredvis af netvaerksanmodninger, tager flere skraermbilleder og korer analysemoduler. En enkelt scanning tager 30-90 sekunder afhaengigt af sidens kompleksitet. Ved 15 samtidige scanninger pr. worker bliver ressourcestyring den primaere tekniske bekymring.

Semaforarkitekturen

Vi bruger en semaforbaseret samtidighedsmodel til at begraense antallet af samtidige Chromium-processer pr. worker. Hver worker har en fast semafor (15 pladser i vores produktionskonfiguration). En scanning erhverver en plads, for den starter sin browser, og frigiver den ved afslutning. Dette forhindrer hukommelsesudmattelse -- 15 Chromium-instanser med fuld anmodningsopfangning forbruger allerede betydelig RAM -- og giver modtryk mod Redis-koen.

Undtagelsen for dokumentanmodninger

Tidligt i udviklingen stodte vi pa et gennemlobsproblem: vores logik til anmodningsopfangning (der inspicerer hver anmodning for SSRF-sikkerhed -- blokerer anmodninger til private IP-intervaller, interne netvaerk og andre potentielt farlige mal) tilfoejede latenstid til hver ressourceindlaesning, inklusive hoveddokumentanmodningen. Da dokument-URL'en allerede er valideret, for scanningen begynder, tilfoejede vi en hurtigvejsomgaelse: anmodninger af dokumenttype til den forvaliderede mal-URL springer den fulde opfangningspipeline over. Denne tilsyneladende lille optimering havde en betydelig indvirkning pa den samlede gennemstromning, fordi dokumentanmodningen blokerer alt andet.

DNS-forvarmning

Den forste anmodning til et nyt domaene medforer et DNS-opslag, som pa vores infrastruktur kunne tilfoeje 50-200 ms pr. domaene. Med det gennemsnitlige site, der kontakter 10,4 tredjepartsdomaener (og nogle op til 171), akkumulerede DNS-oplosningstiden sig betydeligt. Vi implementerede DNS-forvarmning ved hjaelp af en lokal Unbound DNS-resolvercache: for hver scanning oploser vi maldomaenet og varmer cachen. Unbound-instansen serverer cachede svar for efterfolgende opslag inden for scanningen, hvilket reducerer DNS-overhead pr. domaene til under et millisekund.

SSRF-sikkerhed i stor skala

Hver anmodning opfanget af scanneren kontrolleres mod et saet sikkerhedsregler, for den tillades at fortsaette. Anmodninger til private IP-intervaller (RFC 1918, RFC 4193, link-local, loopback) blokeres. Dette forhindrer en ondsindet malside i at bruge scanneren som en SSRF-vektor til at probe interne netvaerk.

Udfordringen i stor skala var at skelne aegte SSRF-blokeringer fra semaforsaturation. Nar alle 15 semaforpladser er i brug, og en scanning ikke kan erhverve en plads, ligner den resulterende timeout overfladisk en anmodning, der blokeres af sikkerhedshensyn. Vi tilfoejede eksplicit fejlkategorisering for at skelne "blokeret fordi malet oploste til en privat IP" fra "blokeret fordi scanneren er pa kapacitet." Dette var essentielt for driftsovervaagning og for praecis klassifikation af scanningsfejl.

Udfordring 4: Detektion af botundvigelse

Under undersogelsen identificerede vi 137 hjemmesider, der tilsyneladende bevidst skjuler deres samtykkebanner for automatiserede scannere. Banneret vises til menneskelige besoegende, men underttrykkes, nar siden detekterer kendetegn ved automatiseret browsing.

Den mest almindelige mekanisme, vi identificerede, involverer RCB (Real Cookie Banner) WordPress-pluginnets `isAcceptAllForBots`-konfigurationsindstilling. Nar den er aktiveret, detekterer denne indstilling automatiserede browsere (via `navigator.webdriver`, user-agent-heuristikker eller adfaerdssignaler) og enten automatisk accepterer samtykke pa deres vegne eller skjuler banneret helt. Intentionen, som dokumenteret af pluginnet, er at forhindre automatiserede besoegende i at blive praesenteret for en samtykkedialog, de ikke meningsfuldt kan interagere med. Effekten er, at compliancescannere -- og tilsynsmyndigheder, der bruger automatiserede vaerktoejer -- ser en side, der tilsyneladende ikke har nogen samtykkemekanisme, mens menneskelige besoegende ser et fuldt samtykkebanner.

Dette er et gennemsigtighedsproblem. Hvis en hjemmesides samtykkemekanisme kun er synlig for menneskelige besoegende, kan den ikke auditeres i stor skala. Vi markerer disse sider separat i vores resultater, fordi fundet er kvalitativt anderledes end "intet banner detekteret." Siden har et banner; den vaelger at skjule det for os.

Vi detekterer botundvigelse gennem en kombination af signaler: tilstedevaerelsen af kendt botdetektionskonfiguration i CMP-indstillinger (tilgaengelig via JavaScript-inspektion), uoverensstemmelser mellem hvad DOM'en viser og hvad CMP'ens API rapporterer, og i nogle tilfaelde ved at sammenligne automatiserede scanningsresultater med manuel verifikation.

Tallet 137 er bestemt et underestimat. Vi kan kun detektere botundvigelse, nar vi kan identificere mekanismen. Sider, der bruger mere sofistikeret eller tilpasset botdetektion, kan med succes undvige bade vores scanner og vores undvigelsesdetektion.

Udfordring 5: CMP-fejlidentifikation

En side kan indlaese flere scripts, der ligner samtykkeplatforme. PiwikPRO inkluderer en CMP-komponent, men er primaert en analysesuite. Nogle WordPress-sider indlaeser Complianz sammen med et separat analyseplugin, der har CMP-lignende funktioner. Enterprise-sider kan have rester af en tidligere CMP, der stadig indlaeser ved siden af den nuvaerende.

Naiv detektion -- "hvis vi ser scriptet, er det CMP'en" -- producerer fejlidentifikationer, der kaskaderer til forkert bannerinteraktion. Hvis scanneren identificerer PiwikPRO som CMP'en og forsoger at bruge PiwikPRO's bannerselektorer, kan den overse det faktiske tarteaucitron-banner, der kontrollerer samtykke pa siden.

Vores tillidsbaserede tilgang adresserer dette ved at rangere CMP-kandidater. Nar flere potentielle CMP'er detekteres:

1. Vi tjekker, hvilken der har et synligt banner i DOM'en (script til stede men intet banner betyder sandsynligvis inaktiv eller ikke-CMP-brug).

2. Vi tjekker, hvilken der eksponerer en aktiv CMP-API (f.eks. en fungerende `__tcfapi` eller tilsvarende).

3. Vi foretraekker den CMP, hvis verificerede selektorer matcher synlige DOM-elementer, frem for den, der kun detekteres af script-URL.

Denne heuristik er ikke perfekt, men den loste de mest almindelige tilfaelde af fejlidentifikation, vi stodte pa under udvikling og testning.

Begraensninger

Ingen automatiseret scanner replikerer perfekt enhver menneskelig browsingoplevelse. Dette er de kendte begraensninger:

GeoIP-afhaengige bannere. Nogle CMP'er, bemaerkelsesvaerdigt CookieYes, serverer forskellige samtykkeoplevelser baseret pa besoegendes IP-geolokation. Vores scanninger stammer fra specifikke netvaerksplaceringer i Europa. En side, der viser et samtykkebanner til besoegende fra Frankrig, men ikke til besoegende uden for EU, vil vise forskellige resultater afhaengigt af scanningens oprindelse. Vi scanner i ojeblikket ikke hver side fra hvert EU-land. Lukket shadow DOM. Nogle CMP'er renderer deres banner inde i en lukket shadow DOM, som er utilgaengelig for standard DOM-foresporgsler via `document.querySelector`. Transcends CMP bruger denne tilgang. Vores scanner kan detektere shadow host-elementet, men kan ikke inspicere dets indhold for at finde accept-/afvisningsknapper. Disse sider ender typisk som inkonklusive i vores resultater. Dynamiske klassenavne og obfuskering. Nogle CMP'er, bemaerkelsesvaerdigt Admiral, bruger dynamisk genererede klassenavne, der aendrer sig ved hver sideindlaesning. Selektorbaseret detektion fejler for disse, fordi selektorerne ikke er stabile pa tvaers af besog. Vi falder tilbage til generiske heuristikker, men tilliden er lavere. Single-page applications. SPA'er, der handterer samtykkestatus helt i client-side JavaScript og indlaeser samtykkemekanismen efter indledende ruteaendringer (i stedet for ved indledende sideindlaesning), er svaerere at vurdere. Vores scanner navigerer til URL'en og venter pa, at siden stabiliserer sig, men den simulerer ikke in-app-navigation. Et samtykkebanner, der kun vises, efter brugeren navigerer inden for SPA'en, kan blive overset. Sprogdaekning. Vores detektion af afvisningsknapper bruger tekstmatchning pa tvaers af et saet understottede sprog, men vi daekker ikke alle EU-sprog lige godt. Et banner pa maltesisk eller estisk kan have afvisningsknaplabels, som vores tekstmatchning ikke genkender, hvilket forer til en misset test af afvisningsflow (selvom selve banneret stadig kan detekteres af strukturelle heuristikker). Timing-graensetilfaelde. Et script, der affyrer 30 sekunder efter sideindlaesning, vil blive overset af en scanning, der venter 15 sekunder pa netvaerksinaktivitet. Vi bruger generoese timeouts, men den lange hale af asynkron adfaerd er iboende vanskelig at fange fuldstaendigt.

Disse begraensninger bidrager til vores inkonklusive rate pa 14,9 %.

Infrastrukturen

Produktionsscanninginfrastrukturen bestar af:

• Scanningmotor: En Go-applikation, der bruger chromedp som CDP-klient til Chromium-automatisering. Go blev valgt for sin samtidighedsmodel (goroutines og channels mapper naturligt pa parallel scanningorkestrering), sine ydelseskarakteristika og sin enkelhed i deployment (enkelt statisk binaer).
• Browserruntime: Headless Chromium startet pr. scanning via CDP. Hver scanning far en frisk browserproces med nul delt tilstand.
• Ko: Redis-backed arbejdsko, der distribuerer URL'er til scannerworkere. Redis handterer jobdistribution, fremdriftssporing og hastighedsbegraensning.
• Database: PostgreSQL til varig lagring af scanningsresultater, fund, bevismetadata og alle strukturerede data. Scanninger, fund, cookies, anmodninger og analyseoutputs lagres alle relationelt.
• DNS-cache: Lokal Unbound-resolver, der leverer cachede DNS-opslag og SSRF-sikker oplosning.
• Bevislagring: Skraermbilleder, HAR-filer og PDF-rapporter lagres som varige artefakter knyttet til scanningsposter.

For undersogelsen af 97.304 sider behandlede vi 114.748 kandidat-URL'er (97.304 gennemfort med succes) over cirka 2,5 dage ved brug af 3 serverinstanser, der korte scannerworkere parallelt. Hver server korte flere workerprocesser med 15 samtidige scanningspladser hver. Spidsgennemstromningen var ca. 25-30 afsluttede scanninger pr. minut pr. server.

Den primaere flaskehals var ikke CPU eller hukommelse, men netvaerk: hver scanning genererer hundredvis af udgaende anmodninger (til malsiden og dens tredjepartsressourcer), og den samlede bandbredde og forbindelsesantal pa tvaers af alle samtidige scanninger maettede den tilgaengelige netvaerkskapacitet, for andre ressourcer var opbrugt.

Abne udfordringer og fremtidigt arbejde

Flere problemer forbliver uloste eller delvist loste:

Lokalisering af samtykkebannere. Vores tekstmatchning daekker store EU-sprog, men er ufuldstaendig for mindre sprogfaellesskaber. Udvidelse af daekningen kraever ikke kun tilfoejelse af oversaettelser, men validering af, at selektorerne og interaktionsmonstrene fungerer korrekt med lokaliserede CMP-versioner. Longitudinel overvaagning. Vores nuvaerende arkitektur er optimeret til scanning pa et enkelt tidspunkt. At detektere aendringer i samtykkeadfaerd over tid -- forbedrede en side sig efter handhaevelse? Rettede en CMP-opdatering en klasse af fejl i afvisningsflow? -- kraever gentagne scanninger med differentiel analyse, hvilket er arkitektonisk anderledes end engangsvurdering. CMP-compliancebenchmarking. Vi har dataene til at vurdere compliancerater pr. CMP (er Cookiebot forbundet med bedre compliance end OneTrust?), men at adskille CMP-kvalitet fra sideoperatorens konfigurationskvalitet er metodologisk komplekst. En CMP, der oftere er installeret af store virksomheder med dedikerede privatlivsteams, vil se bedre ud samlet set, selvom selve vaerktoejet ikke er mere compliant. Realtidsverifikation af samtykkestatus. Den nuvaerende scanner opererer i batchtilstand. At integrere samtykkeverifikation i CI/CD-pipelines eller realtidsovervaagning kraever en hurtigere, lettere scanningstilstand, der ofrer noget bevisdybde for hastighed. Vi udforsker dette.

API'en

Den samme scanningmotor beskrevet i dette indlaeg er tilgaengelig gennem GDPR Monitors offentlige API. Du kan indsende scanningsanmodninger programmatisk, polle efter resultater og hente strukturerede fund og bevisartefakter. API'en returnerer de samme data, som vores UI viser: snapshots for samtykke, cookieoversigter, CMP-detektionsresultater, resultater af afvisningsflow, risikoscorer og komplette beviskaeder.

Hvis du bygger compliancevaerktoejer, integrerer privatlivstjek i CI/CD-pipelines, udforer din egen forskning eller bygger overvaagning ind i et privatlivsprogram, giver API'en adgang til adfaerdsmaessig samtykkeanalyse uden behovet for at bygge og vedligeholde din egen Chromium-automatiseringsinfrastruktur.

---

Prov det selv. API-dokumentation er tilgaengelig pa gdprprivacymonitor.eu/developers/api. Indsend en enkelt URL eller integrer automatiseret privatlivsovervaagning i din arbejdsgang.