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

Automatizēta piekrišanas atbilstības pārbaude izklausās vienkārši, kamēr nemēģināt to uzbūvēt. Naivā pieeja — ielādēt lapu, pārbaudīt sīkdatnes, meklēt joslu — palaiž garām lielāko daļu no tā, kas ir svarīgs. Piekrišanas pārkāpumi ir uzvedības, nevis strukturāli. Tie izpaužas skriptu izpildes laikā, tīkla pieprasījumu secībā, saskarnes elementu reakcijā uz lietotāja mijiedarbību un stāvokļa noturībā starp lapas ielādēm. Neko no tā nevar novērtēt, nepalaižot reālu pārlūkprogrammu, nemijiedarbojoties ar lapu tā, kā to darītu cilvēks, un nereģistrējot, kas faktiski notiek tīkla līmenī.

Šis ieraksts apraksta, kā mēs izveidojām skenēšanas dzinēju aiz GDPR Monitor, inženierijas izaicinājumus, kas patērēja lielāko daļu mūsu laika, arhitektūras lēmumus, ko pieņēmām un kāpēc, un ierobežojumus, par kuriem esam godīgi. Ja strādājat ar tīmekļa atbilstību, pārlūkprogrammu automatizāciju vai liela mēroga tīmekļa mērījumiem, šeit vajadzētu būt kaut kam noderīgam.

Cauruļvada pārskats

Katra skenēšana iziet cauri sešiem posmiem. Cauruļvada izpratne ir nepieciešamais konteksts specifiskajiem izaicinājumiem, kas seko.

1. posms: pārlūkprogrammas palaišana un izolācija. Tīra Chromium instance sākas ar nulles stāvokli — bez sīkdatnēm, bez localStorage, bez kešatmiņas, bez service worker. Tā ir tīrās telpas garantija, kas padara pirms piekrišanas mērījumus jēgpilnus. Mēs konfigurējam standarta skatlogu, reālistiskus user-agent un Accept-Language galvenes, kas atbilst mērķa valstij, un standarta pārlūkprogrammas karogus. Katra skenēšana saņem savu pārlūkprogrammas procesu; nav stāvokļa noplūdes starp skenēšanām. 2. posms: navigācija un momentuzņēmums pirms piekrišanas. Skeneris pāriet uz mērķa URL, gaida, kamēr lapa sasniedz stabilu stāvokli (tīkls dīkstāvē, DOM nostabilizējies), un fiksē visu, kas noticis: iestatītās sīkdatnes, veiktos tīkla pieprasījumus (ar pilnu URL, laiku un atbildes metadatiem), kontaktētos trešo pušu domēnus un pilnu lapas ekrānuzņēmumu. Šis momentuzņēmums atbild uz pamata jautājumu: ko šī tīmekļa vietne darīja, pirms lietotājam bija jebkāda iespēja dot piekrišanu? 3. posms: CMP noteikšana un joslas identifikācija. Skeneris mēģina identificēt piekrišanas pārvaldības platformu un atrast piekrišanas joslu, pieņemšanas pogu un noraidīšanas pogu. Tam tiek izmantota daudzslāņu noteikšanas sistēma, kas detalizēti aprakstīta zemāk. 4. posms: piekrišanas mijiedarbība. Skeneris mijiedarbojas ar joslu — noklikšķinot uz pieņemt standarta plūsmai, noklikšķinot uz noraidīt noraidīšanas plūsmas testam. Tas gaida, kamēr lapa nostabilizējas pēc mijiedarbības, ņemot vērā animācijas, skriptu atkārtotu novērtēšanu un aizkavētu tagu aktivizēšanu. 5. posms: momentuzņēmums pēc piekrišanas un diferenciālā analīze. Otrais pilnais momentuzņēmums fiksē stāvokli pēc piekrišanas mijiedarbības. Salīdzinot pirms piekrišanas un pēc piekrišanas momentuzņēmumus, atklājas, kas mainījies: jaunas sīkdatnes, jauni izsekošanas pieprasījumi, piekrišanas stāvoklis CMP API. 6. posms: analīze, klasifikācija un atskaites ģenerēšana. Neapstrādātie dati tiek padoti analīzes moduļiem: sīkdatņu klasifikācija pret mūsu datubāzi, izsekotāju salīdzināšana pret zināmiem modeļiem, sīkdatņu dzīves ilguma novērtēšana, joslas pieejamības audits, Google Consent Mode validācija, pirkstu nospiedumu signālu noteikšana un riska vērtēšana. Rezultāts ir strukturēta atskaite ar secinājumiem, pierādījumu artefaktiem un kompozītu riska rādītāju.

