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

Automatiserad kontroll av samtyckesefterlevnad later enkelt tills du forsoker bygga det. Det naiva tillvagagångssättet -- hamta en sida, kontrollera cookies, leta efter en banderoll -- missar det mesta av det som spelar roll. Samtyckesoverträdelser ar beteendemassiga, inte strukturella. De manifesteras i timing av skriptkorning, sekvensen av natverksforfragar, svaret fran UI-element pa användarinteraktion och bestäendet av tillstand over sidladdningar. Du kan inte bedoma nagot av detta utan att kora en riktig webblasare, interagera med sidan som en manniska skulle gora och registrera vad som faktiskt hander pa natverksniva.

Det har inlagget beskriver hur vi byggde skannningsmotorn bakom GDPR Monitor, de tekniska utmaningar som tog mest av var tid, de arkitekturella beslut vi fattade och varfor, samt de begransningar vi ar arliga om. Om du arbetar med webbefterlevnad, webblasarautomation eller storskalig webbmatning bor det finnas nagot anvandbart har.

Pipelineoversikt

Varje skanning passerar genom sex steg. Att forsta pipelinen ar nodvandigt sammanhang for de specifika utmaningar som foljer.

Steg 1: Webblasarstart och isolering. En frarsk Chromium-instans startar med noll tillstand -- inga cookies, inget localStorage, ingen cache, inga service workers. Detta ar den renrumsgaranti som gor matning fore samtycke meningsfull. Vi konfigurerar en standardvy, realistisk user-agent och Accept-Language-huvuden matchande mallandet, samt standardflaggor. Varje skanning far sin egen webblasarprocess; det finns inget tillstandslackage mellan skanningar. Steg 2: Navigering och ogonblicksbild fore samtycke. Scannern navigerar till mal-URL:en, vantar pa att sidan nar ett stabilt tillstand (natverk inaktivt, DOM stabiliserad) och fangar allt som har hant: cookies satta, natverksforfragar gjorda (med fullstandig URL, timing och svarsmetadata), tredjepartsdomaner kontaktade och en helsidesskarmdump. Denna ogonblicksbild besvarar den fundamentala fragan: vad gjorde denna webbplats innan anvandaren hade nagon mojlighet att samtycka? Steg 3: CMP-detektering och bannerollidentifiering. Scannern forsoker identifiera samtyckeshanteringsplattformen och lokalisera samtyckesbanderollen, acceptknappen och avvisningsknappen. Detta anvander ett skiktat detekteringssystem som beskrivs i detalj nedan. Steg 4: Samtyckeinteraktion. Scannern interagerar med banderollen -- klickar acceptera for standardflodet, klickar avvisa for avvisningsflodestestet. Den vantar pa att sidan stabiliseras efter interaktion, med hansyn till animationer, skriptomutvardering och fordrojd taggavfyrning. Steg 5: Ogonblicksbild efter samtycke och differentialanalys. En andra fullstandig ogonblicksbild fangar tillstandet efter samtyckesinteraktion. Jamforelse av ogonblicksbilder fore och efter samtycke avslojar vad som andrades: nya cookies, nya sparningsforfragar, samtyckestillstand i CMP-API:er. Steg 6: Analys, klassificering och rapportgenerering. Raadata matas in i analysmoduler: cookie-klassificering mot var databas, spararmatchning mot kanda monster, cookie-livstidsutvärdering, tillganglighetsrevision av banderollen, Google Consent Mode-validering, fingeravtrycksignaldetektering och riskpoängsättning. Resultatet ar en strukturerad rapport med resultat, bevisartefakter och en sammansatt riskpoang.

Varje steg producerar tidsstamplad bevisning som lagras bestaende. Varje resultat kan sparas tillbaka till specifika natverksforfragar, cookie-poster eller skarmdumpar.

Utmaning 1: CMP-detektering -- 45 plattformar, oändliga variationer

Samtyckeshantering ar inte standardiserat. Det finns inget universellt HTML-attribut, inget obligatoriskt JavaScript-API, ingen konsekvent DOM-struktur som sager "detta ar en samtyckesbanderoll." Det finns 45 distinkta CMP:er i vart detekteringsbibliotek, var och en med sin egen DOM-struktur, skriptsignaturer, JavaScript-globaler och interaktionsmonster. Utover dessa var 34,7 % av de banderoller vi detekterade i var studie med 97 304 webbplatser generiska eller oidentifierade -- anpassade implementeringar, regionala leverantorer eller minimala losningar som inte matchade nagon kand CMP-signatur.

