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

Automatizirana provjera usklađenosti pristanka zvuči jednostavno dok je ne pokušate izgraditi. Naivan pristup -- dohvatite stranicu, provjerite kolačiće, potražite banner -- propušta većinu onoga što je bitno. Kršenja pristanka su bihevioralna, ne strukturalna. Manifestiraju se u vremenskom rasporedu izvršavanja skripti, redoslijedu mrežnih zahtjeva, reakciji elemenata korisničkog sučelja na interakciju korisnika i trajnosti stanja kroz učitavanja stranica. Ništa od toga ne možete procijeniti bez pokretanja stvarnog preglednika, interakcije sa stranicom onako kako bi to učinio čovjek i bilježenja onoga što se zapravo događa na mrežnoj razini.

Ovaj članak opisuje kako smo izgradili mehanizam za skeniranje koji stoji iza GDPR Monitora, inženjerske izazove koji su zauzeli većinu našeg vremena, arhitektonske odluke koje smo donijeli i zašto, te ograničenja o kojima smo iskreni. Ako radite na usklađenosti weba, automatizaciji preglednika ili mjerenju weba velikih razmjera, ovdje bi trebalo biti nešto korisno za vas.

Pregled pipeline-a

Svako skeniranje prolazi kroz šest faza. Razumijevanje pipeline-a nužan je kontekst za specifične izazove koji slijede.

Faza 1: Pokretanje i izolacija preglednika. Nova Chromium instanca pokreće se s nultim stanjem -- bez kolačića, bez localStorage-a, bez predmemorije, bez service workera. To je garancija čiste sobe koja mjerenje prije pristanka čini smislenim. Konfiguriramo standardni viewport, realistične user-agent i Accept-Language zaglavlja koja odgovaraju ciljnoj zemlji te standardne oznake preglednika. Svako skeniranje dobiva vlastiti proces preglednika; nema curenja stanja između skeniranja. Faza 2: Navigacija i snimka stanja prije pristanka. Skener navigira na ciljni URL, čeka da stranica dosegne stabilno stanje (mirna mreža, smiren DOM) i bilježi sve što se dogodilo: postavljene kolačiće, izvršene mrežne zahtjeve (s potpunim URL-om, vremenskim podacima i metapodacima odgovora), kontaktirane domene trećih strana i snimku zaslona cijele stranice. Ova snimka stanja odgovara na temeljno pitanje: što je ova web stranica učinila prije nego što je korisnik uopće imao priliku pristati? Faza 3: Detekcija CMP-a i identifikacija bannera. Skener pokušava identificirati platformu za upravljanje pristankom i locirati banner za pristanak, gumb za prihvaćanje i gumb za odbijanje. Za to se koristi slojeviti sustav detekcije detaljno opisan u nastavku. Faza 4: Interakcija s pristankom. Skener komunicira s bannerom -- klika prihvati za standardni tok, klika odbij za test toka odbijanja. Čeka da se stranica smiri nakon interakcije, uzimajući u obzir animacije, ponovnu evaluaciju skripti i odgođeno pokretanje oznaka. Faza 5: Snimka stanja nakon pristanka i diferencijalna analiza. Druga potpuna snimka bilježi stanje nakon interakcije s pristankom. Usporedba snimki prije i nakon pristanka otkriva što se promijenilo: novi kolačići, novi zahtjevi za praćenje, stanje pristanka u CMP API-jima. Faza 6: Analiza, klasifikacija i generiranje izvješća. Sirovi podaci ulaze u module za analizu: klasifikacija kolačića prema našoj bazi podataka, podudaranje trackera prema poznatim obrascima, evaluacija trajanja kolačića, revizija pristupačnosti bannera, validacija Google Consent Modea, detekcija signala otiskivanja i bodovanje rizika. Izlaz je strukturirano izvješće s nalazima, dokaznim artefaktima i kompozitnom ocjenom rizika.

Svaka faza proizvodi vremenski označene dokaze koji se trajno pohranjuju. Svaki nalaz može se pratiti unatrag do specifičnih mrežnih zahtjeva, unosa kolačića ili snimki zaslona.

