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

La verifica automatizzata della conformità del consenso sembra semplice finché non si prova a realizzarla. L'approccio ingenuo -- caricare una pagina, controllare i cookie, cercare un banner -- non coglie la maggior parte di ciò che conta. Le violazioni del consenso sono comportamentali, non strutturali. Si manifestano nella tempistica dell'esecuzione degli script, nella sequenza delle richieste di rete, nella risposta degli elementi UI all'interazione dell'utente e nella persistenza dello stato tra i caricamenti di pagina. Non si può valutare nulla di tutto questo senza eseguire un vero browser, interagire con la pagina come farebbe un essere umano e registrare ciò che accade effettivamente a livello di rete.

Questo post descrive come abbiamo costruito il motore di scansione alla base di GDPR Monitor, le sfide ingegneristiche che hanno consumato la maggior parte del nostro tempo, le decisioni architetturali che abbiamo preso e il perché, e i limiti su cui siamo onesti. Se lavori nella conformità web, nell'automazione dei browser o nella misurazione web su larga scala, dovresti trovare qualcosa di utile qui.

Panoramica della pipeline

Ogni scansione passa attraverso sei fasi. Comprendere la pipeline è un contesto necessario per le sfide specifiche che seguono.

Fase 1: Avvio del browser e isolamento. Un'istanza Chromium pulita si avvia con stato zero -- nessun cookie, nessun localStorage, nessuna cache, nessun service worker. Questa è la garanzia di camera sterile che rende significativa la misurazione pre-consenso. Configuriamo un viewport standard, header user-agent e Accept-Language realistici corrispondenti al paese di destinazione e flag browser standard. Ogni scansione ottiene il proprio processo browser; non c'è perdita di stato tra le scansioni. Fase 2: Navigazione e snapshot pre-consenso. Lo scanner naviga verso l'URL di destinazione, attende che la pagina raggiunga uno stato stabile (rete inattiva, DOM stabile) e cattura tutto ciò che è successo: cookie impostati, richieste di rete effettuate (con URL completo, tempistiche e metadati di risposta), domini di terze parti contattati e uno screenshot a pagina intera. Questo snapshot risponde alla domanda fondamentale: cosa ha fatto questo sito web prima che l'utente avesse qualsiasi opportunità di dare il consenso? Fase 3: Rilevamento della CMP e identificazione del banner. Lo scanner tenta di identificare la piattaforma di gestione del consenso e di localizzare il banner di consenso, il pulsante di accettazione e il pulsante di rifiuto. Questo utilizza un sistema di rilevamento a strati descritto in dettaglio di seguito. Fase 4: Interazione con il consenso. Lo scanner interagisce con il banner -- cliccando "Accetta" per il flusso standard, cliccando "Rifiuta" per il test del flusso di rifiuto. Attende che la pagina si stabilizzi dopo l'interazione, tenendo conto di animazioni, rivalutazione degli script e attivazione ritardata dei tag. Fase 5: Snapshot post-consenso e analisi differenziale. Un secondo snapshot completo cattura lo stato dopo l'interazione con il consenso. Il confronto tra snapshot pre-consenso e post-consenso rivela cosa è cambiato: nuovi cookie, nuove richieste di tracciamento, stato del consenso nelle API della CMP. Fase 6: Analisi, classificazione e generazione del report. I dati grezzi alimentano moduli di analisi: classificazione dei cookie rispetto al nostro database, corrispondenza dei tracker rispetto a pattern noti, valutazione della durata dei cookie, audit dell'accessibilità del banner, validazione di Google Consent Mode, rilevamento dei segnali di fingerprinting e calcolo del punteggio di rischio. L'output è un report strutturato con risultati, artefatti di prova e un punteggio di rischio composito.

Ogni fase produce prove con timestamp che vengono memorizzate in modo durevole. Qualsiasi risultato può essere ricondotto a specifiche richieste di rete, voci di cookie o screenshot.

Sfida 1: Rilevamento delle CMP -- 45 piattaforme, infinite variazioni

La gestione del consenso non è standardizzata. Non esiste un attributo HTML universale, nessuna API JavaScript obbligatoria, nessuna struttura DOM coerente che dica "questo è un banner di consenso". Ci sono 45 CMP distinte nella nostra libreria di rilevamento, ciascuna con la propria struttura DOM, firme degli script, variabili globali JavaScript e pattern di interazione. Oltre a queste, il 34,7% dei banner rilevati nel nostro studio su 97.304 siti erano generici o non identificati -- implementazioni personalizzate, fornitori regionali o soluzioni minimali che non corrispondono a nessuna firma CMP nota.

