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

Ο αυτοματοποιημενος ελεγχος συμμορφωσης συγκαταθεσης ακουγεται απλος μεχρι να προσπαθησεις να τον κατασκευασεις. Η αφελης προσεγγιση -- φορτωση μιας σελιδας, ελεγχος για cookies, αναζητηση banner -- χανει τα περισσοτερα απο οσα εχουν σημασια. Οι παραβιασεις συγκαταθεσης ειναι συμπεριφορικες, οχι δομικες. Εκδηλωνονται στον χρονισμο εκτελεσης scripts, στην ακολουθια αιτηματων δικτυου, στην αποκριση στοιχειων UI στην αλληλεπιδραση χρηστη και στη διατηρηση καταστασης μεταξυ φορτωσεων σελιδων. Δεν μπορεις να αξιολογησεις τιποτα απο αυτα χωρις να τρεξεις εναν πραγματικο browser, να αλληλεπιδρασεις με τη σελιδα οπως θα εκανε ενας ανθρωπος, και να καταγραψεις τι πραγματικα συμβαινει σε επιπεδο δικτυου.

Αυτη η αναρτηση περιγραφει πως κατασκευασαμε τη μηχανη σαρωσης πισω απο το GDPR Monitor, τις τεχνικες προκλησεις που απορροφησαν τον περισσοτερο χρονο μας, τις αρχιτεκτονικες αποφασεις που πηραμε και γιατι, και τους περιορισμους για τους οποιους ειμαστε ειλικρινεις. Αν δουλευεις με web compliance, αυτοματοποιηση browser η μεγαλης κλιμακας μετρηση ιστου, θα πρεπει να υπαρχει κατι χρησιμο εδω.

Επισκοπηση pipeline

Καθε σαρωση περναει απο εξι σταδια. Η κατανοηση του pipeline ειναι αναγκαιο πλαισιο για τις συγκεκριμενες προκλησεις που ακολουθουν.

Σταδιο 1: Εκκινηση browser και απομονωση. Μια νεα παρουσια Chromium ξεκιναει με μηδενικη κατασταση -- χωρις cookies, χωρις localStorage, χωρις cache, χωρις service workers. Αυτη ειναι η εγγυηση καθαρου δωματιου που κανει τη μετρηση πριν τη συγκαταθεση ουσιαστικη. Ρυθμιζουμε ενα τυπικο viewport, ρεαλιστικο user-agent και Accept-Language headers που ταιριαζουν με τη χωρα-στοχο, και τυπικες σημαιες browser. Καθε σαρωση παιρνει τη δικη της διεργασια browser· δεν υπαρχει διαρροη καταστασης μεταξυ σαρωσεων. Σταδιο 2: Πλοηγηση και στιγμιοτυπο πριν τη συγκαταθεση. Ο σαρωτης πλοηγειται στη διευθυνση URL στοχου, περιμενει τη σελιδα να φτασει σε σταθερη κατασταση (δικτυο αδρανες, DOM σταθεροποιημενο) και καταγραφει ολα οσα εχουν συμβει: cookies που τοποθετηθηκαν, αιτηματα δικτυου (με πληρη URL, χρονισμο και μεταδεδομενα απαντησης), domains τριτων μερων που επικοινωνησαν, και screenshot πληρους σελιδας. Αυτο το στιγμιοτυπο απανταει στο θεμελιωδες ερωτημα: τι εκανε αυτη η ιστοσελιδα πριν ο χρηστης ειχε οποιαδηποτε ευκαιρια να δωσει συγκαταθεση; Σταδιο 3: Ανιχνευση CMP και αναγνωριση banner. Ο σαρωτης επιχειρει να αναγνωρισει την πλατφορμα διαχειρισης συγκαταθεσης και να εντοπισει το banner συγκαταθεσης, το κουμπι αποδοχης και το κουμπι απορριψης. Αυτο χρησιμοποιει ενα στρωματοποιημενο συστημα ανιχνευσης που περιγραφεται αναλυτικα παρακατω. Σταδιο 4: Αλληλεπιδραση συγκαταθεσης. Ο σαρωτης αλληλεπιδρα με το banner -- κλικ αποδοχη για τη τυπικη ροη, κλικ απορριψη για τη δοκιμη ροης απορριψης. Περιμενει τη σελιδα να ηρεμησει μετα την αλληλεπιδραση, λαμβανοντας υποψη animations, επαναξιολογηση scripts και καθυστερημενη ενεργοποιηση tags. Σταδιο 5: Στιγμιοτυπο μετα τη συγκαταθεση και διαφορικη αναλυση. Ενα δευτερο πληρες στιγμιοτυπο καταγραφει την κατασταση μετα την αλληλεπιδραση συγκαταθεσης. Η συγκριση στιγμιοτυπων πριν και μετα τη συγκαταθεση αποκαλυπτει τι αλλαξε: νεα cookies, νεα αιτηματα παρακολουθησης, κατασταση συγκαταθεσης σε CMP APIs. Σταδιο 6: Αναλυση, ταξινομηση και δημιουργια αναφορας. Τα ακατεργαστα δεδομενα τροφοδοτουν μοναδες αναλυσης: ταξινομηση cookies εναντι της βασης δεδομενων μας, αντιστοιχηση trackers εναντι γνωστων μοτιβων, αξιολογηση χρονου ζωης cookies, ελεγχος προσβασιμοτητας του banner, επικυρωση Google Consent Mode, ανιχνευση σηματων fingerprinting και βαθμολογηση κινδυνου. Η εξοδος ειναι μια δομημενη αναφορα με ευρηματα, αποδεικτικα τεκμηρια και συνθετη βαθμολογια κινδυνου.