Var detektering anvander ett konfidensbaserat, skiktat tillvagagångssätt:

Skikt 1: Skriptsignaturdetektering

Scannern kontrollerar forekomsten av kanda CMP-skript via URL-monster och JavaScript-globala variabler. Cookiebot laddar till exempel fran `consent.cookiebot.com` och exponerar `window.Cookiebot`. OneTrust laddar fran `cdn.cookielaw.org` och exponerar `window.OneTrust`. Varje CMP har karakteristiska laddningsmonster som kan detekteras fore DOM-granskning.

Detta skikt ar snabbt och hog-konfidensigt nar det matchar. Men det har en kritisk begransning: det berättar vilken CMP som finns pa sidan, inte nodvandigtvis vilken CMP som ansvarar for samtyckesbanderollen. En webbplats kan ladda PiwikPRO for analys (som inkluderar en CMP-komponent) medan den anvander tarteaucitron for faktisk samtyckehantering. Att detektera bada skripten ar latt; att veta vilken som kontrollerar banderollen ar svarare.

Skikt 2: Verifierad selektormatchning

For varje kand CMP underhaller vi en kuraterad uppsattning CSS-selektorer som tillforlitligt identifierar banderollkontainern, acceptknappen och avvisningsknappen. Dessa ar selektorer vi har validerat over flera versioner och konfigurationer av varje CMP. Nar en CMP detekteras i skikt 1 och dess verifierade selektorer matchar element i DOM:en har vi hog konfidens i bade CMP-identifieringen och banderollens interaktionsmal.

Skikt 3: Kompatibel selektormatchning

En bredare uppsattning selektorer som fungerar over manga versioner av en CMP men ar mindre precisa. Dessa hanterar fall dar en CMP har anpassats, temats eller kor en version som inte tacks av vara verifierade selektorer. De byter precision mot tackning.

Skikt 4: Generiska heuristiker

For de 34,7 % av banderoller som inte ar associerade med en kand CMP faller vi tillbaka pa heuristisk detektering. Scannern letar efter:

• Fasta eller klibbiga element nara botten eller toppen av vyn
• Element som innehaller samtyckerelaterade nyckelord pa flera sprak ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" etc.)
• Knappar med vanliga samtyckeaktionsetiketter ("Accept All", "Reject All", "Manage Preferences" och motsvarigheter)
• Strukturella monster typiska for samtyckedialoger: overlagringsbakgrunder, modala kontainrar, stangknappar

Detta skikt fangar manga anpassade implementeringar men ar till sin natur mindre tillforlitligt. En fast promotionsbanderoll eller nyhetsbrevregistrering kan se strukturellt liknande ut som en samtyckedialog.

Skikt 5: CMP API-probing

Vissa CMP:er exponerar JavaScript-API:er -- framfor allt IAB Transparency and Consent Framework (TCF) API via `__tcfapi`. Vi probar efter dessa API:er for att bade verifiera CMP-detektering och lasa det programmatiska samtyckestillstandet, som vi senare jamfor med observerat webblasarbeteende.

Konfidensmodellen

Istallet for att behandla detektering som binar (hittad/inte hittad) tilldelar vi konfidenspoang baserat pa vilka skikt som matchade och hur starkt. En webbplats dar vi detekterar ett CMP-skript, matchar verifierade selektorer och hittar ett TCF API far hog konfidens. En webbplats dar bara generiska heuristiker triggade far lagre konfidens. Denna konfidenspoang matas in i var riskklassificering -- lagre detektionskonfidens innebar att resultat ar mer sannolika att klassificeras som inkonklusiva snarare an definitiva.

Konfidensmodellen ar anledningen till att CMP-felidentifiering, aven om den forekom, inte systematiskt snedvrider vara resultat. Nar detektering ar tvetydig sager vi det, istallet for att tvinga en klassificering.

Utmaning 2: Avvisningsflödet -- Varfor "Klicka och kontrollera" ar forvanansvart svart

Att testa en avvisningsknapp later enkelt: hitta den, klicka pa den, kontrollera om cookies ar borta. I praktiken ar varje steg kantat av tidsproblem, asynkront beteende och plattformsspecifika egenheter.