Il nostro rilevamento utilizza un approccio a strati basato sulla confidenza:

Strato 1: Rilevamento delle firme degli script

Lo scanner verifica la presenza di script CMP noti tramite pattern URL e variabili globali JavaScript. Cookiebot, ad esempio, si carica da `consent.cookiebot.com` ed espone `window.Cookiebot`. OneTrust si carica da `cdn.cookielaw.org` ed espone `window.OneTrust`. Ogni CMP ha pattern di caricamento caratteristici che possono essere rilevati prima di esaminare il DOM.

Questo strato è veloce e ad alta confidenza quando trova una corrispondenza. Ma ha un limite critico: ti dice quale CMP è presente sulla pagina, non necessariamente quale CMP è responsabile del banner di consenso. Un sito potrebbe caricare PiwikPRO per l'analytics (che include un componente CMP) utilizzando al contempo tarteaucitron per la gestione effettiva del consenso. Rilevare entrambi gli script è facile; sapere quale controlla il banner è più difficile.

Strato 2: Corrispondenza dei selettori verificati

Per ogni CMP nota, manteniamo un set curato di selettori CSS che identificano in modo affidabile il contenitore del banner, il pulsante di accettazione e il pulsante di rifiuto. Questi sono selettori che abbiamo validato su molteplici versioni e configurazioni di ogni CMP. Quando una CMP viene rilevata nello Strato 1 e i suoi selettori verificati corrispondono a elementi nel DOM, abbiamo alta confidenza sia nell'identificazione della CMP che nei target di interazione del banner.

Strato 3: Corrispondenza dei selettori compatibili

Un set più ampio di selettori che funziona su molte versioni di una CMP ma è meno preciso. Gestiscono i casi in cui una CMP è stata personalizzata, tematizzata o sta eseguendo una versione non coperta dai nostri selettori verificati. Scambiano precisione per copertura.

Strato 4: Euristiche generiche

Per il 34,7% dei banner non associati a una CMP nota, ricorriamo al rilevamento euristico. Lo scanner cerca:

• Elementi a posizione fissa o sticky vicino alla parte inferiore o superiore del viewport
• Elementi contenenti parole chiave relative al consenso in più lingue ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar", ecc.)
• Pulsanti con etichette comuni di azione sul consenso ("Accept All", "Reject All", "Manage Preferences" e equivalenti)
• Pattern strutturali tipici dei dialoghi di consenso: sfondi overlay, contenitori modali, pulsanti di chiusura

Questo strato intercetta molte implementazioni personalizzate ma è intrinsecamente meno affidabile. Un banner promozionale a posizione fissa o un modulo di iscrizione alla newsletter può apparire strutturalmente simile a un dialogo di consenso.

Strato 5: Sondaggio delle API CMP

Alcune CMP espongono API JavaScript -- in particolare l'API IAB Transparency and Consent Framework (TCF) tramite `__tcfapi`. Sondiamo queste API sia per verificare il rilevamento della CMP sia per leggere lo stato di consenso programmatico, che successivamente confrontiamo con il comportamento osservato del browser.

Il modello di confidenza

Piuttosto che trattare il rilevamento come binario (trovato/non trovato), assegniamo punteggi di confidenza basati su quali strati hanno trovato corrispondenza e con quale forza. Un sito dove rileviamo uno script CMP, troviamo corrispondenza con selettori verificati e troviamo un'API TCF ottiene alta confidenza. Un sito dove solo le euristiche generiche sono scattate ottiene confidenza più bassa. Questo punteggio di confidenza alimenta la nostra classificazione del rischio -- una confidenza di rilevamento più bassa significa che i risultati sono più propensi a essere classificati come inconclusivi piuttosto che definitivi.

Il modello di confidenza è il motivo per cui l'errata identificazione della CMP, sebbene si verifichi, non distorce sistematicamente i nostri risultati. Quando il rilevamento è ambiguo, lo dichiariamo, piuttosto che forzare una classificazione.

Sfida 2: Il flusso di rifiuto -- Perché "Clicca e controlla" è sorprendentemente difficile

Testare un pulsante di rifiuto sembra semplice: trovarlo, cliccarlo, verificare se i cookie sono spariti. In pratica, ogni passaggio è irto di problemi di tempistica, comportamento asincrono e stranezze specifiche della piattaforma.