Καθε σταδιο παραγει χρονοσημασμενα αποδεικτικα που αποθηκευονται μονιμα. Καθε ευρημα μπορει να ανιχνευθει πισω σε συγκεκριμενα αιτηματα δικτυου, εγγραφες cookies η screenshots.

Προκληση 1: Ανιχνευση CMP -- 45 πλατφορμες, απειρες παραλλαγες

Η διαχειριση συγκαταθεσης δεν ειναι τυποποιημενη. Δεν υπαρχει καθολικο HTML attribute, κανενα υποχρεωτικο JavaScript API, καμια συνεπης δομη DOM που να λεει "αυτο ειναι ενα banner συγκαταθεσης." Υπαρχουν 45 διακριτα CMP στη βιβλιοθηκη ανιχνευσης μας, καθενα με τη δικη του δομη DOM, υπογραφες scripts, JavaScript globals και μοτιβα αλληλεπιδρασης. Περα απο αυτα, 34,7% των banners που ανιχνευσαμε στη μελετη μας 97.304 ιστοσελιδων ηταν γενερικα η μη αναγνωρισμενα -- εξατομικευμενες υλοποιησεις, τοπικοι πωλητες η ελαχιστες λυσεις που δεν ταιριαζουν με καμια γνωστη υπογραφη CMP.

Η ανιχνευση μας χρησιμοποιει μια στρωματοποιημενη προσεγγιση βασισμενη σε εμπιστοσυνη:

Στρωμα 1: Ανιχνευση υπογραφης script

Ο σαρωτης ελεγχει την παρουσια γνωστων scripts CMP κατα μοτιβο URL και JavaScript globals. Η Cookiebot, για παραδειγμα, φορτωνει απο `consent.cookiebot.com` και εκθετει `window.Cookiebot`. Η OneTrust φορτωνει απο `cdn.cookielaw.org` και εκθετει `window.OneTrust`. Καθε CMP εχει χαρακτηριστικα μοτιβα φορτωσης που μπορουν να ανιχνευτουν πριν εξεταστει το DOM.

Αυτο το στρωμα ειναι γρηγορο και υψηλης εμπιστοσυνης οταν ταιριαζει. Αλλα εχει εναν κρισιμο περιορισμο: σου λεει ποιο CMP ειναι παρον στη σελιδα, οχι απαραιτητα ποιο CMP ειναι υπευθυνο για το banner συγκαταθεσης. Μια ιστοσελιδα μπορει να φορτωνει PiwikPRO για αναλυτικα (που περιλαμβανει ενα συστατικο CMP) ενω χρησιμοποιει tarteaucitron για την πραγματικη διαχειριση συγκαταθεσης. Η ανιχνευση και των δυο scripts ειναι ευκολη· το να γνωριζεις ποιο ελεγχει το banner ειναι δυσκολοτερο.

Στρωμα 2: Αντιστοιχηση επαληθευμενων selectors

Για καθε γνωστο CMP, διατηρουμε ενα επιμελημενο συνολο CSS selectors που αναγνωριζουν αξιοπιστα τον container του banner, το κουμπι αποδοχης και το κουμπι απορριψης. Αυτοι ειναι selectors που εχουμε επικυρωσει σε πολλαπλες εκδοσεις και ρυθμισεις καθε CMP. Οταν ενα CMP ανιχνευεται στο Στρωμα 1 και οι επαληθευμενοι selectors του ταιριαζουν με στοιχεια στο DOM, εχουμε υψηλη εμπιστοσυνη τοσο στην αναγνωριση CMP οσο και στους στοχους αλληλεπιδρασης banner.

Στρωμα 3: Αντιστοιχηση συμβατων selectors

Ενα ευρυτερο συνολο selectors που λειτουργει σε πολλες εκδοσεις ενος CMP αλλα ειναι λιγοτερο ακριβες. Αυτοι χειριζονται περιπτωσεις οπου ενα CMP εχει εξατομικευτει, θεματοποιηθει η τρεχει μια εκδοση που δεν καλυπτεται απο τους επαληθευμενους selectors μας. Ανταλλασσουν ακριβεια για καλυψη.

Στρωμα 4: Γενικες ευρετικες μεθοδοι

Για το 34,7% των banners που δεν συσχετιζονται με γνωστο CMP, επιστρεφουμε στην ευρετικη ανιχνευση. Ο σαρωτης αναζητα:

• Στοιχεια σταθερης η sticky θεσης κοντα στο κατω η πανω μερος του viewport
• Στοιχεια που περιεχουν λεξεις-κλειδια σχετικες με τη συγκαταθεση σε πολλες γλωσσες ("cookies", "consent", "privacy", "akzeptieren", "accepter", "aceptar" κ.λπ.)
• Κουμπια με κοινες ετικετες ενεργειων συγκαταθεσης ("Accept All", "Reject All", "Manage Preferences" και αντιστοιχα)
• Δομικα μοτιβα τυπικα διαλογων συγκαταθεσης: backgrounds overlay, modal containers, κουμπια κλεισιματος

Αυτο το στρωμα πιανει πολλες εξατομικευμενες υλοποιησεις αλλα ειναι εγγενως λιγοτερο αξιοπιστο. Ενα banner προωθησης σταθερης θεσης η μια εγγραφη newsletter μπορει να μοιαζει δομικα με εναν διαλογο συγκαταθεσης.

Στρωμα 5: Ανιχνευση CMP API

Ορισμενα CMP εκθετουν JavaScript APIs -- κυριως το IAB Transparency and Consent Framework (TCF) API μεσω `__tcfapi`. Ανιχνευουμε αυτα τα APIs τοσο για επαληθευση ανιχνευσης CMP οσο και για αναγνωση της προγραμματικης καταστασης συγκαταθεσης, την οποια αργοτερα συγκρινουμε με την παρατηρουμενη συμπεριφορα browser.

Το μοντελο εμπιστοσυνης

Αντι να αντιμετωπιζουμε την ανιχνευση ως δυαδικη (βρεθηκε/δεν βρεθηκε), αποδιδουμε βαθμολογιες εμπιστοσυνης βασισμενες σε ποια στρωματα ταιριαξαν και ποσο ισχυρα. Μια ιστοσελιδα οπου ανιχνευουμε script CMP, ταιριαζουμε επαληθευμενους selectors και βρισκουμε TCF API παιρνει υψηλη εμπιστοσυνη. Μια ιστοσελιδα οπου μονο γενικες ευρετικες μεθοδοι ενεργοποιηθηκαν παιρνει χαμηλοτερη εμπιστοσυνη. Αυτη η βαθμολογια εμπιστοσυνης τροφοδοτει την ταξινομηση κινδυνου μας -- χαμηλοτερη εμπιστοσυνη ανιχνευσης σημαινει οτι τα ευρηματα ειναι πιο πιθανο να ταξινομηθουν ως ασυμπεραστα αντι οριστικα.

Το μοντελο εμπιστοσυνης ειναι ο λογος που η λανθασμενη αναγνωριση CMP, αν και συμβαινει, δεν στρεβλωνει συστηματικα τα αποτελεσματα μας. Οταν η ανιχνευση ειναι ασαφης, το λεμε, αντι να εξαναγκαζουμε μια ταξινομηση.

Προκληση 2: Η ροη απορριψης -- γιατι το "κλικ και ελεγχος" ειναι εκπληκτικα δυσκολο

Η δοκιμη ενος κουμπιου απορριψης ακουγεται απλη: βρες το, κανε κλικ, ελεγξε αν τα cookies εφυγαν. Στην πραξη, καθε βημα ειναι γεματο ζητηματα χρονισμου, ασυγχρονη συμπεριφορα και ιδιομορφιες πλατφορμας.

Ευρεση του κουμπιου απορριψης. Δεν εχουν ολα τα κουμπια απορριψης ετικετα "Reject". Μπορει να λενε "Decline All", "Refuse", "Only necessary cookies", "Manage settings" (οδηγωντας σε δευτερο επιπεδο οπου η απορριψη ειναι δυνατη), η αντιστοιχα σε οποιαδηποτε απο δεκαδες γλωσσες. Ορισμενα CMP τοποθετουν την επιλογη απορριψης σε διαφορετικη οπτικη θεση, σε διαφορετικο μεγεθος η σε διαφορετικο χρωμα απο την επιλογη αποδοχης. Ορισμενα τη κρυβουν πισω απο εναν συνδεσμο "More options" η "Customize". Ο σαρωτης μας διατηρει ενα πολυγλωσσο συνολο μοτιβων ενεργειας απορριψης και ανιχνευει επισης επιλογες απορριψης δευτερου επιπεδου οπου το πρωτο επιπεδο προσφερει μονο αποδοχη και εξατομικευση. Αναμονη για τη σωστη στιγμη. Μετα το κλικ στην απορριψη, η σελιδα μπορει να υποστει σημαντικες αλλαγες: το banner κλεινει (συχνα με animation), η CMP ενεργοποιει callbacks καταστασης συγκαταθεσης, οι tag managers επαναξιολογουν τους κανονες τους, και scripts μπορει να φορτωθουν η να αφαιρεθουν. Ο ελεγχος cookies πολυ νωρις πιανει τη μεταβατικη κατασταση. Ο ελεγχος πολυ αργα χανει τη μεταβατικη παρακολουθηση που ενεργοποιειται και ολοκληρωνεται γρηγορα. Χρησιμοποιουμε αναμονη πολλαπλων σηματων: αδρανεια δικτυου, σταθεροτητα DOM και ενα ελαχιστο κατωφλι καθυστερησης, ρυθμισμενο απο εμπειρικη δοκιμη σε εκατονταδες ρυθμισεις CMP. Η δοκιμη επαναφορτωσης και το consent respawn. Το βημα επαναφορτωσης ηταν αυτο που αποκαλυψε το consent respawn ως φαινομενο. Δεν ξεκινησαμε με σκοπο να το βρουμε -- η αρχικη δοκιμη ροης απορριψης μας ελεγχε μονο την αμεση κατασταση μετα την απορριψη. Αλλα κατα την αναπτυξη, παρατηρησαμε ιστοσελιδες που φαινονταν καθαρες μετα την απορριψη αλλα ειχαν cookies παρακολουθησης οταν ελεγξαμε ξανα μετα απο επαναφορτωση σελιδας. Η αρχικη αποσφαλματωση υπεθεσε προβλημα χρονισμου στον σαρωτη. Περαιτερω ερευνα επιβεβαιωσε οτι ηταν πραγματικο: scripts τριτων μερων που ξανατοποθετουσαν cookies κατα τη φορτωση σελιδας ανεξαρτητα απο την κατασταση συγκαταθεσης.