Katrs posms rada laikzīmogotus pierādījumus, kas tiek ilgstoši glabāti. Jebkuru secinājumu var izsekot līdz konkrētiem tīkla pieprasījumiem, sīkdatņu ierakstiem vai ekrānuzņēmumiem.

1. izaicinājums: CMP noteikšana — 45 platformas, bezgalīgas variācijas

Piekrišanas pārvaldība nav standartizēta. Nav universāla HTML atribūta, nav obligāta JavaScript API, nav konsekventas DOM struktūras, kas teiktu "šī ir piekrišanas josla". Mūsu noteikšanas bibliotēkā ir 45 dažādas CMP, katrai ar savu DOM struktūru, skriptu parakstiem, JavaScript globālajiem mainīgajiem un mijiedarbības modeļiem. Turklāt 34,7% joslu, ko atklājām mūsu 97 304 vietņu pētījumā, bija vispārīgas vai neidentificētas — pielāgotas implementācijas, reģionāli piegādātāji vai minimāli risinājumi, kas neatbilda nevienam zināmam CMP parakstam.

Mūsu noteikšana izmanto uz pārliecību balstītu, daudzslāņu pieeju:

1. slānis: skriptu parakstu noteikšana

Skeneris pārbauda zināmu CMP skriptu klātbūtni pēc URL modeļa un JavaScript globālajiem mainīgajiem. Cookiebot, piemēram, ielādējas no `consent.cookiebot.com` un eksponē `window.Cookiebot`. OneTrust ielādējas no `cdn.cookielaw.org` un eksponē `window.OneTrust`. Katrai CMP ir raksturīgi ielādes modeļi, ko var noteikt pirms DOM pārbaudes.

Šis slānis ir ātrs un augsti uzticams, kad tas atbilst. Bet tam ir būtisks ierobežojums: tas norāda, kura CMP ir klātesoša lapā, bet ne obligāti kura CMP ir atbildīga par piekrišanas joslu. Vietne var ielādēt PiwikPRO analītikai (kas ietver CMP komponenti), vienlaikus izmantojot tarteaucitron faktiskai piekrišanas pārvaldībai. Abu skriptu noteikšana ir vienkārša; zināt, kurš kontrolē joslu, ir grūtāk.

2. slānis: verificētu selektoru salīdzināšana

Katrai zināmajai CMP mēs uzturams kurētu CSS selektoru kopu, kas uzticami identificē joslas konteineru, pieņemšanas pogu un noraidīšanas pogu. Tie ir selektori, ko esam validējuši vairākās katras CMP versijās un konfigurācijās. Kad CMP tiek noteikta 1. slānī un tās verificētie selektori atbilst DOM elementiem, mums ir augsta pārliecība gan par CMP identifikāciju, gan joslas mijiedarbības mērķiem.

3. slānis: saderīgu selektoru salīdzināšana

Plašāka selektoru kopa, kas darbojas daudzās CMP versijās, bet ir mazāk precīza. Tā apstrādā gadījumus, kad CMP ir pielāgota, ar mainītu tēmu vai darbojas versijā, ko mūsu verificētie selektori neaptver. Tā upurē precizitāti pārklājuma labā.

4. slānis: vispārīgas heiristikas

34,7% joslu, kas nav saistītas ar zināmu CMP, mēs atgriežamies pie heiristiskas noteikšanas. Skeneris meklē:

• Fiksēta pozīcija vai lipīga pozīcija elementus tuvu skatlogu apakšai vai augšai
• Elementus, kas satur ar piekrišanu saistītus atslēgvārdus vairākās valodās ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" utt.)
• Pogas ar izplatītām piekrišanas darbību etiķetēm ("Accept All", "Reject All", "Manage Preferences" un ekvivalenti)
• Piekrišanas dialogiem raksturīgus strukturālos modeļus: pārklājuma fonus, modālos konteinerus, aizvēršanas pogas

Šis slānis aptver daudzas pielāgotas implementācijas, bet ir dabiski mazāk uzticams. Fiksēta pozīcija reklāmas josla vai biļetena pierakstīšanās forma var strukturāli līdzināties piekrišanas dialogam.

5. slānis: CMP API zondēšana

Dažas CMP eksponē JavaScript API — it īpaši IAB Caurspīdīguma un piekrišanas ietvara (TCF) API caur `__tcfapi`. Mēs zondējam šīs API gan lai verificētu CMP noteikšanu, gan lai nolasītu programmatisko piekrišanas stāvokli, ko vēlāk salīdzinām ar novēroto pārlūkprogrammas uzvedību.

Pārliecības modelis

Tā vietā, lai uzskatītu noteikšanu par bināru (atrasts/neatrasts), mēs piešķiram pārliecības rādītājus, pamatojoties uz to, kuri slāņi atbilda un cik spēcīgi. Vietne, kurā noteikts CMP skripts, atbilst verificēti selektori un atrasts TCF API, saņem augstu pārliecību. Vietne, kurā aktivizējās tikai vispārīgas heiristikas, saņem zemāku pārliecību. Šis pārliecības rādītājs tiek ievadīts mūsu riska klasifikācijā — zemāka noteikšanas pārliecība nozīmē, ka secinājumi biežāk tiek klasificēti kā nenoteikti, nevis galīgi.

Pārliecības modelis ir iemesls, kāpēc CMP nepareiza identifikācija, lai gan tā notiek, sistemātiski neietekmē mūsu rezultātus. Kad noteikšana ir neskaidra, mēs to pasakām, nevis piespiedu kārtā klasificējam.

2. izaicinājums: noraidīšanas plūsma — kāpēc "noklikšķini un pārbaudi" ir pārsteidzoši grūti

Noraidīšanas pogas testēšana izklausās vienkārši: atrodi to, noklikšķini, pārbaudi, vai sīkdatnes ir pazudušas. Praksē katrs solis ir pilns ar laika problēmām, asinhronu uzvedību un platformai specifiskām īpatnībām.

Noraidīšanas pogas atrašana. Ne visas noraidīšanas pogas ir apzīmētas ar "Noraidīt". Tās var teikt "Atteikt visu", "Atteikties", "Tikai nepieciešamās sīkdatnes", "Pārvaldīt iestatījumus" (vedot uz otro slāni, kur noraidīšana ir iespējama), vai ekvivalentus desmitiem valodu. Dažas CMP novieto noraidīšanas opciju citā vizuālā vietā, citā izmērā vai citā krāsā nekā pieņemšanas opcija. Dažas to slēpj aiz "Vairāk opciju" vai "Pielāgot" saites. Mūsu skeneris uztur daudzvalodu noraidīšanas darbību modeļu kopu un arī nosaka otrā slāņa noraidīšanas opcijas, kur pirmais slānis piedāvā tikai pieņemt un pielāgot. Pareizā brīža gaidīšana. Pēc noraidīšanas noklikšķināšanas lapa var piedzīvot nozīmīgas izmaiņas: josla pazūd (bieži ar animāciju), CMP aktivizē piekrišanas stāvokļa atgriezeniskos izsaukumus, tagu pārvaldnieki pārvērtē savus noteikumus, un skripti var tikt ielādēti vai atcelti. Sīkdatņu pārbaude pārāk agri fiksē pārejas vidus stāvokli. Pārbaude pārāk vēlu palaiž garām īslaicīgu izsekošanu, kas aktivizējas un ātri pabeigz. Mēs izmantojam daudzsignālu gaidīšanu: tīkla dīkstāvi, DOM stabilitāti un minimālu aizkaves grīdu, kas noregulēta no empīriskas testēšanas simtiem CMP konfigurāciju. Pārlādēšanas tests un piekrišanas atjaunošanās. Pārlādēšanas solis ir tas, kas atklāja piekrišanas atjaunošanos kā fenomenu. Mēs neizvirzījām mērķi to atrast — mūsu sākotnējais noraidīšanas plūsmas tests pārbaudīja tikai tūlītējo stāvokli pēc noraidīšanas. Bet izstrādes laikā mēs pamanījām vietnes, kas izskatījās tīras pēc noraidīšanas, bet kurām bija izsekošanas sīkdatnes, kad pārbaudījām atkal pēc lapas pārlādēšanas. Sākotnējā atkļūdošana pieņēma skenera laika problēmu. Turpmāka izmeklēšana apstiprināja, ka tas bija reāli: trešo pušu skripti atkārtoti iestatīja sīkdatnes lapas ielādē neatkarīgi no piekrišanas stāvokļa.

