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

Avtomatizirano preverjanje skladnosti privolitve zveni preprosto, dokler ga ne poskusite zgraditi. Naivni pristop -- pridobi stran, preveri piškotke, poišči pasico -- zgreši večino tistega, kar je pomembno. Kršitve privolitve so vedenjske, ne strukturne. Izražajo se v časovnem razporejanju izvajanja skript, zaporedju omrežnih zahtev, odzivu elementov uporabniškega vmesnika na interakcijo uporabnika in obstojnosti stanja med nalaganjem strani. Ničesar od tega ne morete oceniti brez zagona resničnega brskalnika, interakcije s stranjo tako, kot bi to storil človek, in beleženja, kaj se dejansko dogaja na omrežni ravni.

Ta objava opisuje, kako smo zgradili mehanizem za pregledovanje v ozadju GDPR Monitor, inženirske izzive, ki so porabili večino našega časa, arhitekturne odločitve, ki smo jih sprejeli in zakaj, ter omejitve, o katerih smo iskreni. Če delate na področju spletne skladnosti, avtomatizacije brskalnikov ali velikega obsega spletnih meritev, bi tukaj moralo biti kaj uporabnega.

Pregled cevovoda

Vsak pregled preide skozi šest faz. Razumevanje cevovoda je nujen kontekst za specifične izzive, ki sledijo.

Faza 1: Zagon brskalnika in izolacija. Svež primerek Chromium se zažene z ničelnim stanjem -- brez piškotkov, brez localStorage, brez predpomnilnika, brez delovnih procesov storitev (service worker). To je garancija čiste sobe, ki merjenje pred privolitvijo naredi smiselno. Konfiguriramo standardno okno pogleda, realistične glave user-agent in Accept-Language, ki ustrezajo ciljni državi, ter standardne zastavice brskalnika. Vsak pregled dobi lasten proces brskalnika; med pregledi ni uhajanja stanja. Faza 2: Navigacija in posnetek pred privolitvijo. Pregledovalnik navigira na ciljni URL, počaka, da stran doseže stabilno stanje (omrežje miruje, DOM se umiri), in zajame vse, kar se je zgodilo: nastavljene piškotke, izvedene omrežne zahteve (s polnim URL-jem, časovnimi podatki in metapodatki odziva), kontaktirane domene tretjih oseb in posnetek zaslona celotne strani. Ta posnetek odgovori na temeljno vprašanje: kaj je to spletno mesto naredilo, preden je imel uporabnik kakršno koli priložnost za privolitev? Faza 3: Zaznavanje CMP in identifikacija pasice. Pregledovalnik poskuša identificirati platformo za upravljanje privolitev ter poiskati pasico privolitve, gumb za sprejetje in gumb za zavrnitev. To uporablja večplastni sistem zaznave, ki je podrobno opisan spodaj. Faza 4: Interakcija s privolitvijo. Pregledovalnik komunicira s pasico -- klikne sprejmi za standardni tok, klikne zavrni za test toka zavrnitve. Počaka, da se stran po interakciji umiri, ob upoštevanju animacij, ponovne evalvacije skript in zapoznelega proženja oznak. Faza 5: Posnetek po privolitvi in diferencialna analiza. Drugi polni posnetek zajame stanje po interakciji s privolitvijo. Primerjava posnetkov pred in po privolitvi razkrije, kaj se je spremenilo: novi piškotki, nove sledilne zahteve, stanje privolitve v API-jih CMP. Faza 6: Analiza, razvrstitev in generiranje poročila. Surovi podatki se stekajo v analitične module: razvrstitev piškotkov glede na našo bazo podatkov, ujemanje sledilnikov z znanimi vzorci, evalvacija življenjske dobe piškotkov, revizija dostopnosti pasice, validacija Google Consent Mode, zaznavanje signalov prstnega odtisa in ocena tveganja. Rezultat je strukturirano poročilo z ugotovitvami, dokaznimi artefakti in sestavljeno oceno tveganja.

Vsaka faza proizvede časovno označene dokaze, ki so trajno shranjeni. Vsako ugotovitev je mogoče izslediti do specifičnih omrežnih zahtev, vnosov piškotkov ali posnetkov zaslona.