Προσθεσαμε ρητη ανιχνευση respawn στο pipeline: μετα τη ροη απορριψης, ο σαρωτης επαναφορτωνει τη σελιδα, περιμενει σταθεροτητα και συγκρινει τον καταλογο cookies με το στιγμιοτυπο μετα την απορριψη. Καθε cookie που αφαιρεθηκε κατα την απορριψη και επανεμφανιζεται μετα την επαναφορτωση σημαιοδοτειται ως respawn. Αυτο επιασε 1.642 ιστοσελιδες με 4.932 cookies respawn -- ενα ευρημα που θα ηταν αορατο χωρις το βημα επαναφορτωσης.

Η ψηφοφορια `waitForScriptIdentifiedCMP`. Ορισμενα CMP φορτωνουν ασυγχρονα και δεν εμφανιζουν το banner τους μεχρι αρκετα δευτερολεπτα μετα την αρχικη φορτωση σελιδας. Αν ο σαρωτης προχωρησει στο βημα απορριψης πριν αρχικοποιηθει η CMP, ειτε χανει το banner εντελως ειτε αλληλεπιδρα με μια μερικως φορτωμενη διεπαφη. Υλοποιησαμε εναν μηχανισμο ψηφοφοριας που περιμενει το JavaScript API της CMP να γινει διαθεσιμο (π.χ. `__tcfapi` για CMP βασισμενα σε TCF, `Cookiebot` global για Cookiebot) πριν προχωρησει. Αυτο προσθετει καθυστερηση ανα σαρωση αλλα μειωνει σημαντικα τα ψευδη αρνητικα απο ασυγχρονη φορτωση CMP.

Προκληση 3: Κορεσμος pipeline σε κλιμακα

Η σαρωση 97.304 ιστοσελιδων δεν ειναι δουλεια για ενα μηχανημα. Καθε σαρωση εκκινει μια διεργασια Chromium, πλοηγειται σε μια ιστοσελιδα, υποκλεπτει και ταξινομει εκατονταδες αιτηματα δικτυου, παιρνει πολλαπλα screenshots και τρεχει μοναδες αναλυσης. Μια μεμονωμενη σαρωση διαρκει 30-90 δευτερολεπτα αναλογα με την πολυπλοκοτητα της ιστοσελιδας. Σε 15 ταυτοχρονες σαρωσεις ανα worker, η διαχειριση πορων γινεται η κυρια τεχνικη ανησυχια.

Η αρχιτεκτονικη σηματοφορου

Χρησιμοποιουμε ενα μοντελο ταυτοχρονισμου βασισμενο σε σηματοφορο για τον περιορισμο ταυτοχρονων διεργασιων Chromium ανα worker. Καθε worker εχει εναν σταθερο σηματοφορο (15 θεσεις στη ρυθμιση παραγωγης μας). Μια σαρωση αποκτα μια θεση πριν εκκινησει τον browser της και την αποδεσμευει κατα την ολοκληρωση. Αυτο αποτρεπει την εξαντληση μνημης -- 15 παρουσιες Chromium με πληρη υποκλοπη αιτηματων καταναλωνουν ηδη σημαντικη RAM -- και παρεχει αντιπιεση κατα της ουρας Redis.

Η εξαιρεση αιτηματος εγγραφου

