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

Gdy postanowiliśmy przeskanować 97 304 strony internetowe UE pod kątem zgodności z GDPR, szybko natrafiliśmy na problem, który definiuje całą tę domenę: nie można ocenić zgodności zgody, czytając HTML. Trzeba uruchomić stronę internetową, wejść z nią w interakcję i obserwować, co przeglądarka faktycznie robi.

Ten wpis opisuje architekturę techniczną skanera GDPR Monitor, wyzwania inżynieryjne, na jakie natrafiliśmy, oraz ograniczenia, o których mówimy otwarcie.

Przegląd architektury

Skaner jest aplikacją Go zbudowaną wokół headless Chromium poprzez Chrome DevTools Protocol (CDP). To nie jest crawler w tradycyjnym sensie -- jest bliższy zautomatyzowanemu testowi przeglądarki, który generuje ustrukturyzowane dowody zgodności.

Główne komponenty:

• Orkiestrator pipeline -- koordynuje etapy skanowania w kolejności: uruchomienie przeglądarki, nawigacja, migawka przed zgodą, wykrywanie banera, interakcja zgody, migawka po zgodzie, analiza i generowanie raportu.
• Menedżer przeglądarki -- zarządza cyklem życia procesu Chromium, przechwytywaniem żądań i komunikacją CDP. Używamy chromedp jako klienta CDP po stronie Go.
• Biblioteka wykrywania CMP -- identyfikuje platformy zarządzania zgodą przy użyciu kombinacji sygnatur skryptów, selektorów DOM i heurystyk behawioralnych. Biblioteka obejmuje dziesiątki znanych CMP.
• Klasyfikatory plików cookie i trackerów -- dopasowują zaobserwowane pliki cookie do bazy danych klasyfikacji, a żądania sieciowe do znanych wzorców trackerów.
• Pipeline dowodów -- rejestruje i przechowuje zrzuty ekranu, pliki HAR (HTTP Archive), migawki plików cookie i logi sieciowe jako opatrzone znacznikami czasu artefakty.
• Moduły analizy -- kontrole wyższego rzędu obejmujące audyt dostępności, walidację Google Consent Mode, mapowanie przepływów danych, wykrywanie sygnałów fingerprintingu i analizę polityki prywatności.

Skaner działa jako worker kolejki w produkcji. Kolejka wspierana przez Redis dystrybuuje URL-e do instancji workerów, z których każda zarządza własną pulą procesów Chromium.

Pipeline skanowania w szczegółach

Pojedynczy skan przechodzi przez te etapy:

Etap 1: Czysty start przeglądarki

Każdy skan zaczyna się od świeżej instancji Chromium. Brak plików cookie, brak lokalnego magazynu, brak zasobów w pamięci podręcznej, brak wcześniejszej historii przeglądania. To jest kluczowe -- musimy obserwować doświadczenie odwiedzającego po raz pierwszy bez wcześniejszego stanu zgody.

Konfigurujemy przeglądarkę ze standardowym viewportem, realistycznym user agentem i nagłówkami językowymi odpowiadającymi krajowi docelowemu. Kwestie GeoIP są obsługiwane na poziomie sieci.

Etap 2: Migawka przed zgodą

Przed jakąkolwiek interakcją skaner rejestruje:

• Wszystkie pliki cookie ustawione przez stronę (first-party i third-party)
• Wszystkie wykonane żądania sieciowe, z pełnym URL, timingiem i metadanymi odpowiedzi
• Liczbę i tożsamość skontaktowanych domen stron trzecich
• Pełnostronicowy zrzut ekranu

Ta migawka odpowiada na pytanie: co się wydarzyło, zanim odwiedzający miał szansę wyrazić zgodę?

Przeciętna strona internetowa w naszym badaniu kontaktowała się z 10,4 domenami stron trzecich na tym etapie. Już sama ta liczba pokazuje, ile się dzieje, zanim użytkownik zobaczy baner, nie mówiąc o kliknięciu czegokolwiek.

Etap 3: Wykrywanie banera i CMP

To jeden z najtrudniejszych problemów inżynieryjnych w systemie. Banery zgody nie są standaryzowane. Obejmują one zarówno dopracowane widgety CMP z dobrze znanymi strukturami DOM, jak i niestandardowe dialogi modalne, wysuwane paski i nakładki na całą stronę.

Nasze wykrywanie wykorzystuje warstwowe podejście:

1. Wykrywanie znanych skryptów CMP. Sprawdzamy URL-e skryptów i globalne obiekty JavaScript powiązane z głównymi CMP (Cookiebot, OneTrust, Usercentrics, Didomi, Complianz i wieloma innymi).

2. Dopasowanie zweryfikowanych selektorów. Dla każdej znanej CMP utrzymujemy zestaw selektorów CSS, które niezawodnie identyfikują kontener banera, przycisk akceptacji i przycisk odrzucenia.