Mēs pievienojām cauruļvadam skaidru atjaunošanās noteikšanu: pēc noraidīšanas plūsmas skeneris pārlādē lapu, gaida stabilitāti un salīdzina sīkdatņu inventāru ar momentuzņēmumu pēc noraidīšanas. Jebkura sīkdatne, kas tika noņemta noraidīšanā un atkal parādās pēc pārlādēšanas, tiek atzīmēta kā atjaunojusies. Tas atklāja 1 642 vietnes ar 4 932 atjaunojušām sīkdatnēm — secinājums, kas būtu bijis neredzams bez pārlādēšanas soļa.

`waitForScriptIdentifiedCMP` aptauja. Dažas CMP ielādējas asinhroni un neattēlo joslu vairākas sekundes pēc sākotnējās lapas ielādes. Ja skeneris pāriet uz noraidīšanas soli pirms CMP inicializācijas, tas vai nu pilnībā neievēro joslu, vai mijiedarbojas ar daļēji ielādētu saskarni. Mēs ieviesām aptaujas mehānismu, kas gaida, kamēr CMP JavaScript API kļūst pieejams (piemēram, `__tcfapi` TCF balstītām CMP, `Cookiebot` globālais Cookiebot) pirms turpināšanas. Tas pievieno latentumu katrai skenēšanai, bet ievērojami samazina viltus negatīvus no asinhronas CMP ielādes.

3. izaicinājums: cauruļvada piesātinājums mērogā

97 304 tīmekļa vietņu skenēšana nav vienas mašīnas darbs. Katra skenēšana palaiž Chromium procesu, pāriet uz tīmekļa vietni, pārtver un klasificē simtiem tīkla pieprasījumu, uzņem vairākus ekrānuzņēmumus un palaiž analīzes moduļus. Viena skenēšana aizņem 30-90 sekundes atkarībā no vietnes sarežģītības. Ar 15 vienlaicīgām skenēšanām uz vienu darbinieku resursu pārvaldība kļūst par galveno inženierijas problēmu.

Semafora arhitektūra

Mēs izmantojam uz semaforu balstītu vienlaicīguma modeli, lai ierobežotu vienlaicīgo Chromium procesu skaitu uz vienu darbinieku. Katram darbiniekam ir fiksēts semafors (15 sloti mūsu ražošanas konfigurācijā). Skenēšana iegūst slotu pirms pārlūkprogrammas palaišanas un atbrīvo to pabeidzot. Tas novērš atmiņas izsīkumu — 15 Chromium instances ar pilnu pieprasījumu pārtveršanu jau patērē ievērojamu RAM — un nodrošina pretspiedenu pret Redis rindu.

Dokumenta pieprasījuma izņēmums