Trovare il pulsante di rifiuto. Non tutti i pulsanti di rifiuto sono etichettati "Rifiuta". Possono dire "Decline All", "Refuse", "Solo cookie necessari", "Gestisci impostazioni" (che porta a un secondo livello dove il rifiuto è possibile), o equivalenti in qualsiasi delle decine di lingue. Alcune CMP posizionano l'opzione di rifiuto in una posizione visiva diversa, con dimensioni diverse o un colore diverso dall'opzione di accettazione. Alcune la nascondono dietro un link "Altre opzioni" o "Personalizza". Il nostro scanner mantiene un set multilingue di pattern di azione di rifiuto e rileva anche opzioni di rifiuto al secondo livello dove il primo livello offre solo accettazione e personalizzazione. Attendere il momento giusto. Dopo aver cliccato "Rifiuta", la pagina può subire cambiamenti significativi: il banner si chiude (spesso con animazione), la CMP attiva callback sullo stato del consenso, i tag manager rivalutano le loro regole e gli script possono essere caricati o scaricati. Controllare i cookie troppo presto intercetta lo stato di transizione. Controllare troppo tardi perde il tracciamento transitorio che si attiva e completa rapidamente. Utilizziamo un'attesa multi-segnale: inattività della rete, stabilità del DOM e una soglia minima di ritardo, calibrata dal testing empirico su centinaia di configurazioni CMP. Il test di ricaricamento e il consent respawn. Il passaggio di ricaricamento è ciò che ha rivelato il consent respawn come fenomeno. Non ci eravamo proposti di trovarlo -- il nostro test originale del flusso di rifiuto controllava solo lo stato immediatamente post-rifiuto. Ma durante lo sviluppo, abbiamo notato siti che apparivano puliti dopo il rifiuto ma avevano cookie di tracciamento quando controllavamo di nuovo dopo un ricaricamento della pagina. Il debugging iniziale ha assunto un problema di tempistica dello scanner. Un'indagine approfondita ha confermato che era reale: script di terze parti che re-impostavano cookie al caricamento della pagina indipendentemente dallo stato del consenso.

Abbiamo aggiunto il rilevamento esplicito del respawn alla pipeline: dopo il flusso di rifiuto, lo scanner ricarica la pagina, attende la stabilità e confronta l'inventario dei cookie con lo snapshot post-rifiuto. Qualsiasi cookie rimosso dal rifiuto e ricomparso dopo il ricaricamento viene segnalato come respawn. Questo ha intercettato 1.642 siti con 4.932 cookie che facevano respawn -- un risultato che sarebbe stato invisibile senza il passaggio di ricaricamento.

Il poll `waitForScriptIdentifiedCMP`. Alcune CMP si caricano in modo asincrono e non rendono il loro banner fino a diversi secondi dopo il caricamento iniziale della pagina. Se lo scanner procede al passaggio di rifiuto prima che la CMP si sia inizializzata, o perde completamente il banner o interagisce con un'interfaccia parzialmente caricata. Abbiamo implementato un meccanismo di polling che attende che l'API JavaScript della CMP diventi disponibile (ad es., `__tcfapi` per le CMP basate su TCF, il globale `Cookiebot` per Cookiebot) prima di procedere. Questo aggiunge latenza per scansione ma riduce significativamente i falsi negativi dal caricamento asincrono della CMP.

Sfida 3: Saturazione della pipeline su scala

Scansionare 97.304 siti web non è un lavoro per una singola macchina. Ogni scansione avvia un processo Chromium, naviga verso un sito web, intercetta e classifica centinaia di richieste di rete, acquisisce molteplici screenshot ed esegue moduli di analisi. Una singola scansione richiede 30-90 secondi a seconda della complessità del sito. Con 15 scansioni simultanee per worker, la gestione delle risorse diventa la preoccupazione ingegneristica principale.

L'architettura a semaforo

Utilizziamo un modello di concorrenza basato su semafori per limitare il numero di processi Chromium simultanei per worker. Ogni worker ha un semaforo fisso (15 slot nella nostra configurazione di produzione). Una scansione acquisisce uno slot prima di avviare il suo browser e lo rilascia al completamento. Questo previene l'esaurimento della memoria -- 15 istanze Chromium con intercettazione completa delle richieste consumano già una RAM significativa -- e fornisce contropressione sulla coda Redis.

L'esenzione per le richieste documento

