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

Automatizuotas sutikimo laikymosi tikrinimas skamba paprastai, kol pabandai jį sukurti. Naivus požiūris -- gauti puslapį, patikrinti slapukus, ieškoti juostos -- praleidžia didžiąją dalį to, kas svarbu. Sutikimo pažeidimai yra elgesio, ne struktūros pobūdžio. Jie pasireiškia skriptų vykdymo laiku, tinklo užklausų seka, vartotojo sąsajos elementų reakcija į naudotojo sąveiką ir būsenos išlikimu per puslapio krovimus. Nieko iš to negalite įvertinti nepaleisdami tikros naršyklės, nesąveikaudami su puslapiu taip, kaip tai darytų žmogus, ir neįrašydami, kas iš tikrųjų vyksta tinklo lygmenyje.

Šis įrašas aprašo, kaip sukūrėme skenavimo variklį, esantį už GDPR Monitor, inžinerinius iššūkius, kurie sunaudojo didžiąją dalį mūsų laiko, priimtus architektūrinius sprendimus ir kodėl, bei apribojimus, dėl kurių esame sąžiningi. Jei dirbate su žiniatinklio laikymusi, naršyklės automatizavimu ar didelio masto žiniatinklio matavimu, čia turėtų būti kažkas naudingo.

Pipeline apžvalga

Kiekvienas skenavimas praeina šešis etapus. Pipeline supratimas yra būtinas kontekstas specifiniams iššūkiams, kurie seka.

1 etapas: naršyklės paleidimas ir izoliacija. Šviežias Chromium egzempliorius startuoja su nuline būsena -- be slapukų, be localStorage, be talpyklos, be service worker. Tai yra švaraus kambario garantija, kuri suteikia prasmę matavimui prieš sutikimą. Konfigūruojame standartinį peržiūros langą, realistiškas user-agent ir Accept-Language antraštes, atitinkančias tikslinę šalį, ir standartinius naršyklės parametrus. Kiekvienas skenavimas gauna savo naršyklės procesą; tarp skenavimų nėra būsenos nutekėjimo. 2 etapas: navigacija ir momentinė kopija prieš sutikimą. Skeneris nukreipia į tikslinį URL, laukia, kol puslapis pasieks stabilią būseną (tinklas neaktyvus, DOM nusistovėjęs), ir užfiksuoja viską, kas įvyko: nustatytus slapukus, pateiktas tinklo užklausas (su pilnu URL, laiku ir atsakymo metaduomenimis), kontaktuotus trečiųjų šalių domenus ir viso puslapio ekrano kopiją. Ši momentinė kopija atsako į fundamentalų klausimą: ką ši svetainė padarė prieš naudotojui turint galimybę duoti sutikimą? 3 etapas: CMP aptikimas ir juostos identifikavimas. Skeneris bando identifikuoti sutikimo valdymo platformą ir rasti sutikimo juostą, priėmimo mygtuką ir atmetimo mygtuką. Tam naudojama sluoksniuota aptikimo sistema, detaliai aprašyta žemiau. 4 etapas: sutikimo sąveika. Skeneris sąveikauja su juosta -- spusteli priimti standartiniam srautui, spusteli atmesti atmetimo srauto testui. Jis laukia, kol puslapis nusistovės po sąveikos, atsižvelgdamas į animacijas, skriptų pervertinimą ir pavėluotą žymų paleidimą. 5 etapas: momentinė kopija po sutikimo ir diferencialinė analizė. Antra pilna momentinė kopija užfiksuoja būseną po sutikimo sąveikos. Palyginus momentines kopijas prieš sutikimą ir po jo atskleidžiama, kas pasikeitė: nauji slapukai, naujos sekimo užklausos, sutikimo būsena CMP API. 6 etapas: analizė, klasifikacija ir ataskaitos generavimas. Neapdoroti duomenys patenka į analizės modulius: slapukų klasifikacija pagal mūsų duomenų bazę, sekimo priemonių atitikimas pagal žinomus šablonus, slapukų gyvavimo trukmės vertinimas, juostos prieinamumo auditas, Google Consent Mode validacija, pirštų atspaudų signalų aptikimas ir rizikos vertinimas. Išvestis yra struktūrizuota ataskaita su radiniais, įrodymų artefaktais ir sudėtiniu rizikos balu.