Izstrādes sākumā mēs saskārāmies ar caurlaidspējas problēmu: mūsu pieprasījumu pārtveršanas loģika (kas pārbauda katru pieprasījumu pret SSRF drošību — bloķējot pieprasījumus uz privātiem IP diapazoniem, iekšējiem tīkliem un citiem potenciāli bīstamiem mērķiem) pievienoja latentumu katrai resursu ielādei, ieskaitot galveno dokumenta pieprasījumu. Tā kā dokumenta URL jau ir validēts pirms skenēšanas sākuma, mēs pievienojām ātrgaitas apvedceļu: dokumenta tipa pieprasījumi uz iepriekš validēto mērķa URL izlaiž pilnu pārtveršanas cauruļvadu. Šī šķietami neliela optimizācija ievērojami ietekmēja kopējo caurlaidspēju, jo dokumenta pieprasījums bloķē visu pārējo.

DNS iepriekšēja uzsildīšana

Pirmais pieprasījums uz jaunu domēnu rada DNS uzmeklēšanu, kas mūsu infrastruktūrā varēja pievienot 50-200ms katram domēnam. Ar vidēji 10,4 trešo pušu domēniem uz vietni (un dažiem līdz 171), DNS atrisināšanas laiks ievērojami uzkrājās. Mēs ieviesām DNS iepriekšēju uzsildīšanu, izmantojot lokālu Unbound DNS atrisinātāja kešatmiņu: pirms katras skenēšanas mēs atrisinām mērķa domēnu un uzsildām kešatmiņu. Unbound instance apkalpo kešotās atbildes turpmākajām uzmeklēšanām skenēšanas ietvaros, samazinot katram domēnam DNS pieskaitāmo laiku līdz zem milisekundes.

SSRF drošība mērogā

Katrs skenera pārtvertais pieprasījums tiek pārbaudīts pret drošības noteikumu kopu pirms atļaušanas turpināt. Pieprasījumi uz privātiem IP diapazoniem (RFC 1918, RFC 4193, link-local, loopback) tiek bloķēti. Tas novērš ļaunprātīgas mērķa vietnes iespēju izmantot skeneri kā SSRF vektoru iekšējo tīklu zondēšanai.

Izaicinājums mērogā bija atšķirt patiesos SSRF blokus no semafora piesātinājuma. Kad visi 15 semafora sloti ir aizņemti un skenēšana nevar iegūt slotu, rezultējošais taimouts virspusēji līdzinās pieprasījumam, kas bloķēts drošības iemeslu dēļ. Mēs pievienojām skaidru kļūdu kategorizāciju, lai atšķirtu "bloķēts, jo mērķis atrisinājās uz privātu IP" no "bloķēts, jo skeneris ir pie kapacitātes". Tas bija būtiski operacionālajai uzraudzībai un precīzai skenēšanas kļūmju klasifikācijai.

4. izaicinājums: botu apiešanas noteikšana

Pētījuma laikā mēs identificējām 137 tīmekļa vietnes, kas, šķiet, apzināti slēpj savu piekrišanas joslu no automatizētiem skeneriem. Josla tiek rādīta cilvēku apmeklētājiem, bet apslāpēta, kad vietne konstatē automatizētas pārlūkošanas pazīmes.

Visbiežākais mehānisms, ko mēs identificējām, ietver RCB (Real Cookie Banner) WordPress spraudņa `isAcceptAllForBots` konfigurācijas opciju. Kad iespējota, šis iestatījums nosaka automatizētas pārlūkprogrammas (caur `navigator.webdriver`, user-agent heiristikām vai uzvedības signāliem) un vai nu automātiski pieņem piekrišanu to vārdā, vai pilnībā slēpj joslu. Nolūks, kā spraudnis to dokumentē, ir novērst automatizētu apmeklētāju apkalpošanu ar piekrišanas dialogu, ar kuru tie nevar jēgpilni mijiedarboties. Efekts ir tāds, ka atbilstības skeneri — un regulatori, kas izmanto automatizētus rīkus — redz vietni, kas, šķiet, nav piekrišanas mehānisma, kamēr cilvēku apmeklētāji redz pilnu piekrišanas joslu.