Izziv 1: Zaznavanje CMP -- 45 platform, neskončne različice

Upravljanje privolitve ni standardizirano. Ne obstaja univerzalni atribut HTML, noben obvezen API JavaScript, nobena konsistentna struktura DOM, ki bi rekla "to je pasica privolitve." V naši knjižnici za zaznavanje je 45 različnih CMP-jev, vsak s svojo strukturo DOM, podpisi skript, globalnimi spremenljivkami JavaScript in vzorci interakcije. Poleg teh je bilo 34,7 % pasic, ki smo jih zaznali v naši študiji 97.304 mest, generičnih ali neidentificiranih -- prilagojene implementacije, regionalni ponudniki ali minimalne rešitve, ki se ne ujemajo z nobenim znanim podpisom CMP.

Naše zaznavanje uporablja pristop na podlagi zaupanja z več plastmi:

Plast 1: Zaznavanje podpisov skript

Pregledovalnik preveri prisotnost znanih skript CMP po vzorcu URL in globalnih spremenljivkah JavaScript. Cookiebot se na primer naloži s `consent.cookiebot.com` in izpostavi `window.Cookiebot`. OneTrust se naloži s `cdn.cookielaw.org` in izpostavi `window.OneTrust`. Vsak CMP ima značilne vzorce nalaganja, ki jih je mogoče zaznati pred pregledom DOM.

Ta plast je hitra in visoko zanesljiva, ko se ujema. Ima pa ključno omejitev: pove vam, kateri CMP je prisoten na strani, ne pa nujno, kateri CMP je odgovoren za pasico privolitve. Mesto bi lahko naložilo PiwikPRO za analitiko (ki vključuje komponento CMP), medtem ko za dejansko upravljanje privolitve uporablja tarteaucitron. Zaznati obe skripti je enostavno; vedeti, katera nadzoruje pasico, je težje.

Plast 2: Ujemanje preverjenih izbirnikov

Za vsak znan CMP vzdržujemo kuratiran nabor CSS izbirnikov, ki zanesljivo identificirajo vsebnik pasice, gumb za sprejetje in gumb za zavrnitev. To so izbirniki, ki smo jih preverili prek več različic in konfiguracij vsakega CMP-ja. Ko je CMP zaznan v 1. plasti in se njegovi preverjeni izbirniki ujemajo z elementi v DOM, imamo visoko zaupanje tako v identifikacijo CMP kot v cilje interakcije s pasico.

Plast 3: Ujemanje združljivih izbirnikov

Širši nabor izbirnikov, ki deluje prek mnogih različic CMP-ja, a je manj natančen. Ti obravnavajo primere, ko je bil CMP prilagojen, tematsko oblikovan ali teče na različici, ki je naši preverjeni izbirniki ne pokrivajo. Žrtvujejo natančnost za pokritost.

Plast 4: Generične hevristike

Za 34,7 % pasic, ki niso povezane z znanim CMP-jem, se vrnemo na hevristično zaznavanje. Pregledovalnik išče:

• Elemente s fiksnim ali lepljivim položajem blizu dna ali vrha okna pogleda
• Elemente, ki vsebujejo ključne besede, povezane s privolitvijo, v več jezikih ("cookies," "consent," "privacy," "akzeptieren," "accepter," "aceptar" itd.)
• Gumbe s pogostimi oznakami dejanj privolitve ("Accept All," "Reject All," "Manage Preferences" in ustrezniki)
• Strukturne vzorce, tipične za dialoge privolitve: prekrivna ozadja, modalni vsebniki, gumbi za zaprtje

Ta plast ujame mnoge prilagojene implementacije, a je sama po sebi manj zanesljiva. Promocijska pasica s fiksnim položajem ali prijava na glasilo lahko strukturno izgledata podobno kot dialog privolitve.

Plast 5: Poizvedovanje API CMP

Nekateri CMP-ji izpostavljajo API-je JavaScript -- najbolj opazno API IAB Transparency and Consent Framework (TCF) prek `__tcfapi`. Poizvedujemo po teh API-jih tako za preverjanje zaznave CMP kot za branje programskega stanja privolitve, ki ga pozneje primerjamo z opazovanim vedenjem brskalnika.