Izazov 1: Detekcija CMP-a -- 45 platformi, beskonačne varijacije

Upravljanje pristankom nije standardizirano. Ne postoji univerzalni HTML atribut, niti obavezni JavaScript API, niti dosljedna DOM struktura koja kaže "ovo je banner za pristanak." U našoj biblioteci za detekciju postoji 45 različitih CMP-ova, svaki sa svojom DOM strukturom, potpisima skripti, JavaScript globalima i obrascima interakcije. Povrh toga, 34,7% bannera koje smo detektirali u našoj studiji od 97.304 stranica bili su generički ili neidentificirani -- prilagođene implementacije, regionalni dobavljači ili minimalna rješenja koja ne odgovaraju nijednom poznatom CMP potpisu.

Naša detekcija koristi pristup temeljen na povjerenju, slojevit pristup:

Sloj 1: Detekcija potpisa skripti

Skener provjerava prisutnost poznatih CMP skripti prema obrascu URL-a i JavaScript globalnim varijablama. Cookiebot, na primjer, učitava se s `consent.cookiebot.com` i izlaže `window.Cookiebot`. OneTrust učitava se s `cdn.cookielaw.org` i izlaže `window.OneTrust`. Svaki CMP ima karakteristične obrasce učitavanja koji se mogu detektirati prije pregledavanja DOM-a.

Ovaj sloj je brz i visokog povjerenja kada se podudara. Ali ima kritično ograničenje: govori vam koji CMP je prisutan na stranici, ali ne nužno koji CMP je odgovoran za banner pristanka. Stranica može učitavati PiwikPRO za analitiku (koji uključuje CMP komponentu) dok koristi tarteaucitron za stvarno upravljanje pristankom. Detektirati obje skripte je lako; znati koja kontrolira banner je teže.

Sloj 2: Podudaranje verificiranih selektora

Za svaki poznati CMP održavamo kuriran skup CSS selektora koji pouzdano identificiraju kontejner bannera, gumb za prihvaćanje i gumb za odbijanje. To su selektori koje smo validirali kroz više verzija i konfiguracija svakog CMP-a. Kada je CMP detektiran u sloju 1 i njegovi verificirani selektori odgovaraju elementima u DOM-u, imamo visoko povjerenje i u identifikaciju CMP-a i u ciljeve interakcije s bannerom.

Sloj 3: Podudaranje kompatibilnih selektora

Širi skup selektora koji funkcionira kroz mnoge verzije CMP-a, ali je manje precizan. Pokriva slučajeve kada je CMP prilagođen, stiliziran ili pokreće verziju koju naši verificirani selektori ne pokrivaju. Žrtvuju preciznost za pokrivenost.

Sloj 4: Generičke heuristike

Za 34,7% bannera koji nisu povezani s poznatim CMP-om, vraćamo se na heurističku detekciju. Skener traži:

• Elemente s fiksnom ili ljepljivom pozicijom blizu dna ili vrha viewporta
• Elemente koji sadrže ključne riječi vezane uz pristanak na više jezika ("cookies," "consent," "privacy," "akzeptieren," "accepter," "aceptar" itd.)
• Gumbe s uobičajenim oznakama radnji pristanka ("Accept All," "Reject All," "Manage Preferences" i ekvivalente)
• Strukturalne obrasce tipične za dijaloge pristanka: pozadine preklapanja, modalne kontejnere, gumbe za zatvaranje

Ovaj sloj hvata mnoge prilagođene implementacije, ali je inherentno manje pouzdan. Fiksno pozicionirani promotivni banner ili prijava za newsletter može strukturalno izgledati slično dijalogu pristanka.

Sloj 5: Ispitivanje CMP API-ja

Neki CMP-ovi izlažu JavaScript API-je -- ponajviše IAB Transparency and Consent Framework (TCF) API putem `__tcfapi`. Ispitujemo ove API-je kako bismo verificirali detekciju CMP-a i pročitali programsko stanje pristanka, koje kasnije uspoređujemo s uočenim ponašanjem preglednika.