Tā ir caurspīdīguma problēma. Ja tīmekļa vietnes piekrišanas mehānisms ir redzams tikai cilvēku apmeklētājiem, to nevar auditēt mērogā. Mēs šīs vietnes atzīmējam atsevišķi savos rezultātos, jo secinājums ir kvalitatīvi atšķirīgs no "josla nav noteikta". Vietnei ir josla; tā izvēlas to mums nerādīt.

Mēs nosakām botu apiešanu caur signālu kombināciju: zināmu botu noteikšanas konfigurāciju klātbūtni CMP iestatījumos (pieejami caur JavaScript pārbaudi), neatbilstības starp to, ko DOM rāda, un to, ko CMP API ziņo, un dažos gadījumos salīdzinot automatizētas skenēšanas rezultātus ar manuālu verifikāciju.

137 skaitlis noteikti ir pārāk zems. Mēs varam noteikt botu apiešanu tikai tad, kad varam identificēt mehānismu. Vietnes, kas izmanto sarežģītāku vai pielāgotu botu noteikšanu, var veiksmīgi izvairīties gan no mūsu skenera, gan mūsu apiešanas noteikšanas.

5. izaicinājums: CMP nepareiza identifikācija

Vietne var ielādēt vairākus skriptus, kas izskatās kā piekrišanas pārvaldības platformas. PiwikPRO ietver CMP komponenti, bet galvenokārt ir analītikas komplekts. Dažas WordPress vietnes ielādē Complianz līdzās atsevišķam analītikas spraudnim ar CMP līdzīgām funkcijām. Uzņēmumu vietnēs var būt iepriekšējās CMP atlikumi, kas joprojām ielādējas līdzās pašreizējai.

Naivā noteikšana — "ja redzam skriptu, tā ir CMP" — rada nepareizas identifikācijas, kas kaskādē pārvēršas nepareizā joslas mijiedarbībā. Ja skeneris identificē PiwikPRO kā CMP un mēģina izmantot PiwikPRO joslas selektorus, tas var palaist garām faktisko tarteaucitron joslu, kas kontrolē piekrišanu vietnē.

Mūsu uz pārliecību balstītā pieeja to risina, sarindojot CMP kandidātus. Kad tiek noteiktas vairākas potenciālās CMP:

1. Mēs pārbaudām, kurai ir redzama josla DOM (skripts klāt, bet nav joslas, nozīmē, iespējams, neaktīva vai nav CMP lietojums).

2. Mēs pārbaudām, kura eksponē aktīvu CMP API (piemēram, funkcionējošu `__tcfapi` vai līdzvērtīgu).

3. Mēs dodam priekšroku CMP, kuras verificētie selektori atbilst redzamiem DOM elementiem, pār to, kas noteikta tikai pēc skripta URL.

Šī heiristika nav pilnīga, bet tā atrisināja visbiežāk sastopamos nepareizās identifikācijas gadījumus, ar kuriem saskārāmies izstrādes un testēšanas laikā.

Ierobežojumi

Neviens automatizēts skeneris pilnīgi nereplikē katru cilvēka pārlūkošanas pieredzi. Šie ir zināmie ierobežojumi:

No GeoIP atkarīgas joslas. Dažas CMP, it īpaši CookieYes, piedāvā dažādas piekrišanas pieredzes, pamatojoties uz apmeklētāja IP ģeolokāciju. Mūsu skenēšanas tiek veiktas no konkrētām tīkla vietām Eiropā. Vietne, kas rāda piekrišanas joslu apmeklētājiem no Francijas, bet ne apmeklētājiem ārpus ES, rādīs dažādus rezultātus atkarībā no skenēšanas izcelsmes. Pašlaik mēs neskenējam katru vietni no katras ES valsts. Slēgts shadow DOM. Dažas CMP attēlo savu joslu slēgtā shadow DOM, kas nav pieejams standarta DOM vaicājumiem caur `document.querySelector`. Transcend CMP izmanto šo pieeju. Mūsu skeneris var noteikt shadow host elementu, bet nevar pārbaudīt tā saturu, lai atrastu pieņemšanas/noraidīšanas pogas. Šīs vietnes parasti nonāk pie nenoteiktiem rezultātiem. Dinamiski klašu nosaukumi un obfuskācija. Dažas CMP, it īpaši Admiral, izmanto dinamiski ģenerētus klašu nosaukumus, kas mainās katrā lapas ielādē. Uz selektoriem balstīta noteikšana šiem neizdodas, jo selektori nav stabili starp apmeklējumiem. Mēs atgriežamies pie vispārīgām heiristikām, bet pārliecība ir zemāka. Vienas lapas lietojumprogrammas. SPA, kas pārvalda piekrišanas stāvokli pilnībā klienta puses JavaScript un ielādē piekrišanas mehānismu pēc sākotnējām maršruta izmaiņām (nevis sākotnējā lapas ielādē), ir grūtāk novērtējamas. Mūsu skeneris pāriet uz URL un gaida, kamēr lapa nostabilizējas, bet nesimulē navigāciju lietojumprogrammas ietvaros. Piekrišanas josla, kas parādās tikai pēc tam, kad lietotājs navigē SPA ietvaros, var tikt nepamanīta. Valodu pārklājums. Mūsu noraidīšanas pogas noteikšana izmanto teksta salīdzināšanu atbalstīto valodu kopā, bet mēs neaptveran katru ES valodu vienlīdzīgi. Joslai maltiešu vai igauņu valodā var būt noraidīšanas pogas etiķetes, ko mūsu teksta salīdzināšana neatpazīst, izraisot noraidīšanas plūsmas testēšanas izlaišanu (lai gan pati josla joprojām var tikt noteikta pēc strukturālām heiristikām). Laika robežgadījumi. Skripts, kas aktivizējas 30 sekundes pēc lapas ielādes, tiks palaists garām skenēšanā, kas gaida 15 sekundes tīkla dīkstāvei. Mēs izmantojam lielus taimautus, bet asinhronās uzvedības garā aste ir dabiski grūti pilnībā aptverama.

Šie ierobežojumi veicina mūsu 14,9% nenoteikto rādītāju.

Infrastruktūra

Ražošanas skenēšanas infrastruktūra sastāv no:

• Skenēšanas dzinējs: Go lietojumprogramma, kas izmanto chromedp kā CDP klientu Chromium automatizācijai. Go tika izvēlēts tā vienlaicīguma modeļa dēļ (gorutīnes un kanāli dabiski atspoguļojas uz paralēlu skenēšanas orķestrēšanu), tā veiktspējas raksturlielumiem un izvietošanas vienkāršībai (viens statisks binārs).
• Pārlūkprogrammas izpildlaiks: Headless Chromium, kas palaists katrai skenēšanai caur CDP. Katra skenēšana saņem svaigu pārlūkprogrammas procesu ar nulles kopīgu stāvokli.
• Rinda: Redis balstīta darba rinda, kas sadala URL skenera darbiniekiem. Redis apstrādā darbu sadali, progresa izsekošanu un ātruma ierobežošanu.
• Datubāze: PostgreSQL ilgstošiem skenēšanas rezultātiem, secinājumiem, pierādījumu metadatiem un visiem strukturētajiem datiem. Skenēšanas, secinājumi, sīkdatnes, pieprasījumi un analīzes rezultāti tiek glabāti relāciju formā.
• DNS kešatmiņa: Lokāls Unbound atrisinātājs, kas nodrošina kešotas DNS uzmeklēšanas un SSRF drošu atrisināšanu.
• Pierādījumu krātuve: Ekrānuzņēmumi, HAR faili un PDF atskaites tiek glabāti kā ilgstoši artefakti, kas saistīti ar skenēšanas ierakstiem.