Nelle prime fasi di sviluppo, abbiamo incontrato un problema di throughput: la nostra logica di intercettazione delle richieste (che ispeziona ogni richiesta per la sicurezza SSRF -- bloccando richieste verso range IP privati, reti interne e altri target potenzialmente pericolosi) aggiungeva latenza a ogni caricamento di risorsa, inclusa la richiesta del documento principale. Poiché l'URL del documento è già stato validato prima dell'inizio della scansione, abbiamo aggiunto un bypass fast-path: le richieste di tipo documento verso l'URL target pre-validato saltano la pipeline completa di intercettazione. Questa ottimizzazione apparentemente piccola ha avuto un impatto significativo sul throughput complessivo perché la richiesta del documento blocca tutto il resto.

Pre-riscaldamento DNS

La prima richiesta verso un nuovo dominio comporta una ricerca DNS, che sulla nostra infrastruttura poteva aggiungere 50-200ms per dominio. Con il sito medio che contatta 10,4 domini di terze parti (e alcuni che ne contattano fino a 171), il tempo di risoluzione DNS si accumulava significativamente. Abbiamo implementato il pre-riscaldamento DNS utilizzando una cache DNS con resolver Unbound locale: prima di ogni scansione, risolviamo il dominio target e riscaldiamo la cache. L'istanza Unbound serve risposte in cache per le ricerche successive all'interno della scansione, riducendo l'overhead DNS per dominio a valori sub-millisecondo.

Sicurezza SSRF su scala

Ogni richiesta intercettata dallo scanner viene controllata rispetto a un set di regole di sicurezza prima di essere autorizzata. Le richieste verso range IP privati (RFC 1918, RFC 4193, link-local, loopback) vengono bloccate. Questo impedisce a un sito target malevolo di utilizzare lo scanner come vettore SSRF per sondare le reti interne.

La sfida su scala era distinguere i blocchi SSRF genuini dalla saturazione dei semafori. Quando tutti i 15 slot del semaforo sono in uso e una scansione non riesce ad acquisire uno slot, il timeout risultante appare superficialmente simile a una richiesta bloccata per motivi di sicurezza. Abbiamo aggiunto una categorizzazione esplicita degli errori per distinguere "bloccata perché il target ha risolto verso un IP privato" da "bloccata perché lo scanner è a capacità". Questo era essenziale per il monitoraggio operativo e per una classificazione accurata dei fallimenti di scansione.

Sfida 4: Rilevamento dell'evasione dei bot

Durante lo studio, abbiamo identificato 137 siti web che sembrano nascondere deliberatamente il loro banner di consenso agli scanner automatizzati. Il banner viene servito ai visitatori umani ma soppresso quando il sito rileva caratteristiche di navigazione automatizzata.

Il meccanismo più comune che abbiamo identificato coinvolge l'opzione di configurazione `isAcceptAllForBots` del plugin WordPress RCB (Real Cookie Banner). Quando abilitata, questa impostazione rileva i browser automatizzati (tramite `navigator.webdriver`, euristiche user-agent o segnali comportamentali) e accetta automaticamente il consenso per loro conto o nasconde completamente il banner. L'intento, come documentato dal plugin, è impedire che ai visitatori automatizzati venga servito un dialogo di consenso con cui non possono interagire in modo significativo. L'effetto è che gli scanner di conformità -- e gli auditor regolamentari che utilizzano strumenti automatizzati -- vedono un sito che sembra non avere alcun meccanismo di consenso, quando i visitatori umani vedono un banner di consenso completo.

Questo è un problema di trasparenza. Se il meccanismo di consenso di un sito web è visibile solo ai visitatori umani, non può essere verificato su scala. Segnaliamo questi siti separatamente nei nostri risultati perché il risultato è qualitativamente diverso da "nessun banner rilevato". Il sito ha un banner; sta scegliendo di non mostrarcelo.

Rileviamo l'evasione dei bot attraverso una combinazione di segnali: la presenza di configurazioni note di rilevamento bot nelle impostazioni della CMP (accessibili tramite ispezione JavaScript), discrepanze tra ciò che il DOM mostra e ciò che l'API della CMP riporta, e in alcuni casi confrontando i risultati della scansione automatizzata con la verifica manuale.

La cifra di 137 è certamente un conteggio insufficiente. Possiamo rilevare l'evasione dei bot solo quando possiamo identificare il meccanismo. Siti che utilizzano un rilevamento bot più sofisticato o personalizzato possono eludere con successo sia il nostro scanner che il nostro rilevamento dell'evasione.