Model zaupanja

Namesto da bi zaznavanje obravnavali kot binarno (najdeno/ni najdeno), dodelimo ocene zaupanja na podlagi tega, katere plasti so se ujemale in kako močno. Mesto, kjer zaznamo skripto CMP, se ujemajo preverjeni izbirniki in najdemo API TCF, dobi visoko zaupanje. Mesto, kjer so se sprožile le generične hevristike, dobi nižje zaupanje. Ta ocena zaupanja se vključi v našo razvrstitev tveganja -- nižje zaupanje zaznave pomeni, da je bolj verjetno, da bodo ugotovitve razvrščene kot nedoločne namesto dokončne.

Model zaupanja je razlog, da napačna identifikacija CMP, čeprav se pojavlja, sistematično ne pristranski naših rezultatov. Ko je zaznavanje dvoumno, to povemo, namesto da bi vsilili razvrstitev.

Izziv 2: Tok zavrnitve -- zakaj je "klikni in preveri" presenetljivo zahtevno

Testiranje gumba za zavrnitev zveni preprosto: poiščite ga, kliknite ga, preverite, ali so piškotki izginili. V praksi je vsak korak poln časovnih težav, asinhronega vedenja in platformsko specifičnih posebnosti.

Iskanje gumba za zavrnitev. Vsi gumbi za zavrnitev niso označeni z "Zavrni." Lahko piše "Zavrni vse," "Odkloni," "Samo nujni piškotki," "Upravljaj nastavitve" (kar vodi do druge plasti, kjer je zavrnitev mogoča) ali ustrezniki v katerem koli od številnih jezikov. Nekateri CMP-ji postavijo možnost zavrnitve na drugačno vizualno lokacijo, v drugačni velikosti ali v drugačni barvi kot možnost sprejetja. Nekateri jo skrijejo za povezavo "Več možnosti" ali "Prilagodi." Naš pregledovalnik vzdržuje večjezični nabor vzorcev dejanj zavrnitve in prav tako zaznava možnosti zavrnitve na drugi plasti, kjer prva plast ponuja le sprejetje in prilagoditev. Čakanje na pravi trenutek. Po kliku na zavrni se stran lahko bistveno spremeni: pasica se zapre (pogosto z animacijo), CMP sproži povratne klice stanja privolitve, upravljalniki oznak ponovno evalvirajo svoja pravila, skripte pa se lahko naložijo ali odstranijo. Če piškotke preverite prezgodaj, ujamete stanje sredi prehoda. Če preverite prepozno, zamudite prehodno sledenje, ki se sproži in hitro zaključi. Uporabljamo večsignalno čakanje: mirovanje omrežja, stabilnost DOM in minimalno talno zakasnitev, uglašeno na podlagi empiričnega testiranja na stotinah konfiguracij CMP. Test ponovnega nalaganja in ponovna oživitev privolitve. Korak ponovnega nalaganja je tisto, kar je razkrilo ponovno oživitev privolitve kot pojav. Nismo ga iskali -- naš prvotni test toka zavrnitve je preverjal le takojšnje stanje po zavrnitvi. Med razvojem pa smo opazili mesta, ki so izgledala čista po zavrnitvi, a so imela sledilne piškotke, ko smo ponovno preverili po ponovnem nalaganju strani. Prvotno odpravljanje napak je predpostavilo časovno težavo pregledovalnika. Nadaljnja preiskava je potrdila, da je resnično: skripte tretjih oseb ponovno nastavljajo piškotke ob nalaganju strani ne glede na stanje privolitve.

V cevovod smo dodali eksplicitno zaznavanje ponovne oživitve: po toku zavrnitve pregledovalnik ponovno naloži stran, počaka na stabilnost in primerja popis piškotkov s posnetkom po zavrnitvi. Vsak piškotek, ki je bil z zavrnitvijo odstranjen in se po ponovnem nalaganju znova pojavi, je označen kot ponovna oživitev. To je ujelo 1.642 mest s 4.932 ponovno oživljenimi piškotki -- ugotovitev, ki bi brez koraka ponovnega nalaganja bila nevidna.