Model povjerenja

Umjesto da tretiramo detekciju kao binarnu (pronađeno/nije pronađeno), dodijeljujemo ocjene povjerenja na temelju toga koji slojevi su se podudarili i koliko snažno. Stranica na kojoj detektiramo CMP skriptu, podudarimo verificirane selektore i pronađemo TCF API dobiva visoko povjerenje. Stranica na kojoj su se aktivirale samo generičke heuristike dobiva niže povjerenje. Ova ocjena povjerenja ulazi u našu klasifikaciju rizika -- niže povjerenje detekcije znači da je veća vjerojatnost da će nalazi biti klasificirani kao neodređeni, a ne definitivni.

Model povjerenja je razlog zašto pogrešna identifikacija CMP-a, premda se događa, ne iskrivljuje sustavno naše rezultate. Kada je detekcija dvosmislena, to i kažemo, umjesto da forsirano klasificiramo.

Izazov 2: Tok odbijanja -- Zašto je "klikni i provjeri" iznenađujuće teško

Testiranje gumba za odbijanje zvuči jednostavno: pronađite ga, kliknite ga, provjerite jesu li kolačići nestali. U praksi je svaki korak prepun problema s vremenskim rasporedom, asinkronim ponašanjem i specifičnostima platforme.

Pronalaženje gumba za odbijanje. Nisu svi gumbi za odbijanje označeni kao "Odbij." Mogu reći "Odbaci sve," "Odbij," "Samo potrebni kolačići," "Upravljaj postavkama" (vodeći na drugi sloj gdje je odbijanje moguće), ili ekvivalente na bilo kojem od desetaka jezika. Neki CMP-ovi smještaju opciju odbijanja na drugu vizualnu lokaciju, u drugačijoj veličini ili drugačijoj boji od opcije prihvaćanja. Neki je skrivaju iza poveznice "Više opcija" ili "Prilagodi." Naš skener održava višejezični skup obrazaca radnji odbijanja i također detektira opcije odbijanja u drugom sloju gdje prvi sloj nudi samo prihvaćanje i prilagodbu. Čekanje pravog trenutka. Nakon klika na odbij, stranica može proći značajne promjene: banner se zatvara (često s animacijom), CMP pokreće povratne pozive stanja pristanka, tag manageri ponovo evaluiraju svoja pravila, a skripte se mogu učitati ili ukloniti. Provjera kolačića prerano uhvati stanje usred tranzicije. Provjera prekasno propušta prolazno praćenje koje se pokrene i brzo dovrši. Koristimo čekanje na više signala: mirnu mrežu, stabilnost DOM-a i minimalni vremenski prag, podešeno empirijskim testiranjem kroz stotine CMP konfiguracija. Test ponovnog učitavanja i consent respawn. Korak ponovnog učitavanja je ono što je otkrilo consent respawn kao fenomen. Nismo ga namjeravali pronaći -- naš originalni test toka odbijanja provjeravao je samo neposredno stanje nakon odbijanja. Ali tijekom razvoja primijetili smo stranice koje su izgledale čisto nakon odbijanja, ali su imale kolačiće za praćenje kada smo provjerili ponovo nakon ponovnog učitavanja stranice. Prvotno ispravljanje pogrešaka pretpostavilo je problem s vremenskim rasporedom skenera. Daljnja istraga potvrdila je da je stvarno: skripte trećih strana koje ponovno postavljaju kolačiće pri učitavanju stranice bez obzira na stanje pristanka.

Dodali smo eksplicitnu detekciju respawna u pipeline: nakon toka odbijanja, skener ponovno učitava stranicu, čeka stabilnost i uspoređuje inventar kolačića sa snimkom stanja nakon odbijanja. Svaki kolačić koji je uklonjen odbijanjem, a pojavi se ponovo nakon ponovnog učitavanja, označava se kao respawn. Time smo uhvatili 1.642 stranice s 4.932 kolačića koji se vraćaju -- nalaz koji bi bio nevidljiv bez koraka ponovnog učitavanja.