3. Dopasowanie kompatybilnych selektorów. Szerszy zestaw selektorów, które działają dla wielu wersji CMP, ale mogą być mniej precyzyjne.

4. Ogólne heurystyki. Dla stron korzystających z niestandardowych lub niezidentyfikowanych rozwiązań zgody (34,7% banerów w naszym badaniu), uciekamy się do wykrywania heurystycznego: szukamy elementów o stałej pozycji z tekstem związanym ze zgodą, przycisków z typowymi etykietami („Akceptuj wszystkie", „Odrzuć", „Zarządzaj preferencjami") i wzorców strukturalnych typowych dla dialogów zgody.

5. Sondowanie API CMP. Niektóre CMP udostępniają API JavaScript (np. API IAB TCF). Sondujemy te API i używamy ich do weryfikacji wykrytego stanu zgody.

To warstwowe podejście jest konieczne, ponieważ żadna pojedyncza strategia nie działa w całej różnorodności internetu. Nawet nasze najbardziej specyficzne detektory CMP napotykają warianty wersji, niestandardowe style, testy A/B i modyfikacje specyficzne dla klientów.

Etap 4: Interakcja zgody

Po wykryciu banera skaner wchodzi z nim w interakcję. Dla głównego skanu klika przycisk akceptacji, aby obserwować pełne zachowanie po zgodzie. Dla testu procesu odrzucania klika przycisk odrzucenia, a następnie przeładowuje, aby sprawdzić consent respawn.

Timing interakcji ma znaczenie. Czekamy, aż strona się ustabilizuje po kliknięciu, uwzględniając animacje, ponowną ewaluację skryptów i opóźnione uruchamianie tagów. Błąd w tym zakresie oznacza albo przeoczenie śledzenia uruchamianego po krótkim opóźnieniu, albo fałszywe alarmy dotyczące żądań już będących w trakcie realizacji.

Etap 5: Migawka po zgodzie i porównanie

Po interakcji zgody wykonujemy kolejną pełną migawkę: pliki cookie, żądania sieciowe, domeny stron trzecich. Porównanie stanu przed i po zgodzie ujawnia, co się zmieniło:

• Które nowe pliki cookie się pojawiły
• Które nowe żądania śledzenia zostały uruchomione
• Czy stan zgody w API CMP odpowiada obserwowanemu zachowaniu

Etap 6: Analiza i klasyfikacja

Surowe porównanie zasila wiele modułów analizy:

• Klasyfikacja plików cookie. Każdy plik cookie jest dopasowywany do naszej bazy danych w celu kategoryzacji jako istotny, analityczny, marketingowy lub nieznany.
• Dopasowanie trackerów. Żądania sieciowe są sprawdzane wobec baz danych wzorców trackerów.
• Sprawdzenie czasu życia plików cookie. Oznaczamy pliki cookie przekraczające zalecane przez CNIL i inne krajowe organy ochrony danych maksimum 13 miesięcy. Nasz skan znalazł 58 127 takich plików cookie na 26 250 stronach internetowych.
• Audyt dostępności. Oceniamy wykryty baner pod kątem rozmiaru celów dotykowych, kontrastu kolorów i nawigacji klawiaturą.
• Walidacja Consent Mode. Dla stron korzystających z Google Consent Mode porównujemy zadeklarowany stan zgody z obserwowanym zachowaniem.
• Ocena ryzyka. Ustalenia są agregowane do oceny ryzyka uwzględniającej wagę, liczbę i kategorię naruszeń.

Odkrycie Consent Respawn

Consent respawn nie był kategorią, którą celowo szukaliśmy. Wyłonił się z danych.

Podczas testowania procesu odrzucania zauważyliśmy wzorzec: niektóre strony pokazywały czysty stan plików cookie zaraz po kliknięciu odrzuć, ale pliki cookie wracały po przeładowaniu strony. Naszym początkowym założeniem był problem z timingiem w skanerze. Po zbadaniu potwierdziliśmy, że to było prawdziwe zachowanie: skrypty stron trzecich ponownie ustawiały pliki cookie przy każdym ładowaniu strony, niezależnie od stanu zgody przechowywanego przez CMP.

Dodaliśmy jawne wykrywanie respawn do pipeline: po zakończeniu procesu odrzucania skaner przeładowuje stronę, czeka na jej stabilizację i porównuje stan plików cookie z migawką po odrzuceniu. Jeśli pliki cookie usunięte przez akcję odrzucenia pojawiają się ponownie, jest to oznaczane jako consent respawn.

Znaleźliśmy 1 642 strony wykazujące to zachowanie, z 4 932 indywidualnymi plikami cookie, które się pojawiły ponownie. Wzorzec jest szczególnie powszechny na stronach korzystających z menedżerów tagów z niepełną integracją zgody -- menedżer tagów respektuje sygnał CMP, ale bezpośrednio osadzony skrypt tego nie robi.

Wykrywanie unikania botów

Podczas badania zidentyfikowaliśmy 137 stron internetowych, które wydają się celowo ukrywać swój baner zgody przed zautomatyzowanymi skanerami.

Wzorzec: te strony serwują w pełni funkcjonalny baner zgody zwykłym przeglądarkom, ale tłumią go, gdy wykrywają cechy zautomatyzowanego przeglądania. Baner po prostu nie pojawia się w naszej sesji headless Chromium, ale pojawia się podczas ręcznej wizyty w przeglądarce pod tym samym URL.

Heurystyki wykrywania obejmują sygnały wykrywalne przez CDP (navigator.webdriver), wykrywanie oparte na timingu i behawioralny fingerprinting. Stosujemy środki zaradcze wobec najczęstszych wzorców wykrywania botów, ale niektóre strony stosują na tyle wyrafinowane wykrywanie, że baner jest skutecznie ukryty przed zautomatyzowaną weryfikacją zgodności.

To niepokojące ustalenie. Jeśli strona internetowa celowo ukrywa swój mechanizm zgody przed skanerami zgodności, rodzi to pytania o cel tego mechanizmu. Oznaczamy te strony osobno w naszych wynikach.

Ograniczenia

Żaden zautomatyzowany system nie może idealnie odwzorować każdego ludzkiego doświadczenia przeglądania. Oto znane ograniczenia:

Wrażliwość na GeoIP. Niektóre strony internetowe serwują różne treści lub przepływy zgody w zależności od geolokalizacji IP odwiedzającego. Nasze skany były wykonywane z określonych lokalizacji sieciowych, co oznacza, że możemy nie widzieć dokładnie tego samego doświadczenia co odwiedzający w każdym kraju UE. Shadow DOM i złożoność frameworków. Nowoczesne frameworki JavaScript i enkapsulacja Shadow DOM mogą ukrywać elementy interfejsu zgody przed standardowymi zapytaniami DOM. Nasze wykrywanie obsługuje wiele takich przypadków, ale niektóre niestandardowe implementacje mogą zostać pominięte. Asynchroniczne i opóźnione ładowanie. Niektóre banery zgody lub skrypty śledzenia ładują się asynchronicznie ze znacznymi opóźnieniami. Stosujemy hojne limity czasu, ale skrypt uruchamiający się 30 sekund po załadowaniu strony może zostać pominięty przez skan czekający 15 sekund. Aplikacje jednostronicowe. SPA zarządzające stanem zgody całkowicie w JavaScript po stronie klienta bez wywoływania wykrywalnych zmian DOM są trudniejsze do wiarygodnej oceny. Nasz wskaźnik 14,9% wyników niejednoznacznych częściowo odzwierciedla to wyzwanie. Język banera zgody. Wykrywamy przyciski za pomocą kombinacji selektorów i dopasowania tekstu. Baner w języku nieobsługiwanym przez nasze dane lokalizacyjne może nie zostać prawidłowo zidentyfikowany.

Te ograniczenia przyczyniają się do naszego wskaźnika 14,9% wyników niejednoznacznych.

Infrastruktura do skalowania

Skanowanie 97 304 stron internetowych to nie zadanie dla jednej maszyny. Infrastruktura produkcyjna wykorzystuje:

• Kolejkę roboczą wspieraną przez Redis, która dystrybuuje URL-e do workerów skanera
• Instancje workerów, z których każda zarządza pulą procesów Chromium
• PostgreSQL do trwałego przechowywania wyników skanowania, ustaleń i metadanych
• Magazyn obiektowy na artefakty dowodowe (zrzuty ekranu, pliki HAR, PDF)
• Ograniczenie szybkości i kontrole współbieżności, aby nie przeciążać stron docelowych ani własnej sieci

Każdy skan trwa około 30-90 sekund w zależności od złożoności strony, więc pełne badanie wymagało ciągłego równoległego wykonywania na wielu workerach przez kilka dni.

API

Ten sam silnik skanera, który zasilił to badanie, jest dostępny poprzez publiczne API GDPR Monitor. Możesz przesyłać żądania skanowania, odpytywać wyniki i pobierać ustrukturyzowane ustalenia i artefakty dowodowe programowo.

Jeśli budujesz narzędzia zgodności, integrujesz kontrole prywatności w CI/CD lub prowadzisz własne badania, API daje Ci dostęp do tej samej analizy behawioralnej bez budowania własnego pipeline automatyzacji Chromium.

---

Wypróbuj sam. Dokumentacja API jest dostępna na gdprprivacymonitor.eu/developers/api. Zeskanuj pojedynczy URL lub zintegruj monitoring prywatności w swoim workflow.