Poizvedba `waitForScriptIdentifiedCMP`. Nekateri CMP-ji se nalagajo asinhrono in svoje pasice ne prikažejo do nekaj sekund po začetnem nalaganju strani. Če pregledovalnik nadaljuje s korakom zavrnitve, preden se CMP inicializira, pasico bodisi povsem zgreši bodisi komunicira z delno naloženim uporabniškim vmesnikom. Implementirali smo mehanizem poizvedovanja, ki čaka, da API JavaScript CMP-ja postane dostopen (npr. `__tcfapi` za CMP-je na osnovi TCF, globalni `Cookiebot` za Cookiebot), preden nadaljuje. To dodaja zakasnitev na pregled, a bistveno zmanjša lažne negativne rezultate zaradi asinhronega nalaganja CMP.

Izziv 3: Nasičenost cevovoda v velikem obsegu

Pregledovanje 97.304 spletnih mest ni delo za en sam stroj. Vsak pregled zažene proces Chromium, navigira na spletno mesto, prestreže in razvrsti stotine omrežnih zahtev, naredi več posnetkov zaslona in zažene analitične module. En sam pregled traja 30-90 sekund, odvisno od zahtevnosti mesta. Pri 15 sočasnih pregledih na delavca postane upravljanje virov primarna inženirska skrb.

Arhitektura semaforja

Uporabljamo model sočasnosti na osnovi semaforja za omejitev števila hkratnih procesov Chromium na delavca. Vsak delavec ima fiksen semafor (15 mest v naši produkcijski konfiguraciji). Pregled pridobi mesto pred zagonom brskalnika in ga sprosti ob zaključku. To preprečuje izčrpanje pomnilnika -- 15 primerkov Chromium s polnim prestrezanjem zahtev že porabi znatno količino RAM -- in zagotavlja protipritisk proti vrsti Redis.

Izjema zahteve dokumenta

Na začetku razvoja smo naleteli na težavo s pretočnostjo: naša logika prestrezanja zahtev (ki vsako zahtevo preverja glede varnosti SSRF -- blokira zahteve na zasebna območja IP, notranja omrežja in druge potencialno nevarne cilje) je dodajala zakasnitev vsakemu nalaganju virov, vključno z glavno zahtevo dokumenta. Ker je URL dokumenta že preverjen pred začetkom pregleda, smo dodali hitro pot: zahteve tipa dokument na predhodno preverjeni ciljni URL preskočijo celoten cevovod prestrezanja. Ta na videz majhna optimizacija je imela znaten vpliv na skupno pretočnost, ker zahteva dokumenta blokira vse ostalo.

Predgretje DNS

Prva zahteva na novo domeno sproži iskanje DNS, ki je na naši infrastrukturi lahko dodalo 50-200 ms na domeno. Ker povprečno mesto kontaktira 10,4 domen tretjih oseb (nekatera pa do 171), se je čas reševanja DNS bistveno nakopičil. Implementirali smo predgretje DNS z uporabo lokalnega predpomnilnika reševalca DNS Unbound: pred vsakim pregledom razrešimo ciljno domeno in ogrejemo predpomnilnik. Primerek Unbound servira predpomnjene odzive za nadaljnja iskanja znotraj pregleda, kar zmanjša obremenitev DNS na domeno na podmilisekundno.

Varnost SSRF v velikem obsegu

Vsaka zahteva, ki jo pregledovalnik prestreže, se pred dovoljenjem nadaljevanja preveri glede na nabor varnostnih pravil. Zahteve na zasebna območja IP (RFC 1918, RFC 4193, link-local, loopback) so blokirane. To preprečuje, da bi zlonamerno ciljno mesto pregledovalnik uporabilo kot vektor SSRF za sondiranje notranjih omrežij.