Hitta avvisningsknappen. Inte alla avvisningsknappar ar markta "Avvisa." De kan saga "Neka alla", "Vagra", "Bara nodvandiga cookies", "Hantera installningar" (som leder till ett andra lager dar avvisning ar mojlig), eller motsvarigheter pa nagot av dussintal sprak. Vissa CMP:er placerar avvisningsalternativet pa en annan visuell plats, i en annan storlek eller i en annan farg an acceptalternativet. Vissa gommar det bakom en lank "Fler alternativ" eller "Anpassa". Var scanner underhaller en flersprakig uppsattning avvisningsaktionsmonster och detekterar aven andralagersavvisningsalternativ dar forsta lagret bara erbjuder acceptera och anpassa. Vanta pa ratt ogonblick. Efter att ha klickat avvisa kan sidan genomga betydande forandringar: banderollen forsvinner (ofta med animation), CMP:n avfyrar samtyckestatusaterkallningar, tagghanterare omutvärderar sina regler och skript kan laddas eller avladdas. Att kontrollera cookies for tidigt fangar mellantillstandet. Att kontrollera for sent missar transient sparning som avfyras och slutfors snabbt. Vi anvander en flersignalvant: natverk inaktivt, DOM-stabilitet och ett minsta fordrojningsgolv, avstamt fran empirisk testning over hundratals CMP-konfigurationer. Omladdningstestet och samtyckes-respawn. Omladdningssteget ar det som avslöjade samtyckes-respawn som fenomen. Vi satte inte ut for att hitta det -- vart ursprungliga avvisningsflodestest kontrollerade bara det omedelbara tillstandet efter avvisning. Men under utvecklingen markete vi webbplatser som sag rena ut efter avvisning men hade sparningscookies nar vi kontrollerade igen efter en sidomladdning. Initial felsokning antog ett timing-problem i scannern. Ytterligare undersokning bekraftade att det var verkligt: tredjepartsskript som återsatte cookies vid sidladdning oavsett samtyckestillstand.

Vi la till explicit respawn-detektering i pipelinen: efter avvisningsflödet laddar scannern om sidan, vantar pa stabilitet och jamfor cookie-inventariet med ogonblicksbilden efter avvisning. Varje cookie som togs bort av avvisning och ateruppstar efter omladdning flaggas som en respawn. Detta fangade 1 642 webbplatser med 4 932 respawnande cookies -- ett resultat som hade varit osynligt utan omladdningssteget.

`waitForScriptIdentifiedCMP`-pollen. Vissa CMP:er laddas asynkront och renderar inte sin banderoll forran flera sekunder efter initial sidladdning. Om scannern gar vidare till avvisningssteget innan CMP:n har initierats, missar den antingen banderollen helt eller interagerar med ett delvis laddat UI. Vi implementerade en pollningsmekanism som vantar pa att CMP:ns JavaScript-API blir tillgangligt (t.ex. `__tcfapi` for TCF-baserade CMP:er, `Cookiebot`-globalen for Cookiebot) innan den fortsatter. Detta okar latens per skanning men minskar avsevart falskt negativa fran asynkron CMP-laddning.

Utmaning 3: Pipelinemattnading vid skala

Att skanna 97 304 webbplatser ar inte ett enmaskinsjobb. Varje skanning startar en Chromium-process, navigerar till en webbplats, fangar upp och klassificerar hundratals natverksforfragar, tar flera skarmdumpar och kor analysmoduler. En enskild skanning tar 30-90 sekunder beroende pa webbplatsens komplexitet. Med 15 simultana skanningar per arbetare blir resurshantering den primara tekniska utmaningen.

Semaforarkitekturen

Vi anvander en semaforbaserad samtidighetmodell for att begransa antalet simultana Chromium-processer per arbetare. Varje arbetare har en fast semafor (15 platser i var produktionskonfiguration). En skanning forvarvar en plats innan den startar sin webblasare och friger den vid slutforande. Detta forhindrar minnesutmattning -- 15 Chromium-instanser med full forfragefångst forbrukar redan avsevart RAM -- och ger mottryck mot Redis-kon.

Dokumentforfragefritagelsen