`waitForScriptIdentifiedCMP` ispitivanje. Neki CMP-ovi učitavaju se asinkrono i ne prikazuju svoj banner do nekoliko sekundi nakon početnog učitavanja stranice. Ako skener nastavi na korak odbijanja prije nego što se CMP inicijalizira, ili potpuno propušta banner ili komunicira s djelomično učitanim korisničkim sučeljem. Implementirali smo mehanizam ispitivanja koji čeka da JavaScript API CMP-a postane dostupan (npr. `__tcfapi` za CMP-ove temeljene na TCF-u, `Cookiebot` globalna varijabla za Cookiebot) prije nego što nastavi. Ovo dodaje kašnjenje po skeniranju, ali značajno smanjuje lažno negativne rezultate od asinkronog učitavanja CMP-a.

Izazov 3: Zasićenost pipeline-a u velikom opsegu

Skeniranje 97.304 web stranice nije posao za jedno računalo. Svako skeniranje pokreće Chromium proces, navigira na web stranicu, presreće i klasificira stotine mrežnih zahtjeva, snima više snimki zaslona i pokreće module za analizu. Jedno skeniranje traje 30-90 sekundi ovisno o složenosti stranice. S 15 istovremenih skeniranja po radniku, upravljanje resursima postaje primarni inženjerski izazov.

Arhitektura semafora

Koristimo model konkurentnosti temeljen na semaforima za ograničavanje broja istovremenih Chromium procesa po radniku. Svaki radnik ima fiksni semafor (15 mjesta u našoj produkcijskoj konfiguraciji). Skeniranje zauzima mjesto prije pokretanja preglednika i oslobađa ga po završetku. To sprečava iscrpljivanje memorije -- 15 Chromium instanci s potpunim presretanjem zahtjeva već troši značajnu količinu RAM-a -- i pruža protupritisak prema Redis redu.

Izuzetak za zahtjev dokumenta

U ranom razvoju naišli smo na problem propusnosti: naša logika presretanja zahtjeva (koja pregledava svaki zahtjev radi SSRF sigurnosti -- blokirajući zahtjeve prema privatnim IP rasponima, internim mrežama i drugim potencijalno opasnim ciljevima) dodavala je kašnjenje svakom učitavanju resursa, uključujući glavni zahtjev dokumenta. Budući da je URL dokumenta već validiran prije početka skeniranja, dodali smo brzi put zaobilaženja: zahtjevi tipa dokument prema prethodno validiranom ciljnom URL-u preskaču puni pipeline presretanja. Ova naizgled mala optimizacija imala je značajan utjecaj na ukupnu propusnost jer zahtjev dokumenta blokira sve ostalo.

DNS predgrijavanje

Prvi zahtjev prema novoj domeni uključuje DNS pretragu, što na našoj infrastrukturi može dodati 50-200ms po domeni. S prosječnom stranicom koja kontaktira 10,4 domene trećih strana (a neke do 171), vrijeme DNS rezolucije značajno se akumuliralo. Implementirali smo DNS predgrijavanje koristeći lokalni Unbound DNS resolver cache: prije svakog skeniranja, razrješujemo ciljnu domenu i zagrijavamo cache. Unbound instanca servira predmemorirane odgovore za naknadne pretrage unutar skeniranja, smanjujući DNS overhead po domeni na ispod milisekunde.

SSRF sigurnost u velikom opsegu

Svaki zahtjev koji skener presretne provjerava se prema skupu sigurnosnih pravila prije nego što mu se dopusti nastavak. Zahtjevi prema privatnim IP rasponima (RFC 1918, RFC 4193, link-local, loopback) blokiraju se. To sprečava zlonamjernu ciljnu stranicu da koristi skener kao SSRF vektor za ispitivanje internih mreža.