Izziv v velikem obsegu je bil razlikovanje med pristnimi blokadami SSRF in nasičenostjo semaforja. Ko je vseh 15 mest semaforja v uporabi in pregled ne more pridobiti mesta, nastala časovna omejitev na videz izgleda podobno zahtevi, blokirani iz varnostnih razlogov. Dodali smo eksplicitno kategorizacijo napak za razlikovanje med "blokirano, ker se je cilj razrešil v zasebni IP" in "blokirano, ker je pregledovalnik na polni zmogljivosti." To je bilo bistveno za operativno spremljanje in za natančno razvrščanje neuspelih pregledov.

Izziv 4: Zaznavanje izogibanja botom

Med študijo smo identificirali 137 spletnih mest, ki se zdi, da namerno skrivajo svojo pasico privolitve pred avtomatiziranimi pregledovalniki. Pasica se servira človeškim obiskovalcem, a se zatre, ko mesto zazna značilnosti avtomatiziranega brskanja.

Najpogostejši mehanizem, ki smo ga identificirali, vključuje konfiguracijo možnost `isAcceptAllForBots` vtičnika RCB (Real Cookie Banner) za WordPress. Ko je omogočena, ta nastavitev zazna avtomatizirane brskalnike (prek `navigator.webdriver`, hevristik user-agent ali vedenjskih signalov) in bodisi samodejno sprejme privolitev v njihovem imenu bodisi pasico povsem skrije. Namen, kot ga dokumentira vtičnik, je preprečiti, da bi avtomatizirani obiskovalci dobili dialog privolitve, s katerim ne morejo smiselno komunicirati. Učinek pa je, da pregledovalniki skladnosti -- in regulatorni revizorji, ki uporabljajo avtomatizirana orodja -- vidijo mesto, ki se zdi, da nima mehanizma privolitve, medtem ko človeški obiskovalci vidijo polno pasico privolitve.

To je problem preglednosti. Če je mehanizem privolitve spletnega mesta viden le človeškim obiskovalcem, ga ni mogoče revidirati v velikem obsegu. Ta mesta v naših rezultatih označujemo ločeno, ker se ugotovitev kakovostno razlikuje od "pasica ni zaznana." Mesto ima pasico; odloča se, da nam je ne pokaže.

Izogibanje botom zaznavamo s kombinacijo signalov: prisotnost znane konfiguracije za zaznavanje botov v nastavitvah CMP (dostopne prek pregleda JavaScript), neskladnosti med tem, kar kaže DOM, in tem, kar sporoča API CMP, v nekaterih primerih pa s primerjavo rezultatov avtomatiziranega pregleda z ročnim preverjanjem.

Številka 137 je zagotovo podcenjena. Izogibanje botom lahko zaznamo le, ko lahko identificiramo mehanizem. Mesta, ki uporabljajo bolj sofisticirano ali prilagojeno zaznavanje botov, morda uspešno ukanejo tako naš pregledovalnik kot naše zaznavanje izogibanja.

Izziv 5: Napačna identifikacija CMP

Mesto lahko naloži več skript, ki izgledajo kot platforme za upravljanje privolitev. PiwikPRO vključuje komponento CMP, a je primarno analitični paket. Nekatera mesta WordPress naložijo Complianz skupaj z ločenim analitičnim vtičnikom, ki ima funkcije, podobne CMP. Podjetniška mesta imajo morda ostanke prejšnjega CMP-ja, ki se še vedno nalagajo ob trenutnem.

Naivno zaznavanje -- "če vidimo skripto, je to CMP" -- proizvede napačne identifikacije, ki se razširijo v napačno interakcijo s pasico. Če pregledovalnik identificira PiwikPRO kot CMP in poskuša uporabiti izbirnike pasice PiwikPRO, morda zgreši dejansko pasico tarteaucitron, ki na mestu nadzoruje privolitev.

Naš pristop na podlagi zaupanja to naslavlja z razvrščanjem kandidatov CMP. Ko je zaznanih več potencialnih CMP-jev:

1. Preverimo, kateri ima vidno pasico v DOM (skripta prisotna, a brez pasice, pomeni verjetno neaktivno ali ne-CMP uporabo).

2. Preverimo, kateri izpostavlja aktiven API CMP (npr. delujoč `__tcfapi` ali enakovreden).

3. Prednost damo CMP-ju, čigar preverjeni izbirniki se ujemajo z vidnimi elementi DOM, pred tistim, ki je zaznan le po URL skripte.