Tidigt i utvecklingen stotte vi pa ett genomstroöningsproblem: var forfragefångstlogik (som inspekterar varje forfragan for SSRF-sakerhet -- blockerar forfragar till privata IP-intervall, interna natverk och andra potentiellt farliga mal) la till latens till varje resursladdning, inklusive huvuddokumentforfragan. Eftersom dokument-URL:en redan har validerats innan skanningen borjar la vi till en snabbvagsforbikoppling: dokumenttypforfragar till den forvaliderade mal-URL:en hoppar over den fullstandiga fangstpipelinen. Denna till synes lilla optimering hade en betydande inverkan pa overgripande genomstromning eftersom dokumentforfragan blockerar allt annat.

DNS-forvärmning

Den forsta forfragan till en ny doman medfor en DNS-uppslagning, som pa var infrastruktur kunde lagga till 50-200 ms per doman. Med den genomsnittliga webbplatsen som kontaktar 10,4 tredjepartsdomaner (och vissa som kontaktar upp till 171) ackumulerades DNS-upplösningstiden avsevart. Vi implementerade DNS-forvärmning med en lokal Unbound DNS-resolver-cache: fore varje skanning loser vi maldomanen och varmer cachen. Unbound-instansen serverar cachade svar for efterfoljande uppslagningar inom skanningen, vilket reducerar DNS-overhead per doman till under en millisekund.

SSRF-sakerhet vid skala

Varje forfragan som fangats upp av scannern kontrolleras mot en uppsattning sakerhetsregler innan den tillats fortsatta. Forfragar till privata IP-intervall (RFC 1918, RFC 4193, link-local, loopback) blockeras. Detta forhindrar en skadlig malwebbplats fran att anvanda scannern som en SSRF-vektor for att proba interna natverk.

Utmaningen vid skala var att skilja genuina SSRF-blockeringar fran semaforkörning. Nar alla 15 semaforplatser anvands och en skanning inte kan forvarva en plats, ser den resulterande timeouten ytligt liknande ut som en forfragan som blockeras av sakerhetskal. Vi la till explicit felkategorisering for att skilja "blockerad eftersom malet löstes till en privat IP" fran "blockerad eftersom scannern ar pa kapacitet." Detta var nodvandigt for operativ overvakning och for korrekt klassificering av skanningsfel.

Utmaning 4: Detektering av bot-undvikande

Under studien identifierade vi 137 webbplatser som verkar avsiktligt dollja sin samtyckesbanderoll for automatiserade skannrar. Banderollen visas for manskliga besokare men undertrycks nar webbplatsen detekterar egenskaper hos automatiserad surfning.

Den vanligaste mekanismen vi identifierade involverar RCB (Real Cookie Banner) WordPress-tilläggets `isAcceptAllForBots`-konfigurationsalternativ. Nar det ar aktiverat detekterar denna installning automatiserade webblasare (via `navigator.webdriver`, user-agent-heuristiker eller beteendesignaler) och antingen automatiskt accepterar samtycke pa deras vagnar eller doljer banderollen helt. Avsikten, som dokumenterats av tillägget, ar att forhindra att automatiserade besokare serveras en samtyckedialog de inte kan meningsfullt interagera med. Effekten ar att efterlevnadskannrar -- och regulatoriska granskare som anvander automatiserade verktyg -- ser en webbplats som verkar sakna samtyckesmekanism, nar manskliga besokare ser en fullstandig samtyckesbanderoll.

Detta ar ett transparensproblem. Om en webbplats samtyckesmekanism bara ar synlig for manskliga besokare kan den inte granskas i stor skala. Vi flaggar dessa webbplatser separat i vara resultat eftersom resultatet ar kvalitativt annorlunda fran "ingen banderoll detekterad." Webbplatsen har en banderoll; den valjer att inte visa den for oss.

Vi detekterar bot-undvikande genom en kombination av signaler: forekomsten av kand bot-detektionskonfiguration i CMP-installningar (tillganglig via JavaScript-inspektion), avvikelser mellan vad DOM:en visar och vad CMP:ns API rapporterar, och i vissa fall genom att jamfora automatiserade skanningsresultat med manuell verifiering.

Siffran 137 ar sakert en underraekning. Vi kan bara detektera bot-undvikande nar vi kan identifiera mekanismen. Webbplatser som anvander mer sofistikerad eller anpassad bot-detektering kan framgångsrikt undvika bade var scanner och var undvikandedetektering.

Utmaning 5: CMP-felidentifiering