Kiekvienas etapas sukuria laiko žymomis pažymėtus įrodymus, kurie saugomi ilgalaikiai. Bet kuris radinys gali būti atsektas iki konkrečių tinklo užklausų, slapukų įrašų ar ekrano kopijų.

Iššūkis 1: CMP aptikimas -- 45 platformos, begalė variacijų

Sutikimo valdymas nėra standartizuotas. Nėra universalaus HTML atributo, privalomo JavaScript API, nuoseklios DOM struktūros, kuri sakytų „tai yra sutikimo juosta." Mūsų aptikimo bibliotekoje yra 45 atskirų CMP, kiekviena su savo DOM struktūra, skriptų signatūromis, JavaScript globaliais kintamaisiais ir sąveikos šablonais. Be jų, 34,7 % juostų, kurias aptikome 97 304 svetainių tyrime, buvo bendrinės arba neatpažintos -- pritaikyti įgyvendinimai, regioniniai tiekėjai arba minimalūs sprendimai, neatitinkantys nė vienos žinomos CMP signatūros.

Mūsų aptikimas naudoja pasitikėjimu pagrįstą, sluoksniuotą metodą:

1 sluoksnis: skriptų signatūrų aptikimas

Skeneris tikrina žinomų CMP skriptų buvimą pagal URL šabloną ir JavaScript globaliuosius kintamuosius. Cookiebot, pavyzdžiui, kraunasi iš `consent.cookiebot.com` ir eksponuoja `window.Cookiebot`. OneTrust kraunasi iš `cdn.cookielaw.org` ir eksponuoja `window.OneTrust`. Kiekviena CMP turi būdingus krovimo šablonus, kuriuos galima aptikti prieš tikrinant DOM.

Šis sluoksnis yra greitas ir aukšto pasitikėjimo, kai atitinka. Bet jis turi kritinį apribojimą: jis pasako, kuri CMP yra puslapyje, bet nebūtinai kuri CMP yra atsakinga už sutikimo juostą. Svetainė gali krauti PiwikPRO analizei (kuri apima CMP komponentą), tuo pat metu naudodama tarteaucitron tikram sutikimo valdymui. Aptikti abu skriptus yra lengva; žinoti, kuris kontroliuoja juostą, yra sunkiau.

2 sluoksnis: patvirtintų selektorių atitikimas

Kiekvienai žinomai CMP turime kuruotą CSS selektorių rinkinį, kuris patikimai identifikuoja juostos konteinerį, priėmimo mygtuką ir atmetimo mygtuką. Tai yra selektoriai, kuriuos patvirtinome per kelias kiekvienos CMP versijas ir konfigūracijas. Kai CMP aptinkama 1 sluoksnyje ir jos patvirtinti selektoriai atitinka DOM elementus, turime aukštą pasitikėjimą tiek CMP identifikavimu, tiek juostos sąveikos taikiniais.

3 sluoksnis: suderinamų selektorių atitikimas

Platesnis selektorių rinkinys, veikiantis per daugelį CMP versijų, bet mažiau tikslus. Tai tvarko atvejus, kai CMP buvo pritaikyta, perdažyta arba veikia versija, kurios neapima mūsų patvirtinti selektoriai. Jie aukoja tikslumą dėl aprėpties.

4 sluoksnis: bendrinės euristikos

34,7 % juostų, nesusijusių su žinoma CMP, grįžtame prie euristinio aptikimo. Skeneris ieško:

• Fiksuotos arba lipnios padėties elementų peržiūros lango apačioje ar viršuje
• Elementų, kurių turinys apima su sutikimu susijusius raktažodžius keliomis kalbomis („cookies", „consent", „privacy", „akzeptieren", „accepter", „aceptar" ir t.t.)
• Mygtukų su dažnomis sutikimo veiksmo etiketėmis („Accept All", „Reject All", „Manage Preferences" ir atitikmenimis)
• Struktūrinių šablonų, būdingų sutikimo dialogams: perdangos fonai, modaliniai konteineriai, uždarymo mygtukai

Šis sluoksnis pagauna daugelį pritaikytų įgyvendinimų, bet yra iš esmės mažiau patikimas. Fiksuotos padėties reklaminė juosta ar naujienlaiškio registracijos forma gali atrodyti struktūriškai panašiai į sutikimo dialogą.

5 sluoksnis: CMP API tikrinimas

Kai kurios CMP eksponuoja JavaScript API -- ypač IAB Transparency and Consent Framework (TCF) API per `__tcfapi`. Mes tikname šias API tiek CMP aptikimui patvirtinti, tiek programinei sutikimo būsenai nuskaityti, kurią vėliau lyginame su stebėtu naršyklės elgesiu.

Pasitikėjimo modelis

Užuot traktavę aptikimą kaip dvejetainį (rasta / nerasta), priskiriame pasitikėjimo balus pagal tai, kurie sluoksniai atitiko ir kaip stipriai. Svetainė, kurioje aptinkame CMP skriptą, atitinkame patvirtintus selektorius ir randame TCF API, gauna aukštą pasitikėjimą. Svetainė, kurioje suveikė tik bendrinės euristikos, gauna žemesnį pasitikėjimą. Šis pasitikėjimo balas patenka į mūsų rizikos klasifikaciją -- žemesnis aptikimo pasitikėjimas reiškia, kad radiniai labiau tikėtini būti klasifikuoti kaip neapibrėžti, o ne galutiniai.

Pasitikėjimo modelis yra priežastis, kodėl CMP klaidinga identifikacija, nors ji pasitaiko, sistemiškai neiškraipo mūsų rezultatų. Kai aptikimas yra dviprasmiškas, mes tai pasakome, užuot vertę klasifikaciją.

Iššūkis 2: atmetimo srautas -- kodėl „paspausti ir patikrinti" yra stebėtinai sunku

Atmetimo mygtuko testavimas skamba paprastai: rask jį, paspausk, patikrink, ar slapukai dingo. Praktikoje kiekvienas žingsnis yra kupinas laiko problemų, asinchroninio elgesio ir platformai specifinių keistenybių.

Atmetimo mygtuko radimas. Ne visi atmetimo mygtukai pavadinti „Reject". Jie gali sakyti „Decline All", „Refuse", „Only necessary cookies", „Manage settings" (vedantis į antrą sluoksnį, kur galimas atmetimas) arba atitikmenis bet kuria iš dešimčių kalbų. Kai kurios CMP patalpina atmetimo parinktį kitoje vizualinėje vietoje, kitu dydžiu ar kita spalva nei priėmimo parinktis. Kai kurios ją slepia už „More options" ar „Customize" nuorodos. Mūsų skeneris turi daugiakalbį atmetimo veiksmo šablonų rinkinį ir taip pat aptinka antrojo sluoksnio atmetimo parinktis, kai pirmasis sluoksnis siūlo tik priėmimą ir pritaikymą. Laukimas tinkamo momento. Po atmetimo paspaudimo puslapis gali patirti reikšmingų pokyčių: juosta užsidaro (dažnai su animacija), CMP iškviečia sutikimo būsenos atgalines funkcijas, žymų valdikliai iš naujo vertina savo taisykles, o skriptai gali būti kraunami arba iškraunami. Per anksti tikrinant slapukus pagaunama pereinamoji būsena. Per vėlai tikrinant praleidžiamas trumpalaikis sekimas, kuris paleidžiamas ir greitai baigiasi. Naudojame kelių signalų laukimą: tinklo neveiksnumą, DOM stabilumą ir minimalią vėlinimo grindį, suderintą iš empirinio testavimo per šimtus CMP konfigūracijų. Perkrovimo testas ir consent respawn. Perkrovimo žingsnis yra tai, kas atskleidė consent respawn kaip reiškinį. Mes neplanavome jo rasti -- mūsų pradinis atmetimo srauto testas tikrino tik tiesioginę būseną po atmetimo. Bet kūrimo metu pastebėjome svetaines, kurios atrodė švarios po atmetimo, bet turėjo sekimo slapukus, kai patikrinome dar kartą po puslapio perkrovimo. Pradinis derinimas tarė, kad tai skenerio laiko problema. Tolesnis tyrimas patvirtino, kad tai realu: trečiųjų šalių skriptai iš naujo nustatantys slapukus puslapio krovimo metu, nepaisant sutikimo būsenos.

Pridėjome aiškų atsiradimo iš naujo aptikimą į pipeline: po atmetimo srauto skeneris perkrauna puslapį, laukia stabilumo ir lygina slapukų inventorių su momentine kopija po atmetimo. Bet kuris slapukas, pašalintas atmetimo metu ir vėl atsirandantis po perkrovimo, pažymimas kaip atsiradęs iš naujo. Tai pagavo 1 642 svetaines su 4 932 atsirandančiais iš naujo slapukais -- radinys, kuris būtų buvęs nematomas be perkrovimo žingsnio.

`waitForScriptIdentifiedCMP` apklausa. Kai kurios CMP kraunasi asinchroniškai ir nerodo savo juostos iki kelių sekundžių po pradinio puslapio krovimo. Jei skeneris pereina prie atmetimo žingsnio prieš CMP inicializaciją, jis arba praleidžia juostą visiškai, arba sąveikauja su iš dalies pakrauta vartotojo sąsaja. Įgyvendinome apklausos mechanizmą, kuris laukia, kol CMP JavaScript API taps pasiekiamas (pvz., `__tcfapi` TCF pagrįstoms CMP, `Cookiebot` globalusis kintamasis Cookiebot) prieš tęsiant. Tai prideda vėlinimą kiekvienam skenavimui, bet reikšmingai sumažina klaidingus neigiamus rezultatus dėl asinchroninio CMP krovimo.

Iššūkis 3: pipeline prisotinimas dideliu mastu

97 304 svetainių skenavimas nėra vieno kompiuterio darbas. Kiekvienas skenavimas paleidžia Chromium procesą, nukreipia į svetainę, perima ir klasifikuoja šimtus tinklo užklausų, daro kelias ekrano kopijas ir vykdo analizės modulius. Vienas skenavimas trunka 30-90 sekundžių, priklausomai nuo svetainės sudėtingumo. Su 15 lygiagrečių skenavimų viename darbuotojuje išteklių valdymas tampa pagrindine inžinerine problema.

Semaforo architektūra

Naudojame semaforu pagrįstą lygiagretumo modelį, ribojantį vienu metu veikiančių Chromium procesų skaičių kiekvienam darbuotojui. Kiekvienas darbuotojas turi fiksuotą semaforą (15 vietų mūsų gamybinėje konfigūracijoje). Skenavimas užima vietą prieš paleisdamas naršyklę ir ją atleidžia baigęs. Tai apsaugo nuo atminties išsekimo -- 15 Chromium egzempliorių su pilnu užklausų perėmimu jau sunaudoja reikšmingą RAM -- ir suteikia priešslėgį Redis eilei.

Dokumento užklausos išimtis

Ankstyvame kūrimo etape susidūrėme su pralaidumo problema: mūsų užklausų perėmimo logika (kuri tikrina kiekvieną užklausą dėl SSRF saugumo -- blokuoja užklausas į privačius IP diapazonus, vidinius tinklus ir kitus potencialiai pavojingus taikinius) pridėdavo vėlinimą kiekvienam resurso krovimui, įskaitant pagrindinę dokumento užklausą. Kadangi dokumento URL jau buvo patvirtintas prieš skenavimo pradžią, pridėjome greito kelio apėjimą: dokumento tipo užklausos į iš anksto patvirtintą tikslinį URL praleidžia pilną perėmimo pipeline. Ši iš pažiūros nedidelė optimizacija turėjo reikšmingą poveikį bendram pralaidumui, nes dokumento užklausa blokuoja viską kitą.

DNS pašildymas

Pirmoji užklausa į naują domeną sukelia DNS paiešką, kuri mūsų infrastruktūroje galėjo pridėti 50-200 ms kiekvienam domenui. Vidutinei svetainei kontaktuojant 10,4 trečiųjų šalių domenus (o kai kurioms -- iki 171), DNS resoliucijos laikas smarkiai kaupėsi. Įgyvendinome DNS pašildymą naudodami vietinę Unbound DNS resolverio talpyklą: prieš kiekvieną skenavimą resolviname tikslinį domeną ir pašildomame talpyklą. Unbound egzempliorius teikia talpyklines atsakymus tolesnėms paieškoms skenavimo metu, sumažindamas DNS pridėtinį kiekvienam domenui iki submilisekundinio.

SSRF saugumas dideliu mastu

Kiekviena skenerio perimta užklausa tikrinama pagal saugumo taisyklių rinkinį prieš leidžiant jai tęstis. Užklausos į privačius IP diapazonus (RFC 1918, RFC 4193, link-local, loopback) blokuojamos. Tai apsaugo piktavališkam tiksliniam svetainei nuo skenerio panaudojimo kaip SSRF vektoriaus vidinių tinklų tikrinimui.

Iššūkis dideliu mastu buvo atskirti tikrus SSRF blokavimus nuo semaforo prisotinimo. Kai visos 15 semaforo vietų naudojamos ir skenavimas negali užimti vietos, gautas laiko limitas iš pažiūros panašus į užklausos blokavimą dėl saugumo priežasčių. Pridėjome aiškų klaidų kategorizavimą, kad atskirtume „blokuota, nes tikslas resolvinosi į privatų IP" nuo „blokuota, nes skeneris yra pilnu pajėgumu." Tai buvo esminis operaciniam stebėjimui ir tiksliai skenavimo nesėkmių klasifikacijai.

Iššūkis 4: robotų vengimo aptikimas

Tyrimo metu identifikavome 137 svetaines, kurios, atrodo, tyčia slepia sutikimo juostą nuo automatizuotų skenerių. Juosta rodoma žmonių lankytojams, bet slopinama, kai svetainė aptinka automatizuotos naršyklės požymius.

Dažniausias mūsų identifikuotas mechanizmas apima RCB (Real Cookie Banner) WordPress papildinio `isAcceptAllForBots` konfigūracijos parinktį. Kai ji įjungta, šis nustatymas aptinka automatizuotas naršykles (per `navigator.webdriver`, user-agent euristikas arba elgesio signalus) ir arba automatiškai priima sutikimą jų vardu, arba visiškai paslepia juostą. Tikslas, kaip dokumentuoja papildinys, yra neleisti automatizuotiems lankytojams gauti sutikimo dialogo, su kuriuo jie negali prasmingai sąveikauti. Efektas yra tas, kad laikymosi skeneriai -- ir reguliuotojai, naudojantys automatizuotus įrankius -- mato svetainę, kuri atrodo neturinti sutikimo mechanizmo, kai žmonių lankytojai mato pilną sutikimo juostą.

Tai yra skaidrumo problema. Jei svetainės sutikimo mechanizmas matomas tik žmonių lankytojams, jo negalima audituoti dideliu mastu. Mes pažymime šias svetaines atskirai mūsų rezultatuose, nes radinys kokybiškai skiriasi nuo „juosta neaptikta." Svetainė turi juostą; ji pasirinko jos mums nerodyti.

Robotų vengimą aptinkame per signalų derinį: žinomų robotų aptikimo konfigūracijų buvimą CMP nustatymuose (prieinamuose per JavaScript tikrinimą), neatitikimus tarp to, ką rodo DOM, ir ką praneša CMP API, o kai kuriais atvejais -- lyginant automatizuoto skenavimo rezultatus su rankiniu patikrinimu.

137 skaičius neabejotinai yra nepilnas. Galime aptikti robotų vengimą tik tada, kai galime identifikuoti mechanizmą. Svetainės, naudojančios sudėtingesnį ar pritaikytą robotų aptikimą, gali sėkmingai apeiti tiek mūsų skenerį, tiek mūsų vengimo aptikimą.

Iššūkis 5: CMP klaidinga identifikacija

Svetainė gali krauti kelis skriptus, kurie atrodo kaip sutikimo valdymo platformos. PiwikPRO apima CMP komponentą, bet pirmiausia yra analizės rinkinys. Kai kurios WordPress svetainės krauna Complianz kartu su atskiru analizės papildiniu, turinčiu CMP tipo funkcijas. Įmonių svetainės gali turėti ankstesnės CMP likučius, vis dar kraunamus kartu su dabartine.

Naivus aptikimas -- „jei matome skriptą, tai yra CMP" -- sukuria klaidingas identifikacijas, kurios kaskadu veda į neteisingą juostos sąveiką. Jei skeneris identifikuoja PiwikPRO kaip CMP ir bando naudoti PiwikPRO juostos selektorius, jis gali praleisti tikrąją tarteaucitron juostą, kuri kontroliuoja sutikimą svetainėje.

Mūsų pasitikėjimu pagrįstas požiūris tai sprendžia rikiuodamas CMP kandidatus. Kai aptinkamos kelios potencialios CMP:

1. Tikriname, kuri turi matomą juostą DOM (skriptas yra, bet juostos nėra, reiškia greičiausiai neaktyvi arba ne CMP naudojimas).

2. Tikriname, kuri eksponuoja aktyvų CMP API (pvz., veikiantį `__tcfapi` ar atitikmenį).

3. Teikiame pirmenybę CMP, kurios patvirtinti selektoriai atitinka matomus DOM elementus, o ne tai, kuri aptikta tik pagal skripto URL.

Ši euristika nėra tobula, bet ji išsprendė dažniausius klaidingos identifikacijos atvejus, su kuriais susidūrėme kūrimo ir testavimo metu.

Apribojimai

Joks automatizuotas skeneris tobulai neatkartoja kiekvienos žmogaus naršymo patirties. Tai žinomi apribojimai:

Nuo GeoIP priklausančios juostos. Kai kurios CMP, ypač CookieYes, teikia skirtingas sutikimo patirtis pagal lankytojo IP geolokaciją. Mūsų skenavimai kyla iš konkrečių tinklo vietų Europoje. Svetainė, kuri rodo sutikimo juostą Prancūzijos lankytojams, bet ne lankytojams iš ne ES, rodys skirtingus rezultatus priklausomai nuo skenavimo kilmės. Šiuo metu neskenuojame kiekvienos svetainės iš kiekvienos ES šalies. Uždaras shadow DOM. Kai kurios CMP rodo savo juostą uždarame shadow DOM, kuris nepasiekiamas standartinėms DOM užklausoms per `document.querySelector`. Transcend CMP naudoja šį metodą. Mūsų skeneris gali aptikti shadow host elementą, bet negali patikrinti jo turinio, kad rastų priėmimo/atmetimo mygtukus. Šios svetainės paprastai baigiasi kaip neapibrėžtos mūsų rezultatuose. Dinaminiai klasių pavadinimai ir obfuskacija. Kai kurios CMP, ypač Admiral, naudoja dinamiškai generuojamus klasių pavadinimus, kurie keičiasi kiekvienu puslapio krovimu. Selektoriais pagrįstas aptikimas šiems neveikia, nes selektoriai nėra stabilūs per apsilankymus. Grįžtame prie bendrinių euristikų, bet pasitikėjimas yra žemesnis. Vieno puslapio programos. SPA, kurios valdo sutikimo būseną visiškai kliento pusės JavaScript ir krauną sutikimo mechanizmą po pradinių maršruto pakeitimų (o ne pradiniame puslapio krovime), yra sunkiau vertinamos. Mūsų skeneris nukreipia į URL ir laukia, kol puslapis stabilizuosis, bet nesimaliuoja navigacijos programos viduje. Sutikimo juosta, kuri pasirodo tik naudotojui naršant SPA viduje, gali būti praleista. Kalbų aprėptis. Mūsų atmetimo mygtuko aptikimas naudoja teksto atitikimą per palaikomų kalbų rinkinį, bet ne kiekvieną ES kalbą apimame vienodai. Juosta maltiečių ar estų kalba gali turėti atmetimo mygtuko etiketes, kurių mūsų teksto atitikimas neatpažįsta, vedant prie praleisto atmetimo srauto testavimo (nors pati juosta vis dar gali būti aptikta struktūrinėmis euristikomis). Laiko kraštutiniai atvejai. Skriptas, kuris paleidžiamas 30 sekundžių po puslapio krovimo, bus praleistas skenavimo, kuris laukia 15 sekundžių tinklo neveiksnumo. Naudojame dosnias laiko ribas, bet ilga asinchroninio elgesio uodega yra iš esmės sunkiai visiškai pagaunama.

Šie apribojimai prisideda prie mūsų 14,9 % neapibrėžto rodiklio.

Infrastruktūra

Gamybinė skenavimo infrastruktūra susideda iš:

• Skenerio variklis: Go programa, naudojanti chromedp kaip CDP klientą Chromium automatizavimui. Go buvo pasirinkta dėl savo lygiagretumo modelio (gorutinos ir kanalai natūraliai atitinka lygiagretų skenavimo orkestravimą), veikimo charakteristikų ir diegimo paprastumo (vienas statinis dvejetainis failas).
• Naršyklės vykdymo aplinka: Headless Chromium, paleidžiamas kiekvienam skenavimui per CDP. Kiekvienas skenavimas gauna šviežią naršyklės procesą su nuline bendra būsena.
• Eilė: Redis pagrįsta darbų eilė, paskirstanti URL skenerio darbuotojams. Redis tvarko darbų paskirstymą, eigos sekimą ir dažnio ribojimą.
• Duomenų bazė: PostgreSQL ilgalaikiam skenavimo rezultatų, radinių, įrodymų metaduomenų ir visų struktūrizuotų duomenų saugojimui. Skenavimai, radiniai, slapukai, užklausos ir analizės išvestys saugomos reliaciškai.
• DNS talpykla: Vietinis Unbound resolveris, teikiantis talpyklines DNS paieškas ir SSRF saugią resoliuciją.
• Įrodymų saugykla: Ekrano kopijos, HAR failai ir PDF ataskaitos saugomi kaip ilgalaikiai artefaktai, susieti su skenavimo įrašais.

97 304 svetainių tyrimui apdorojome 114 748 kandidatų URL (97 304 sėkmingai užbaigti) per maždaug 2,5 dienos, naudodami 3 serverių egzempliorius, vykdančius skenerio darbuotojus lygiagrečiai. Kiekvienas serveris vykdė kelis darbuotojų procesus su 15 lygiagrečių skenavimo vietų kiekviename. Didžiausias pralaidumas buvo maždaug 25-30 užbaigtų skenavimų per minutę kiekvienam serveriui.

Pagrindinis kliūtis buvo ne CPU ar atmintis, o tinklas: kiekvienas skenavimas generuoja šimtus išeinančių užklausų (į tikslinę svetainę ir jos trečiųjų šalių išteklius), o bendras pralaidumas ir ryšių skaičius per visus lygiagrečius skenavimus prisotino turimą tinklo pajėgumą anksčiau nei kiti ištekliai buvo išnaudoti.

Atviri iššūkiai ir ateities darbai

Keletas problemų lieka neišspręstos arba iš dalies išspręstos:

Sutikimo juostos lokalizacija. Mūsų teksto atitikimas apima pagrindines ES kalbas, bet yra nepilnas mažesnėms kalbų bendruomenėms. Aprėpties plėtimas reikalauja ne tik vertimų pridėjimo, bet ir patvirtinimo, kad selektoriai ir sąveikos šablonai veikia teisingai su lokalizuotomis CMP versijomis. Ilgalaikis stebėjimas. Mūsų dabartinė architektūra optimizuota vieno momento skenavimui. Sutikimo elgesio pokyčių aptikimas laikui bėgant -- ar svetainė pagerėjo po vykdymo? Ar CMP atnaujinimas ištaisė atmetimo srauto nesėkmių klasę? -- reikalauja pakartotinių skenavimų su diferencialine analize, kuri architektūriškai skiriasi nuo vienkartinio vertinimo. CMP laikymosi lyginamoji analizė. Turime duomenis CMP lygio laikymosi rodikliams vertinti (ar Cookiebot siejamas su geresniu laikymusi nei OneTrust?), bet CMP kokybės atskyrimas nuo svetainės operatoriaus konfigūracijos kokybės yra metodologiškai sudėtingas. CMP, kuri dažniau diegiama didelėse įmonėse su specialiomis privatumo komandomis, atrodys geriau agreguotai, net jei pats įrankis nėra labiau atitinkantis. Realaus laiko sutikimo būsenos tikrinimas. Dabartinis skeneris veikia paketiniame režime. Sutikimo tikrinimo integravimas į CI/CD pipeline ar realaus laiko stebėjimą reikalauja greitesnio, lengvesnio skenavimo režimo, kuris paaukoja tam tikrą įrodymų gylį dėl greičio. Mes tai tyrinėjame.

API

Tas pats skenavimo variklis, aprašytas šiame įraše, yra prieinamas per GDPR Monitor viešąjį API. Galite pateikti skenavimo užklausas programiškai, apklausti rezultatus ir gauti struktūrizuotus radinius bei įrodymų artefaktus. API grąžina tuos pačius duomenis, kuriuos rodo mūsų vartotojo sąsaja: momentines kopijas prieš sutikimą, slapukų inventorius, CMP aptikimo rezultatus, atmetimo srauto rezultatus, rizikos balus ir pilnas įrodymų grandines.

Jei kuriate laikymosi įrankius, integruojate privatumo patikras į CI/CD pipeline, vykdote savo tyrimus ar kuriate stebėjimą privatumo programoje, API suteikia prieigą prie elgesio sutikimo analizės be būtinybės kurti ir prižiūrėti savo Chromium automatizacijos infrastruktūrą.

---

Išbandykite patys. API dokumentacija prieinama adresu gdprprivacymonitor.eu/developers/api. Pateikite vieną URL arba integruokite automatizuotą privatumo stebėjimą į savo darbo eigą.