Νωρις στην αναπτυξη, αντιμετωπισαμε ενα προβλημα απoδοσης: η λογικη υποκλοπης αιτηματων μας (που ελεγχει καθε αιτημα για ασφαλεια SSRF -- αποκλειοντας αιτηματα σε ιδιωτικα ευρη IP, εσωτερικα δικτυα και αλλους δυνητικα επικινδυνους στοχους) προσθετε καθυστερηση σε καθε φορτωση πορου, συμπεριλαμβανομενου του κυριου αιτηματος εγγραφου. Επειδη η διευθυνση URL εγγραφου εχει ηδη επικυρωθει πριν αρχισει η σαρωση, προσθεσαμε μια παρακαμψη γρηγορης διαδρομης: αιτηματα τυπου εγγραφου στην προεπικυρωμενη διευθυνση URL στοχου παρακαμπτουν το πληρες pipeline υποκλοπης. Αυτη η φαινομενικα μικρη βελτιστοποιηση ειχε σημαντικο αντικτυπο στη συνολικη απoδοση επειδη το αιτημα εγγραφου μπλοκαρει ολα τα αλλα.

Προθερμανση DNS

Το πρωτο αιτημα σε ενα νεο domain συνεπαγεται αναζητηση DNS, η οποια στην υποδομη μας μπορουσε να προσθεσει 50-200ms ανα domain. Με τη μεση ιστοσελιδα να επικοινωνει με 10,4 domains τριτων μερων (και ορισμενες με εως 171), ο χρονος αναλυσης DNS συσσωρευοταν σημαντικα. Υλοποιησαμε προθερμανση DNS χρησιμοποιωντας μια τοπικη cache Unbound DNS resolver: πριν απο καθε σαρωση, αναλυουμε το domain στοχου και θερμαινουμε την cache. Η παρουσια Unbound εξυπηρετει αποθηκευμενες απαντησεις για επομενες αναζητησεις εντος της σαρωσης, μειωνοντας το overhead DNS ανα domain σε κατω απο ενα χιλιοστο του δευτερολεπτου.

Ασφαλεια SSRF σε κλιμακα

Καθε αιτημα που υποκλεπτεται απο τον σαρωτη ελεγχεται εναντι ενος συνολου κανονων ασφαλειας πριν επιτραπει να προχωρησει. Αιτηματα σε ιδιωτικα ευρη IP (RFC 1918, RFC 4193, link-local, loopback) αποκλειονται. Αυτο αποτρεπει μια κακοβουλη ιστοσελιδα στοχο απο το να χρησιμοποιησει τον σαρωτη ως φορεα SSRF για ανιχνευση εσωτερικων δικτυων.

Η προκληση σε κλιμακα ηταν η διακριση γνησιων αποκλεισμων SSRF απο κορεσμο σηματοφορου. Οταν ολες οι 15 θεσεις σηματοφορου ειναι σε χρηση και μια σαρωση δεν μπορει να αποκτησει θεση, το timeout που προκυπτει μοιαζει επιφανειακα με αιτημα που αποκλειεται για λογους ασφαλειας. Προσθεσαμε ρητη κατηγοριοποιηση σφαλματων για τη διακριση "αποκλεισμενο επειδη ο στοχος αναλυθηκε σε ιδιωτικο IP" απο "αποκλεισμενο επειδη ο σαρωτης ειναι σε χωρητικοτητα." Αυτο ηταν ουσιωδες για τη λειτουργικη παρακολουθηση και για την ακριβη ταξινομηση αποτυχιων σαρωσης.

Προκληση 4: Ανιχνευση αποφυγης bot

Κατα τη μελετη, εντοπισαμε 137 ιστοσελιδες που φαινεται να κρυβουν σκοπιμα το banner συγκαταθεσης τους απο αυτοματοποιημενους σαρωτες. Το banner εμφανιζεται σε ανθρωπινους επισκεπτες αλλα αποκρυπτεται οταν η ιστοσελιδα ανιχνευει χαρακτηριστικα αυτοματοποιημενης περιηγησης.

Ο πιο κοινος μηχανισμος που εντοπισαμε περιλαμβανει την επιλογη ρυθμισης `isAcceptAllForBots` του WordPress plugin RCB (Real Cookie Banner). Οταν ενεργοποιηθει, αυτη η ρυθμιση ανιχνευει αυτοματοποιημενους browsers (μεσω `navigator.webdriver`, ευρετικων user-agent, η σηματων συμπεριφορας) και ειτε αποδεχεται αυτοματα τη συγκαταθεση εκ μερους τους ειτε αποκρυπτει το banner εντελως. Η προθεση, οπως τεκμηριωνεται απο το plugin, ειναι να αποτρεψει αυτοματοποιημενους επισκεπτες απο το να δουν εναν διαλογο συγκαταθεσης με τον οποιο δεν μπορουν ουσιαστικα να αλληλεπιδρασουν. Το αποτελεσμα ειναι οτι σαρωτες συμμορφωσης -- και ρυθμιστικοι ελεγκτες που χρησιμοποιουν αυτοματοποιημενα εργαλεια -- βλεπουν μια ιστοσελιδα που φαινεται να μην εχει κανεναν μηχανισμο συγκαταθεσης, ενω οι ανθρωπινοι επισκεπτες βλεπουν ενα πληρες banner συγκαταθεσης.