97 304 vietņu pētījumam mēs apstrādājām 114 748 kandidātu URL (97 304 veiksmīgi pabeigti) aptuveni 2,5 dienās, izmantojot 3 serveru instances, kas paralēli darbināja skenera darbiniekus. Katrs serveris darbināja vairākus darbinieku procesus ar 15 vienlaicīgiem skenēšanas slotiem katrā. Maksimālā caurlaidspēja bija aptuveni 25-30 pabeigtas skenēšanas minūtē uz serveri.

Galvenais šaurais kakls nebija CPU vai atmiņa, bet tīkls: katra skenēšana ģenerē simtiem izejošo pieprasījumu (uz mērķa vietni un tās trešo pušu resursiem), un agregētais joslas platums un savienojumu skaits pār visām vienlaicīgajām skenēšanām piesātināja pieejamo tīkla kapacitāti pirms citu resursu izsīkuma.

Neatrisināti izaicinājumi un turpmākais darbs

Vairākas problēmas paliek neatrisinātas vai daļēji atrisinātas:

Piekrišanas joslas lokalizācija. Mūsu teksta salīdzināšana aptver galvenās ES valodas, bet ir nepilnīga mazākām valodu kopienām. Pārklājuma paplašināšanai nepieciešams ne tikai tulkojumu pievienošana, bet arī validācija, ka selektori un mijiedarbības modeļi pareizi darbojas ar lokalizētām CMP versijām. Longitudinālā uzraudzība. Mūsu pašreizējā arhitektūra ir optimizēta viena brīža skenēšanai. Piekrišanas uzvedības izmaiņu noteikšanai laika gaitā — vai vietne uzlabojās pēc izpildes? vai CMP atjauninājums novērsa noraidīšanas plūsmas kļūmju klasi? — nepieciešamas atkārtotas skenēšanas ar diferenciālu analīzi, kas arhitektoniski atšķiras no vienreizēja novērtējuma. CMP atbilstības salīdzinājums. Mums ir dati, lai novērtētu atbilstības rādītājus pa CMP (vai Cookiebot ir saistīts ar labāku atbilstību nekā OneTrust?), bet CMP kvalitātes atdalīšana no vietnes operatora konfigurācijas kvalitātes ir metodoloģiski sarežģīta. CMP, ko biežāk izvieto lieli uzņēmumi ar specializētām privātuma komandām, izskatīsies labāk kopumā, pat ja pats rīks nav atbilstošāks. Reāllaika piekrišanas stāvokļa verifikācija. Pašreizējais skeneris darbojas partijas režīmā. Piekrišanas verifikācijas integrēšanai CI/CD cauruļvados vai reāllaika uzraudzībā nepieciešams ātrāks, vieglāks skenēšanas režīms, kas upurē zināmu pierādījumu dziļumu ātruma labā. Mēs to pētām.

API

Tas pats skenēšanas dzinējs, kas aprakstīts šajā ierakstā, ir pieejams caur GDPR Monitor publisko API. Jūs varat programātiski iesniegt skenēšanas pieprasījumus, aptaujāt rezultātus un izgūt strukturētus secinājumus un pierādījumu artefaktus. API atgriež tos pašus datus, ko rāda mūsu saskarne: momentuzņēmumus pirms piekrišanas, sīkdatņu inventārus, CMP noteikšanas rezultātus, noraidīšanas plūsmas iznākumus, riska rādītājus un pilnas pierādījumu ķēdes.

Ja veidojat atbilstības rīkus, integrējat privātuma pārbaudes CI/CD cauruļvados, veicat savu pētniecību vai veidojat uzraudzību privātuma programmā, API nodrošina piekļuvi uzvedības piekrišanas analīzei bez nepieciešamības veidot un uzturēt savu Chromium automatizācijas infrastruktūru.

---

Izmēģiniet paši. API dokumentācija ir pieejama gdprprivacymonitor.eu/developers/api. Iesniedziet vienu URL vai integrējiet automatizētu privātuma uzraudzību savā darbplūsmā.