Ta hevristika ni popolna, a je razrešila najpogostejše primere napačne identifikacije, na katere smo naleteli med razvojem in testiranjem.

Omejitve

Noben avtomatizirani pregledovalnik ne posnema popolnoma vsake izkušnje človeškega brskanja. To so znane omejitve:

Pasice, odvisne od GeoIP. Nekateri CMP-ji, zlasti CookieYes, servirajo različne izkušnje privolitve na podlagi geolociranja IP obiskovalca. Naši pregledi izvirajo iz specifičnih omrežnih lokacij v Evropi. Mesto, ki prikaže pasico privolitve obiskovalcem iz Francije, ne pa obiskovalcem od zunaj EU, bo kazalo različne rezultate glede na izvor pregleda. Trenutno ne pregledujemo vsakega mesta iz vsake države EU. Zaprti senčni DOM. Nekateri CMP-ji svojo pasico upodobijo znotraj zaprtega senčnega DOM, ki ni dostopen standardnim poizvedovanjem DOM prek `document.querySelector`. CMP Transcend uporablja ta pristop. Naš pregledovalnik lahko zazna gostiteljski element sence, a ne more pregledati njegove vsebine za iskanje gumbov za sprejetje/zavrnitev. Ta mesta se v naših rezultatih navadno končajo kot nedoločna. Dinamična imena razredov in obfuskacija. Nekateri CMP-ji, zlasti Admiral, uporabljajo dinamično generirana imena razredov, ki se ob vsakem nalaganju strani spremenijo. Zaznavanje na podlagi izbirnikov pri teh odpove, ker izbirniki niso stabilni med obiski. Vrnemo se na generične hevristike, a je zaupanje nižje. Enostranske aplikacije. Enostranske aplikacije (SPA), ki upravljajo stanje privolitve povsem v JavaScript na strani odjemalca in naložijo mehanizem privolitve šele po začetnih spremembah poti (namesto ob začetnem nalaganju strani), so težje za oceno. Naš pregledovalnik navigira na URL in čaka, da se stran stabilizira, a ne simulira navigacije znotraj aplikacije. Pasica privolitve, ki se pojavi šele po tem, ko uporabnik navigira znotraj SPA, je morda zgrešena. Pokritost jezikov. Naše zaznavanje gumbov za zavrnitev uporablja ujemanje besedila prek nabora podprtih jezikov, a ne pokrivamo vsakega jezika EU enako. Pasica v malteščini ali estonščini ima morda oznake gumbov za zavrnitev, ki jih naše ujemanje besedila ne prepozna, kar vodi do izpusta pri testiranju toka zavrnitve (čeprav je pasica sama morda še vedno zaznana s strukturnimi hevristikami). Robni primeri časovnega razporejanja. Skripta, ki se sproži 30 sekund po nalaganju strani, bo zgrešena pri pregledu, ki čaka 15 sekund na mirovanje omrežja. Uporabljamo radodarne časovne omejitve, a dolg rep asinhronega vedenja je sam po sebi težko povsem zajeti.

Te omejitve prispevajo k naši 14,9-odstotni stopnji nedoločnih rezultatov.

Infrastruktura

Produkcijska infrastruktura za pregledovanje sestoji iz:

• Mehanizem pregledovalnika: Go aplikacija, ki uporablja chromedp kot odjemalca CDP za avtomatizacijo Chromium. Go je bil izbran za svoj model sočasnosti (gorutine in kanali se naravno preslikajo na vzporedno orkestracijo pregledov), svoje zmogljivostne lastnosti in enostavnost nameščanja (ena sama statična binarna datoteka).
• Izvajalno okolje brskalnika: Headless Chromium, zagnan na pregled prek CDP. Vsak pregled dobi svež proces brskalnika z ničelnim deljenim stanjem.
• Vrsta: Delovna vrsta, podprta z Redis, ki distribuira URL-je delavcem pregledovalnika. Redis upravlja distribucijo opravil, sledenje napredku in omejevanje hitrosti.
• Baza podatkov: PostgreSQL za trajne rezultate pregledov, ugotovitve, metapodatke dokazov in vse strukturirane podatke. Pregledi, ugotovitve, piškotki, zahteve in rezultati analiz so vsi shranjeni relacijsko.
• Predpomnilnik DNS: Lokalni reševalec Unbound, ki zagotavlja predpomnjene iskanja DNS in reševanje, varno pred SSRF.
• Shranjevanje dokazov: Posnetki zaslona, datoteke HAR in poročila PDF so shranjeni kot trajni artefakti, povezani z zapisi pregledov.