Αυτο ειναι προβλημα διαφανειας. Αν ο μηχανισμος συγκαταθεσης μιας ιστοσελιδας ειναι ορατος μονο σε ανθρωπινους επισκεπτες, δεν μπορει να ελεγχθει σε κλιμακα. Σημαιοδοτουμε αυτες τις ιστοσελιδες ξεχωριστα στα αποτελεσματα μας επειδη το ευρημα ειναι ποιοτικα διαφορετικο απο "δεν ανιχνευθηκε banner." Η ιστοσελιδα εχει banner· επιλεγει να μην μας το δειξει.

Ανιχνευουμε αποφυγη bot μεσω συνδυασμου σηματων: παρουσια γνωστης ρυθμισης ανιχνευσης bot σε ρυθμισεις CMP (προσβασιμη μεσω ελεγχου JavaScript), ασυμφωνιες μεταξυ αυτου που δειχνει το DOM και αυτου που αναφερει το API της CMP, και σε ορισμενες περιπτωσεις συγκρινοντας αυτοματοποιημενα αποτελεσματα σαρωσης με χειροκινητη επαληθευση.

Ο αριθμος 137 ειναι σιγουρα υποεκτιμηση. Μπορουμε να ανιχνευσουμε αποφυγη bot μονο οταν μπορουμε να αναγνωρισουμε τον μηχανισμο. Ιστοσελιδες που χρησιμοποιουν πιο εξελιγμενη η εξατομικευμενη ανιχνευση bot μπορει να αποφευγουν επιτυχως τοσο τον σαρωτη μας οσο και την ανιχνευση αποφυγης μας.

Προκληση 5: Λανθασμενη αναγνωριση CMP

Μια ιστοσελιδα μπορει να φορτωνει πολλαπλα scripts που μοιαζουν με πλατφορμες διαχειρισης συγκαταθεσης. Η PiwikPRO περιλαμβανει ενα συστατικο CMP αλλα ειναι κυριως μια σουιτα αναλυτικων. Ορισμενες ιστοσελιδες WordPress φορτωνουν Complianz μαζι με ενα ξεχωριστο plugin αναλυτικων που εχει χαρακτηριστικα παρομοια με CMP. Εταιρικες ιστοσελιδες μπορει να εχουν υπολειμματα ενος προηγουμενου CMP που ακομα φορτωνει μαζι με το τρεχον.

Αφελης ανιχνευση -- "αν δουμε το script, ειναι η CMP" -- παραγει λανθασμενες αναγνωρισεις που αλυσιδωτα οδηγουν σε εσφαλμενη αλληλεπιδραση banner. Αν ο σαρωτης αναγνωρισει την PiwikPRO ως CMP και προσπαθησει να χρησιμοποιησει τους selectors banner της PiwikPRO, μπορει να χασει το πραγματικο banner tarteaucitron που ελεγχει τη συγκαταθεση στην ιστοσελιδα.

Η προσεγγιση μας βασισμενη σε εμπιστοσυνη αντιμετωπιζει αυτο καταταζοντας τους υποψηφιους CMP. Οταν ανιχνευονται πολλαπλα πιθανα CMP:

1. Ελεγχουμε ποιο εχει ορατο banner στο DOM (script παρον αλλα χωρις banner σημαινει πιθανον ανενεργο η μη CMP χρηση).

2. Ελεγχουμε ποιο εκθετει ενεργο CMP API (π.χ. λειτουργικο `__tcfapi` η αντιστοιχο).

3. Προτιμουμε το CMP του οποιου οι επαληθευμενοι selectors ταιριαζουν με ορατα στοιχεια DOM εναντι αυτου που ανιχνευεται μονο μεσω URL script.

Αυτη η ευρετικη δεν ειναι τελεια, αλλα επιλυσε τις πιο κοινες περιπτωσεις λανθασμενης αναγνωρισης που αντιμετωπισαμε κατα την αναπτυξη και τη δοκιμη.

Περιορισμοι

Κανενας αυτοματοποιημενος σαρωτης δεν αναπαραγει τελεια καθε ανθρωπινη εμπειρια περιηγησης. Αυτοι ειναι οι γνωστοι περιορισμοι:

Banners εξαρτωμενα απο GeoIP. Ορισμενα CMP, κυριως η CookieYes, εξυπηρετουν διαφορετικες εμπειριες συγκαταθεσης βασει γεωγραφικης τοποθεσιας IP του επισκεπτη. Οι σαρωσεις μας προερχονται απο συγκεκριμενες τοποθεσιες δικτυου στην Ευρωπη. Μια ιστοσελιδα που δειχνει banner συγκαταθεσης σε επισκεπτες απο τη Γαλλια αλλα οχι σε επισκεπτες εκτος ΕΕ θα δειξει διαφορετικα αποτελεσματα αναλογα με την προελευση σαρωσης. Δεν σαρωνουμε αυτη τη στιγμη καθε ιστοσελιδα απο καθε χωρα ΕΕ. Κλειστο shadow DOM. Ορισμενα CMP εμφανιζουν το banner τους μεσα σε κλειστο shadow DOM, το οποιο ειναι απροσβασιμο σε τυπικα ερωτηματα DOM μεσω `document.querySelector`. Το CMP της Transcend χρησιμοποιει αυτη την προσεγγιση. Ο σαρωτης μας μπορει να ανιχνευσει το στοιχειο shadow host αλλα δεν μπορει να ελεγξει τα περιεχομενα του για να βρει κουμπια αποδοχης/απορριψης. Αυτες οι ιστοσελιδες τυπικα καταληγουν ως ασυμπεραστες στα αποτελεσματα μας. Δυναμικα ονοματα κλασεων και συσκοτιση. Ορισμενα CMP, κυριως η Admiral, χρησιμοποιουν δυναμικα παραγομενα ονοματα κλασεων που αλλαζουν σε καθε φορτωση σελιδας. Η ανιχνευση βασισμενη σε selectors αποτυγχανει για αυτα επειδη οι selectors δεν ειναι σταθεροι μεταξυ επισκεψεων. Επιστρεφουμε σε γενικες ευρετικες μεθοδους, αλλα η εμπιστοσυνη ειναι χαμηλοτερη. Single-page applications. SPA που διαχειριζονται την κατασταση συγκαταθεσης εξ ολοκληρου σε client-side JavaScript και φορτωνουν τον μηχανισμο συγκαταθεσης μετα απο αρχικες αλλαγες διαδρομης (αντι κατα την αρχικη φορτωση σελιδας) ειναι δυσκολοτερα να αξιολογηθουν. Ο σαρωτης μας πλοηγειται στη διευθυνση URL και περιμενει τη σελιδα να σταθεροποιηθει, αλλα δεν προσομοιωνει πλοηγηση εντος εφαρμογης. Ενα banner συγκαταθεσης που εμφανιζεται μονο αφου ο χρηστης πλοηγηθει εντος του SPA μπορει να χαθει. Γλωσσικη καλυψη. Η ανιχνευση κουμπιου απορριψης μας χρησιμοποιει αντιστοιχηση κειμενου σε ενα συνολο υποστηριζομενων γλωσσων, αλλα δεν καλυπτουμε ολες τις γλωσσες ΕΕ ισοτιμα. Ενα banner στα μαλτεζικα η εσθονικα μπορει να εχει ετικετες κουμπιου απορριψης που η αντιστοιχηση κειμενου μας δεν αναγνωριζει, οδηγωντας σε χαμενη δοκιμη ροης απορριψης (αν και το ιδιο το banner μπορει ακομα να ανιχνευτει απο δομικες ευρετικες μεθοδους). Ακραιες περιπτωσεις χρονισμου. Ενα script που ενεργοποιειται 30 δευτερολεπτα μετα τη φορτωση σελιδας θα χαθει απο μια σαρωση που περιμενει 15 δευτερολεπτα για αδρανεια δικτυου. Χρησιμοποιουμε γενναιοδωρα timeouts, αλλα η μακρα ουρα ασυγχρονης συμπεριφορας ειναι εγγενως δυσκολο να καταγραφει πληρως.

Αυτοι οι περιορισμοι συμβαλλουν στο ποσοστο ασυμπεραστων αποτελεσματων μας 14,9%.

Η υποδομη

Η υποδομη σαρωσης παραγωγης αποτελειται απο:

• Μηχανη σαρωσης: Μια εφαρμογη Go που χρησιμοποιει chromedp ως CDP client για αυτοματοποιηση Chromium. Η Go επιλεχθηκε για το μοντελο ταυτοχρονισμου της (goroutines και channels αντιστοιχιζονται φυσικα στην παραλληλη ενορχηστρωση σαρωσης), τα χαρακτηριστικα αποδοσης της και την απλοτητα αναπτυξης (ενα μονο στατικο binary).
• Browser runtime: Headless Chromium που εκκινει ανα σαρωση μεσω CDP. Καθε σαρωση παιρνει μια νεα διεργασια browser με μηδενικη κοινοχρηστη κατασταση.
• Ουρα: Ουρα εργασιας υποστηριζομενη απο Redis που διανεμει URLs σε workers σαρωτη. Η Redis χειριζεται τη διανομη εργασιων, την παρακολουθηση προοδου και τον περιορισμο ρυθμου.
• Βαση δεδομενων: PostgreSQL για μονιμη αποθηκευση αποτελεσματων σαρωσης, ευρηματων, μεταδεδομενων αποδεικτικων και ολων των δομημενων δεδομενων. Σαρωσεις, ευρηματα, cookies, αιτηματα και εξοδοι αναλυσης αποθηκευονται ολα σχεσιακα.
• DNS cache: Τοπικος resolver Unbound που παρεχει αποθηκευμενες αναζητησεις DNS και ασφαλη αναλυση SSRF.
• Αποθηκευση αποδεικτικων: Screenshots, αρχεια HAR και αναφορες PDF αποθηκευονται ως μονιμα τεκμηρια συνδεδεμενα με εγγραφες σαρωσης.

Για τη μελετη 97.304 ιστοσελιδων, επεξεργαστηκαμε 114.748 υποψηφιες διευθυνσεις URL (97.304 ολοκληρωθηκαν επιτυχως) σε περιπου 2,5 ημερες χρησιμοποιωντας 3 server instances που τρεχαν workers σαρωτη παραλληλα. Καθε server τρεχε πολλαπλες διεργασιες worker με 15 ταυτοχρονες θεσεις σαρωσης η καθεμια. Η μεγιστη αποδοση ηταν περιπου 25-30 ολοκληρωμενες σαρωσεις ανα λεπτο ανα server.