Izazov u velikom opsegu bio je razlikovanje pravih SSRF blokada od zasićenosti semafora. Kada je svih 15 mjesta semafora u upotrebi i skeniranje ne može zauzeti mjesto, rezultirajući timeout površno izgleda slično zahtjevu blokiranom iz sigurnosnih razloga. Dodali smo eksplicitnu kategorizaciju pogrešaka za razlikovanje "blokirano jer se cilj razriješio u privatni IP" od "blokirano jer je skener na kapacitetu." To je bilo bitno za operativni nadzor i za točnu klasifikaciju neuspjeha skeniranja.

Izazov 4: Detekcija izbjegavanja botova

Tijekom studije identificirali smo 137 web stranica koje namjerno skrivaju svoj banner za pristanak od automatiziranih skenera. Banner se servira ljudskim posjetiteljima, ali se potiskuje kada stranica detektira karakteristike automatiziranog pregledavanja.

Najčešći mehanizam koji smo identificirali uključuje opciju konfiguracije `isAcceptAllForBots` WordPress dodatka RCB (Real Cookie Banner). Kada je omogućena, ova postavka detektira automatizirane preglednike (putem `navigator.webdriver`, heuristika user-agenta ili bihevioralnih signala) i automatski prihvaća pristanak u njihovo ime ili u potpunosti skriva banner. Namjera, kako je dokumentirano od strane dodatka, je spriječiti da se automatiziranim posjetiteljima servira dijalog pristanka s kojim ne mogu smisleno komunicirati. Učinak je da skeneri usklađenosti -- i regulatorni revizori koji koriste automatizirane alate -- vide stranicu koja nema mehanizam pristanka, dok ljudski posjetitelji vide potpuni banner za pristanak.

Ovo je problem transparentnosti. Ako je mehanizam pristanka web stranice vidljiv samo ljudskim posjetiteljima, ne može se revidirati u velikom opsegu. Ove stranice posebno označavamo u našim rezultatima jer je nalaz kvalitativno drugačiji od "banner nije detektiran." Stranica ima banner; bira da nam ga ne pokaže.

Detekciju izbjegavanja botova vršimo kombinacijom signala: prisutnost poznate konfiguracije detekcije botova u CMP postavkama (dostupne putem JavaScript inspekcije), nepodudarnosti između onoga što DOM prikazuje i onoga što CMP-ov API prijavljuje, te u nekim slučajevima usporedbom rezultata automatiziranog skeniranja s ručnom verifikacijom.

Brojka od 137 zasigurno je podcjenjivanje. Izbjegavanje botova možemo detektirati samo kada možemo identificirati mehanizam. Stranice koje koriste sofisticiraniju ili prilagođenu detekciju botova mogu uspješno izbjeći i naš skener i našu detekciju izbjegavanja.

Izazov 5: Pogrešna identifikacija CMP-a

Stranica može učitavati više skripti koje izgledaju kao platforme za upravljanje pristankom. PiwikPRO uključuje CMP komponentu, ali je primarno analitički paket. Neke WordPress stranice učitavaju Complianz uz poseban analitički dodatak koji ima značajke nalik CMP-u. Poslovne stranice mogu imati ostatke prethodnog CMP-a koji se još uvijek učitavaju uz trenutni.

Naivna detekcija -- "ako vidimo skriptu, to je CMP" -- proizvodi lažne identifikacije koje se kaskadno prenose na netočnu interakciju s bannerom. Ako skener identificira PiwikPRO kao CMP i pokuša koristiti PiwikPRO-ove selektore bannera, može propustiti stvarni tarteaucitron banner koji kontrolira pristanak na stranici.

Naš pristup temeljen na povjerenju rješava ovo rangiranjem CMP kandidata. Kada se detektira više potencijalnih CMP-ova:

1. Provjeravamo koji ima vidljivi banner u DOM-u (skripta prisutna, ali bez bannera znači vjerojatno neaktivna ili ne-CMP upotreba).

2. Provjeravamo koji izlaže aktivni CMP API (npr. funkcionalan `__tcfapi` ili ekvivalent).

3. Preferiramo CMP čiji se verificirani selektori podudaraju s vidljivim DOM elementima nad onim koji je detektiran samo prema URL-u skripte.