En webbplats kan ladda flera skript som ser ut som samtyckeshanteringsplattformar. PiwikPRO inkluderar en CMP-komponent men ar framfor allt en analyssvit. Vissa WordPress-webbplatser laddar Complianz vid sidan av ett separat analystillagg som har CMP-liknande funktioner. Foretagswebbplatser kan ha kvarlevor av en tidigare CMP som fortfarande laddas vid sidan av den aktuella.

Naiv detektering -- "om vi ser skriptet ar det CMP:n" -- producerar felidentifieringar som kaskaderar till felaktig banderollinteraktion. Om scannern identifierar PiwikPRO som CMP:n och forsoker anvanda PiwikPRO:s banderollselektorer kan den missa den faktiska tarteaucitron-banderollen som kontrollerar samtycke pa webbplatsen.

Vart konfidensbaserade tillvagångssätt adresserar detta genom att ranka CMP-kandidater. Nar flera potentiella CMP:er detekteras:

1. Vi kontrollerar vilken som har en synlig banderoll i DOM:en (skript narvarande men ingen banderoll innebar sannolikt inaktiv eller icke-CMP-anvandning).

2. Vi kontrollerar vilken som exponerar ett aktivt CMP-API (t.ex. en fungerande `__tcfapi` eller motsvarande).

3. Vi foredrager den CMP vars verifierade selektorer matchar synliga DOM-element framfor den som bara detekteras via skript-URL.

Denna heuristik ar inte perfekt, men den loste de vanligaste felidentifieringsfallen vi stotte pa under utveckling och testning.

Begransningar

Ingen automatiserad scanner replikerar perfekt varje mansklig surfupplevelse. Dessa ar de kanda begransningar som paverkar vara resultat:

GeoIP-beroende banderoller. Vissa CMP:er, framfor allt CookieYes, serverar olika samtyckeupplevelser baserat pa besokarens IP-geolokalisering. Vara skanningar utgår fran specifika natverksplatser i Europa. En webbplats som visar en samtyckesbanderoll for besokare fran Frankrike men inte for besokare utanfor EU visar olika resultat beroende pa skanningens ursprung. Vi skannar for närvarande inte varje webbplats fran varje EU-land. Stangd shadow DOM. Vissa CMP:er renderar sin banderoll i en stangd shadow DOM, som ar otillganglig for standard-DOM-fragor via `document.querySelector`. Transcends CMP anvander detta tillvagångssätt. Var scanner kan detektera shadow host-elementet men kan inte inspektera dess innehall for att hitta accept-/avvisningsknappar. Dessa webbplatser hamnar vanligtvis som inkonklusiva i vara resultat. Dynamiska klassnamn och obfuskering. Vissa CMP:er, framfor allt Admiral, anvander dynamiskt genererade klassnamn som andras vid varje sidladdning. Selektorbaserad detektering misslyckas for dessa eftersom selektorerna inte ar stabila over besok. Vi faller tillbaka pa generiska heuristiker, men konfidensen ar lagre. Ensidiga applikationer. SPA:er som hanterar samtyckestillstand helt i klientsides JavaScript och laddar samtyckesmekanismen efter initiala routerandringar (snarare an vid initial sidladdning) ar svarare att bedoma. Var scanner navigerar till URL:en och vantar pa att sidan stabiliseras, men den simulerar inte navigering i appen. En samtyckesbanderoll som bara visas efter att anvandaren navigerar inom SPA:n kan missas. Sprachtackning. Var avvisningsknappdetektering anvander textmatchning over en uppsattning sprak som stods, men vi tacker inte varje EU-sprak lika. En banderoll pa maltesiska eller estniska kan ha avvisningsknappetiketter som var textmatchning inte kannar igen, vilket leder till att avvisningsflodestestningen missas (aven om sjalva banderollen fortfarande kan detekteras av strukturella heuristiker). Timing-marginalfall. Ett skript som avfyras 30 sekunder efter sidladdning missas av en skanning som vantar 15 sekunder pa natverk inaktivt. Vi anvander generosa tidsgranser, men den langa svansen av asynkront beteende ar till sin natur svar att fanga fullstandigt.

Dessa begransningar bidrar till var 14,9 % inkonklusiva frekvens. Vi foredrar att vara arliga om vad vi inte kan bedoma tillforlitligt snarare an att tvinga varje skanning till en definitiv klassificering.

Infrastrukturen

Produktionens skanningsinfrastruktur bestar av:

• Skannermotor: En Go-applikation som anvander chromedp som CDP-klient for Chromium-automation. Go valdes for sin samtidighetmodell (goroutiner och kanaler kartlagger naturligt pa parallell skanningsorkestrering), sin prestanda och sin distributionsenkelthet (en enda statisk binar).
• Webblasarkorning: Huvudlos Chromium startad per skanning via CDP. Varje skanning far en frarsk webblasarprocess med noll delat tillstand.
• Ko: Redis-backad arbetskon som distribuerar URL:er till skannerarbetare. Redis hanterar jobbdistribution, framstegsspårning och hastighetsbegransning.
• Databas: PostgreSQL for bestående skanningsresultat, resultat, bevismetadata och all strukturerad data. Skanningar, resultat, cookies, forfragar och analysresultat lagras alla relationellt.
• DNS-cache: Lokal Unbound-resolver som tillhandahaller cachade DNS-uppslagningar och SSRF-saker upploesning.
• Bevislagring: Skarmdumpar, HAR-filer och PDF-rapporter lagras som bestående artefakter kopplade till skanningsposter.

For studien med 97 304 webbplatser bearbetade vi 114 748 kandidat-URL:er (97 304 slutfordes framgangsrikt) under ungefar 2,5 dagar med 3 serverinstanser som korde skannerarbetare parallellt. Varje server korde flera arbetarprocesser med 15 simultana skanningsplatser var. Toppgenomstromningen var ungefar 25-30 slutforda skanningar per minut per server.

Den primara flaskhalsen var inte CPU eller minne utan natverk: varje skanning genererar hundratals utgaende forfragar (till malwebbplatsen och dess tredjepartsresurser), och den aggregerade bandbredden och anslutningsantalet over alla simultana skanningar mattade tillganglig natverkskapacitet innan andra resurser var uttomda.

Oppna utmaningar och framtida arbete

Flera problem kvarstar olosta eller delvis losta:

Samtyckesbanderolllokalisering. Var textmatchning tacker storre EU-sprak men ar ofullstandig for mindre sprakgemenskaper. Att utoka tackningen kraver inte bara att lagga till oversattningar utan att validera att selektorer och interaktionsmonster fungerar korrekt med lokaliserade CMP-versioner. Longitudinell overvakning. Var nuvarande arkitektur ar optimerad for punktskanning. Att detektera forandringar i samtyckbeteende over tid -- forbattrades en webbplats efter tillsyn? Fixade en CMP-uppdatering en klass av avvisningsflodesmisslyckanden? -- kraver upprepade skanningar med differentialanalys, vilket ar arkitekturellt annorlunda fran engangsbedoming. CMP-efterlevnadsbenchmarking. Vi har datan for att bedoma efterlevnadsgrad per CMP (ar Cookiebot associerat med battre efterlevnad an OneTrust?), men att separera CMP-kvalitet fran webbplatsoperatorens konfigurationskvalitet ar metodologiskt komplext. En CMP som oftare distribueras av stora foretag med dedikerade integritetesteam kommer att se battre ut i aggregat aven om verktyget i sig inte ar mer kompatibelt. Samtyckestatusverifiering i realtid. Den nuvarande scannern opererar i batchlage. Att integrera samtyckeeverifiering i CI/CD-pipelines eller realtidsovervakning kraver ett snabbare, lattare skanningslage som offrar visst bevisdjup for hastighet. Vi utforskar detta.

API:et

Samma skannermotor som beskrivs i detta inlagg ar tillganglig via GDPR Monitors publika API. Du kan skicka skanningsbegaran programmatiskt, polla efter resultat och hamta strukturerade resultat och bevisartefakter. API:et returnerar samma data som vart UI visar: ogonblicksbilder fore samtycke, cookie-inventarier, CMP-detekteringsresultat, avvisningsflodesresultat, riskpoang och fullstandiga beviskedjor.

Om du bygger efterlevnadsverktyg, integrerar integritetskontroller i CI/CD-pipelines, bedriver egen forskning eller bygger in overvakning i ett integritetsprogram ger API:et tillgang till beteendemassig samtyckeanalys utan behov av att bygga och underhalla din egen Chromium-automationsinfrastruktur.

---

Prova sjalv. API-dokumentation finns pa gdprprivacymonitor.eu/developers/api. Skicka en enskild URL eller integrera automatiserad integritetsovervakning i ditt arbetsflode.