Το κυριο σημειο στενωσης δεν ηταν CPU η μνημη αλλα δικτυο: καθε σαρωση δημιουργει εκατονταδες εξερχομενα αιτηματα (στην ιστοσελιδα στοχο και τους πορους τριτων μερων της), και το συνολικο ευρος ζωνης και ο αριθμος συνδεσεων σε ολες τις ταυτοχρονες σαρωσεις κορεσε τη διαθεσιμη χωρητικοτητα δικτυου πριν εξαντληθουν αλλοι ποροι.

Ανοιχτες προκλησεις και μελλοντικη δουλεια

Αρκετα προβληματα παραμενουν αλυτα η μερικως λυμενα:

Εντοπιοποιηση banner συγκαταθεσης. Η αντιστοιχηση κειμενου μας καλυπτει μεγαλες γλωσσες ΕΕ αλλα ειναι ατελης για μικροτερες γλωσσικες κοινοτητες. Η επεκταση της καλυψης απαιτει οχι μονο προσθηκη μεταφρασεων αλλα επικυρωση οτι οι selectors και τα μοτιβα αλληλεπιδρασης λειτουργουν σωστα με εντοπιοποιημενες εκδοσεις CMP. Χρονικη παρακολουθηση. Η τρεχουσα αρχιτεκτονικη μας ειναι βελτιστοποιημενη για σαρωση σε μια χρονικη στιγμη. Η ανιχνευση αλλαγων στη συμπεριφορα συγκαταθεσης με τον χρονο -- βελτιωθηκε μια ιστοσελιδα μετα την επιβολη; Διορθωσε μια ενημερωση CMP μια κατηγορια αποτυχιων ροης απορριψης; -- απαιτει επαναλαμβανομενες σαρωσεις με διαφορικη αναλυση, κατι που ειναι αρχιτεκτονικα διαφορετικο απο μια εφαπαξ αξιολογηση. Συγκριτικη αξιολογηση CMP. Εχουμε τα δεδομενα για να αξιολογησουμε ποσοστα συμμορφωσης ανα CMP (ειναι η Cookiebot συνδεδεμενη με καλυτερη συμμορφωση απο την OneTrust;), αλλα η αποσυνδεση της ποιοτητας CMP απο την ποιοτητα ρυθμισης του διαχειριστη ιστοσελιδας ειναι μεθοδολογικα περιπλοκη. Ενα CMP που εγκαθισταται συχνοτερα απο μεγαλες επιχειρησεις με ειδικες ομαδες ιδιωτικοτητας θα φαινεται καλυτερο συνολικα ακομα κι αν το ιδιο το εργαλειο δεν ειναι πιο συμμορφωμενο. Επαληθευση καταστασης συγκαταθεσης σε πραγματικο χρονο. Ο τρεχων σαρωτης λειτουργει σε λειτουργια δεσμης. Η ενσωματωση επαληθευσης συγκαταθεσης σε CI/CD pipelines η παρακολουθηση πραγματικου χρονου απαιτει μια ταχυτερη, ελαφρυτερη λειτουργια σαρωσης που θυσιαζει καποιο βαθος αποδεικτικων για ταχυτητα. Το εξερευνουμε.

Το API

Η ιδια μηχανη σαρωσης που περιγραφεται σε αυτη την αναρτηση ειναι διαθεσιμη μεσω του δημοσιου API του GDPR Monitor. Μπορειτε να υποβαλετε αιτηματα σαρωσης προγραμματικα, να κανετε polling για αποτελεσματα και να ανακτησετε δομημενα ευρηματα και αποδεικτικα τεκμηρια. Το API επιστρεφει τα ιδια δεδομενα που εμφανιζει η διεπαφη μας: στιγμιοτυπα πριν τη συγκαταθεση, καταλογους cookies, αποτελεσματα ανιχνευσης CMP, αποτελεσματα ροης απορριψης, βαθμολογιες κινδυνου και πληρεις αλυσιδες αποδεικτικων.

Αν κατασκευαζετε εργαλεια συμμορφωσης, ενσωματωνετε ελεγχους ιδιωτικοτητας σε CI/CD pipelines, διεξαγετε τη δικη σας ερευνα η ενσωματωνετε παρακολουθηση σε ενα προγραμμα ιδιωτικοτητας, το API παρεχει προσβαση σε συμπεριφορικη αναλυση συγκαταθεσης χωρις την αναγκη κατασκευης και συντηρησης δικης σας υποδομης αυτοματοποιησης Chromium.

---

Δοκιμαστε μονοι σας. Τεκμηριωση API ειναι διαθεσιμη στο gdprprivacymonitor.eu/developers/api. Υποβαλετε μια μονη διευθυνση URL η ενσωματωστε αυτοματοποιημενη παρακολουθηση ιδιωτικοτητας στη ροη εργασιας σας.