Ova heuristika nije savršena, ali je riješila najčešće slučajeve pogrešne identifikacije na koje smo naišli tijekom razvoja i testiranja.

Ograničenja

Nijedan automatizirani skener ne replicira savršeno svako ljudsko iskustvo pregledavanja. Ovo su poznata ograničenja:

Banneri ovisni o GeoIP-u. Neki CMP-ovi, osobito CookieYes, serviraju različita iskustva pristanka na temelju geolokacije IP adrese posjetitelja. Naša skeniranja potječu s određenih mrežnih lokacija u Europi. Stranica koja prikazuje banner za pristanak posjetiteljima iz Francuske, ali ne posjetiteljima izvan EU-a, pokazat će različite rezultate ovisno o podrijetlu skeniranja. Trenutno ne skeniramo svaku stranicu iz svake zemlje EU-a. Zatvoreni shadow DOM. Neki CMP-ovi prikazuju svoj banner unutar zatvorenog shadow DOM-a, koji je nedostupan standardnim DOM upitima putem `document.querySelector`. Transcendov CMP koristi ovaj pristup. Naš skener može detektirati shadow host element, ali ne može pregledati njegov sadržaj kako bi pronašao gumbe za prihvaćanje/odbijanje. Te stranice obično završavaju kao neodređene u našim rezultatima. Dinamička imena klasa i obfuskacija. Neki CMP-ovi, osobito Admiral, koriste dinamički generirana imena klasa koja se mijenjaju pri svakom učitavanju stranice. Detekcija temeljena na selektorima ne uspijeva jer selektori nisu stabilni kroz posjete. Vraćamo se na generičke heuristike, ali povjerenje je niže. Jednostranične aplikacije. SPA-ovi koji upravljaju stanjem pristanka u potpunosti u JavaScript-u na strani klijenta i učitavaju mehanizam pristanka nakon početnih promjena ruta (umjesto pri početnom učitavanju stranice) teže su za procjenu. Naš skener navigira na URL i čeka da se stranica stabilizira, ali ne simulira navigaciju unutar aplikacije. Banner za pristanak koji se pojavljuje tek nakon što korisnik navigira unutar SPA-a može biti propušten. Pokrivenost jezika. Naša detekcija gumba za odbijanje koristi podudaranje teksta na skupu podržanih jezika, ali ne pokrivamo svaki jezik EU-a jednako. Banner na malteškom ili estonskom može imati oznake gumba za odbijanje koje naše podudaranje teksta ne prepoznaje, što dovodi do propuštanja testiranja toka odbijanja (premda sam banner može još uvijek biti detektiran strukturalnim heuristikama). Rubni slučajevi vremenskog rasporeda. Skripta koja se pokrene 30 sekundi nakon učitavanja stranice bit će propuštena skeniranjem koje čeka 15 sekundi na mirnu mrežu. Koristimo velikodušne vremenske pragove, ali dugi rep asinkronog ponašanja inherentno je teško potpuno uhvatiti.

Ova ograničenja doprinose našoj stopi neodređenosti od 14,9%.

Infrastruktura

Produkcijska infrastruktura za skeniranje sastoji se od:

• Mehanizam skenera: Go aplikacija koja koristi chromedp kao CDP klijent za automatizaciju Chromiuma. Go je odabran zbog svog modela konkurentnosti (goroutine i kanali prirodno se preslikavaju na paralelnu orkestraciju skeniranja), svojih karakteristika performansi i jednostavnosti implementacije (jedna statička binarna datoteka).
• Runtime preglednika: Headless Chromium koji se pokreće po skeniranju putem CDP-a. Svako skeniranje dobiva svjež proces preglednika bez dijeljenog stanja.
• Red: Redis-om podržan radni red koji distribuira URL-ove radnicima skenera. Redis upravlja distribucijom poslova, praćenjem napretka i ograničavanjem brzine.
• Baza podataka: PostgreSQL za trajne rezultate skeniranja, nalaze, metapodatke dokaza i sve strukturirane podatke. Skeniranja, nalazi, kolačići, zahtjevi i izlazi analiza pohranjuju se relacijski.
• DNS cache: Lokalni Unbound resolver koji pruža predmemorirane DNS pretrage i SSRF-sigurnu rezoluciju.
• Pohrana dokaza: Snimke zaslona, HAR datoteke i PDF izvješća pohranjuju se kao trajni artefakti povezani sa zapisima skeniranja.