Sfida 5: Errata identificazione della CMP

Un sito può caricare molteplici script che sembrano piattaforme di gestione del consenso. PiwikPRO include un componente CMP ma è principalmente una suite di analytics. Alcuni siti WordPress caricano Complianz insieme a un plugin di analytics separato che ha funzionalità simili a una CMP. I siti enterprise possono avere residui di una CMP precedente ancora in caricamento insieme a quella attuale.

Il rilevamento ingenuo -- "se vediamo lo script, è la CMP" -- produce identificazioni false che si propagano in interazioni errate con il banner. Se lo scanner identifica PiwikPRO come la CMP e tenta di utilizzare i selettori del banner di PiwikPRO, potrebbe perdere il banner tarteaucitron effettivo che controlla il consenso sul sito.

Il nostro approccio basato sulla confidenza affronta questo problema classificando i candidati CMP. Quando vengono rilevate molteplici potenziali CMP:

1. Verifichiamo quale ha un banner visibile nel DOM (script presente ma nessun banner significa probabilmente inattivo o utilizzo non-CMP).

2. Verifichiamo quale espone un'API CMP attiva (ad es., un `__tcfapi` funzionante o equivalente).

3. Preferiamo la CMP i cui selettori verificati corrispondono a elementi DOM visibili rispetto a quella rilevata solo tramite URL dello script.

Questa euristica non è perfetta, ma ha risolto i casi di errata identificazione più comuni che abbiamo incontrato durante lo sviluppo e il testing.

Limiti

Nessuno scanner automatizzato replica perfettamente ogni esperienza di navigazione umana. Questi sono i limiti noti:

Banner dipendenti dal GeoIP. Alcune CMP, in particolare CookieYes, servono esperienze di consenso diverse in base alla geolocalizzazione IP del visitatore. Le nostre scansioni originano da posizioni di rete specifiche in Europa. Un sito che mostra un banner di consenso ai visitatori dalla Francia ma non ai visitatori dall'esterno dell'UE mostrerà risultati diversi a seconda dell'origine della scansione. Attualmente non scansioniamo ogni sito da ogni paese dell'UE. Shadow DOM chiuso. Alcune CMP rendono il loro banner all'interno di uno shadow DOM chiuso, che è inaccessibile alle query DOM standard tramite `document.querySelector`. La CMP di Transcend utilizza questo approccio. Il nostro scanner può rilevare l'elemento host dello shadow ma non può ispezionarne i contenuti per trovare pulsanti di accettazione/rifiuto. Questi siti finiscono tipicamente come inconclusivi nei nostri risultati. Nomi di classe dinamici e offuscamento. Alcune CMP, in particolare Admiral, utilizzano nomi di classe generati dinamicamente che cambiano a ogni caricamento di pagina. Il rilevamento basato su selettori fallisce per queste perché i selettori non sono stabili tra le visite. Ricorriamo alle euristiche generiche, ma la confidenza è più bassa. Applicazioni a pagina singola. Le SPA che gestiscono lo stato del consenso interamente in JavaScript lato client e caricano il meccanismo di consenso dopo cambiamenti di route iniziali (piuttosto che al caricamento iniziale della pagina) sono più difficili da valutare. Il nostro scanner naviga verso l'URL e attende che la pagina si stabilizzi, ma non simula la navigazione interna all'app. Un banner di consenso che appare solo dopo che l'utente naviga all'interno della SPA potrebbe essere perso. Copertura linguistica. Il nostro rilevamento del pulsante di rifiuto utilizza la corrispondenza testuale su un set di lingue supportate, ma non copriamo ogni lingua dell'UE in modo uguale. Un banner in maltese o estone potrebbe avere etichette del pulsante di rifiuto che la nostra corrispondenza testuale non riconosce, portando a un mancato test del flusso di rifiuto (anche se il banner stesso potrebbe essere rilevato tramite euristiche strutturali). Casi limite di tempistica. Uno script che si attiva 30 secondi dopo il caricamento della pagina sarà perso da una scansione che attende 15 secondi per l'inattività della rete. Utilizziamo timeout generosi, ma la coda lunga del comportamento asincrono è intrinsecamente difficile da catturare completamente.

Questi limiti contribuiscono al nostro tasso di inconclusività del 14,9%.

L'infrastruttura

L'infrastruttura di scansione in produzione consiste in:

• Motore di scansione: Un'applicazione Go che utilizza chromedp come client CDP per l'automazione di Chromium. Go è stato scelto per il suo modello di concorrenza (goroutine e canali si mappano naturalmente sull'orchestrazione parallela delle scansioni), le sue caratteristiche di performance e la sua semplicità di deployment (singolo binario statico).
• Runtime del browser: Chromium headless avviato per ogni scansione tramite CDP. Ogni scansione ottiene un processo browser fresco con zero stato condiviso.
• Coda: Coda di lavoro basata su Redis che distribuisce URL ai worker dello scanner. Redis gestisce la distribuzione dei job, il tracciamento del progresso e il rate limiting.
• Database: PostgreSQL per i risultati durevoli delle scansioni, i risultati, i metadati delle prove e tutti i dati strutturati. Scansioni, risultati, cookie, richieste e output delle analisi sono tutti memorizzati in modo relazionale.
• Cache DNS: Resolver Unbound locale che fornisce ricerche DNS in cache e risoluzione sicura contro SSRF.
• Storage delle prove: Screenshot, file HAR e report PDF sono memorizzati come artefatti durevoli collegati ai record delle scansioni.

Per lo studio su 97.304 siti, abbiamo elaborato 114.748 URL candidati (97.304 completati con successo) in circa 2,5 giorni utilizzando 3 istanze server che eseguivano worker dello scanner in parallelo. Ogni server eseguiva molteplici processi worker con 15 slot di scansione simultanei ciascuno. Il throughput di picco era circa 25-30 scansioni completate al minuto per server.

Il collo di bottiglia principale non era la CPU o la memoria ma la rete: ogni scansione genera centinaia di richieste in uscita (verso il sito target e le sue risorse di terze parti), e la larghezza di banda aggregata e il conteggio delle connessioni su tutte le scansioni simultanee saturavano la capacità di rete disponibile prima che altre risorse si esaurissero.

Sfide aperte e lavoro futuro

Diversi problemi restano irrisolti o parzialmente risolti:

Localizzazione dei banner di consenso. La nostra corrispondenza testuale copre le principali lingue dell'UE ma è incompleta per le comunità linguistiche più piccole. Espandere la copertura richiede non solo aggiungere traduzioni ma validare che i selettori e i pattern di interazione funzionino correttamente con le versioni CMP localizzate. Monitoraggio longitudinale. La nostra architettura attuale è ottimizzata per la scansione puntuale. Rilevare cambiamenti nel comportamento del consenso nel tempo -- un sito è migliorato dopo l'enforcement? Un aggiornamento della CMP ha corretto una classe di fallimenti del flusso di rifiuto? -- richiede scansioni ripetute con analisi differenziale, che è architetturalmente diverso dalla valutazione una tantum. Benchmarking della conformità per CMP. Abbiamo i dati per valutare i tassi di conformità per CMP (Cookiebot è associato a una migliore conformità rispetto a OneTrust?), ma districare la qualità della CMP dalla qualità della configurazione dell'operatore del sito è metodologicamente complesso. Una CMP che viene più spesso implementata da grandi imprese con team privacy dedicati apparirà migliore in aggregato anche se lo strumento stesso non è più conforme. Verifica dello stato del consenso in tempo reale. Lo scanner attuale opera in modalità batch. Integrare la verifica del consenso nelle pipeline CI/CD o nel monitoraggio in tempo reale richiede una modalità di scansione più rapida e leggera che sacrifica una certa profondità delle prove per la velocità. Stiamo esplorando questa possibilità.

L'API

Lo stesso motore di scansione descritto in questo post è disponibile tramite l'API pubblica di GDPR Monitor. Puoi inviare richieste di scansione in modo programmatico, interrogare i risultati e recuperare risultati strutturati e artefatti di prova. L'API restituisce gli stessi dati visualizzati dalla nostra interfaccia: snapshot pre-consenso, inventari dei cookie, risultati del rilevamento CMP, esiti del flusso di rifiuto, punteggi di rischio e catene di prove complete.

Se stai costruendo strumenti di conformità, integrando controlli sulla privacy nelle pipeline CI/CD, conducendo le tue ricerche o implementando il monitoraggio in un programma privacy, l'API fornisce accesso all'analisi comportamentale del consenso senza la necessità di costruire e mantenere la tua infrastruttura di automazione Chromium.

---

Provalo tu stesso. La documentazione dell'API è disponibile su gdprprivacymonitor.eu/developers/api. Invia un singolo URL o integra il monitoraggio automatizzato della privacy nel tuo flusso di lavoro.