Za študijo 97.304 mest smo obdelali 114.748 kandidatnih URL-jev (97.304 uspešno zaključenih) v približno 2,5 dneh z uporabo 3 strežniških primerkov, ki so vzporedno poganjali delavce pregledovalnika. Vsak strežnik je poganjal več delavnih procesov s 15 sočasnimi mesti za pregled vsakega. Najvišja pretočnost je bila približno 25-30 zaključenih pregledov na minuto na strežnik.

Primarno ozko grlo ni bil procesor ali pomnilnik, temveč omrežje: vsak pregled generira stotine odhodnih zahtev (na ciljno mesto in njegove vire tretjih oseb), skupna pasovna širina in število povezav prek vseh sočasnih pregledov pa je nasičilo razpoložljivo omrežno zmogljivost, preden so bili drugi viri izčrpani.

Odprti izzivi in prihodnje delo

Več problemov ostaja nerešenih ali delno rešenih:

Lokalizacija pasice privolitve. Naše ujemanje besedila pokriva večje jezike EU, a je nepopolno za manjše jezikovne skupnosti. Razširitev pokritosti ne zahteva le dodajanja prevodov, temveč tudi preverjanje, da izbirniki in vzorci interakcije pravilno delujejo z lokaliziranimi različicami CMP. Vzdolžno spremljanje. Naša trenutna arhitektura je optimizirana za pregled v določenem trenutku. Zaznavanje sprememb v vedenju privolitve skozi čas -- ali se je mesto izboljšalo po uveljavljanju? Ali je posodobitev CMP odpravila razred napak toka zavrnitve? -- zahteva ponavljajoče preglede z diferencialno analizo, kar je arhitekturno drugačno od enkratne ocene. Primerjalno vrednotenje skladnosti CMP. Imamo podatke za oceno stopenj skladnosti po CMP (ali je Cookiebot povezan z boljšo skladnostjo kot OneTrust?), a ločevanje kakovosti CMP od kakovosti konfiguracije upravljavca mesta je metodološko zapleteno. CMP, ki ga pogosteje nameščajo velika podjetja z namenskimi ekipami za zasebnost, bo v agregatu izgledal bolje, tudi če orodje samo ni nič bolj skladno. Preverjanje stanja privolitve v realnem času. Trenutni pregledovalnik deluje v paketnem načinu. Integracija preverjanja privolitve v cevovode CI/CD ali spremljanje v realnem času zahteva hitrejši, lažji način pregleda, ki žrtvuje nekaj globine dokazov za hitrost. To raziskujemo.

API

Isti mehanizem za pregledovanje, opisan v tej objavi, je na voljo prek javnega API-ja GDPR Monitor. Programsko lahko oddajate zahteve za pregled, poizvedujete po rezultatih ter pridobivate strukturirane ugotovitve in dokazne artefakte. API vrača enake podatke, kot jih prikazuje naš uporabniški vmesnik: posnetke pred privolitvijo, popise piškotkov, rezultate zaznave CMP, izide toka zavrnitve, ocene tveganja in popolne dokazne verige.

Če gradite orodja za skladnost, integrirate preverjanja zasebnosti v cevovode CI/CD, izvajate lastne raziskave ali vgrajujete spremljanje v program zasebnosti, API zagotavlja dostop do vedenjske analize privolitve brez potrebe po gradnji in vzdrževanju lastne infrastrukture za avtomatizacijo Chromium.

---

Preizkusite sami. Dokumentacija API-ja je na voljo na gdprprivacymonitor.eu/developers/api. Oddajte posamezen URL ali integrirajte avtomatizirano spremljanje zasebnosti v svoj delovni tok.