Za studiju od 97.304 stranice obradili smo 114.748 kandidatskih URL-ova (97.304 uspješno dovršenih) tijekom otprilike 2,5 dana koristeći 3 poslužiteljske instance koje paralelno pokreću radnike skenera. Svaki poslužitelj pokretao je više radnih procesa s 15 istovremenih mjesta za skeniranje po procesu. Vršna propusnost bila je otprilike 25-30 dovršenih skeniranja po minuti po poslužitelju.

Primarno usko grlo nije bio CPU ni memorija, nego mreža: svako skeniranje generira stotine odlaznih zahtjeva (prema ciljnoj stranici i njenim resursima trećih strana), a agregatna propusnost i broj veza kroz sva istovremena skeniranja zasitili su dostupni mrežni kapacitet prije nego što su ostali resursi bili iscrpljeni.

Otvoreni izazovi i budući rad

Nekoliko problema ostaje neriješeno ili djelomično riješeno:

Lokalizacija bannera za pristanak. Naše podudaranje teksta pokriva glavne jezike EU-a, ali je nepotpuno za manje jezične zajednice. Proširenje pokrivenosti zahtijeva ne samo dodavanje prijevoda, nego i validaciju da selektori i obrasci interakcije ispravno funkcioniraju s lokaliziranim CMP verzijama. Longitudinalni nadzor. Naša trenutna arhitektura optimizirana je za točkasto skeniranje. Detekcija promjena u ponašanju pristanka tijekom vremena -- je li se stranica poboljšala nakon provođenja? Je li ažuriranje CMP-a popravilo klasu neuspjeha toka odbijanja? -- zahtijeva ponovljena skeniranja s diferencijalnom analizom, što je arhitektonski drugačije od jednokratne procjene. Usporedba usklađenosti CMP-ova. Imamo podatke za procjenu stopa usklađenosti po CMP-u (je li Cookiebot povezan s boljom usklađenošću od OneTrusta?), ali razdvajanje kvalitete CMP-a od kvalitete konfiguracije operatera stranice metodološki je složeno. CMP koji češće postavljaju velike tvrtke s posvećenim timovima za privatnost izgledat će bolje u agregatu čak i ako sam alat nije ništa usklađeniji. Verifikacija stanja pristanka u stvarnom vremenu. Trenutni skener radi u batch modu. Integracija verifikacije pristanka u CI/CD pipeline-e ili nadzor u stvarnom vremenu zahtijeva brži, lakši način skeniranja koji žrtvuje neku dubinu dokaza za brzinu. Istražujemo ovo.

API

Isti mehanizam skeniranja opisan u ovom članku dostupan je putem javnog API-ja GDPR Monitora. Možete programski slati zahtjeve za skeniranje, provjeravati rezultate i dohvaćati strukturirane nalaze i dokazne artefakte. API vraća iste podatke koje prikazuje naše korisničko sučelje: snimke stanja prije pristanka, popise kolačića, rezultate detekcije CMP-a, ishode toka odbijanja, ocjene rizika i potpune lance dokaza.

Ako gradite alate za usklađenost, integrirate provjere privatnosti u CI/CD pipeline-e, provodite vlastito istraživanje ili ugrađujete nadzor u program privatnosti, API pruža pristup bihevioralnoj analizi pristanka bez potrebe za izgradnjom i održavanjem vlastite infrastrukture automatizacije Chromiuma.

---

Isprobajte sami. API dokumentacija dostupna je na gdprprivacymonitor.eu/developers/api. Pošaljite jedan URL ili integrirajte automatizirani nadzor privatnosti u svoj radni tok.