80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Kazdy baner cookie sklada te sama dorozumiana obietnice: kliknij „Odrzuc", a sledzenie sie zatrzyma. Baner znika i przegladasz w spokoju. Taki jest uklad, na ktorym zbudowany jest model zgody -- idea, ze uzytkownicy maja znaczacy, egzekwowalny wybor.

Przetestowalismy te obietnice na 28 891 stronach internetowych UE. W 80,4% przypadkow obietnica jest zlamana. Sledzenie jest kontynuowane po tym, jak uzytkownik jednoznacznie klika odrzuc. Pliki cookie pozostaja. Piksele reklamowe nadal sa wysylane. A na 1 642 stronach pliki cookie, ktore akcja odrzucenia poczatkowo usunela, wracaja przy nastepnym zaladowaniu strony -- wzorzec, ktory nazywamy consent respawn.

To nie jest marginalne ustalenie dotyczace kilku zle skonfigurowanych stron. Wskazuje to na systemowy problem w mechanizmie, na ktorym setki milionow mieszkancow UE polegaja w zakresie swoich praw do prywatnosci.

Co „Odrzuc" powinno robic -- prawnie

Ramy prawne sa jasne. Zgodnie z art. 5 ust. 3 dyrektywy ePrivacy przechowywanie lub uzyskiwanie dostepu do informacji na urzadzeniu koncowym uzytkownika wymaga uprzedniej zgody, z waskim wyjatkiem dla plikow cookie scisle niezbednych do uslugi, o ktora uzytkownik wyraznie prosil. Art. 7 ust. 3 GDPR dodaje, ze wycofanie zgody musi byc rownie latwe jak jej udzielenie, a administrator danych musi dzialac na podstawie tego wycofania.

Wytyczne EROD 05/2020 dotyczace zgody na podstawie GDPR precyzuja, co to oznacza dla przyciskow odrzucenia: jesli strona oferuje opcje „Akceptuj wszystko", musi rowniez oferowac rownie widoczna i rownie dostepna opcje odmowy. I ta odmowa musi byc skuteczna -- musi faktycznie zapobiec przetwarzaniu, ktore zgoda by autoryzowala.

TSUE potwierdzil to w sprawie Planet49 (C-673/17): zgoda wymaga jasnego, potwierdzajacego aktu, a wstepnie zaznaczone pola wyboru nie stanowia waznej zgody. Logicznym nastepstwem jest to, ze odmowa -- wyrazny negatywny akt -- musi byc respektowana rownie ostatecznie jak akceptacja. Jesli klikniecie „Akceptuj" wlacza sledzenie, klikniecie „Odrzuc" musi je wylaczyc. Nie czesciowo. Nie tymczasowo. Calkowicie i trwale.

Tak stanowi prawo. Nasze dane pokazuja, co dzieje sie w rzeczywistosci.

Jak testujemy proces odrzucania

Nasz test procesu odrzucania jest zaprojektowany tak, aby byc jak najbardziej zblizony do doswiadczenia prawdziwego uzytkownika klikajacego odrzuc, z dodatkiem kompleksowej instrumentacji. Oto proces krok po kroku:

Krok 1: Czysta sesja przegladarki. Skaner uruchamia czysta instancje Chromium -- bez plikow cookie, bez lokalnego magazynu, bez zbuforowanych zasobow, bez historii przegladania. To jest autentyczny odwiedzajacy po raz pierwszy bez wczesniejszego stanu zgody. Krok 2: Nawigacja i rejestracja stanu przed wyrazeniem zgody. Skaner laduje docelowy adres URL i czeka na stabilizacje strony. Przed jakakolwiek interakcja rejestruje kazdy plik cookie obecny w przegladarce, kazde wykonane zadanie sieciowe i kazda skontaktowana domene strony trzeciej. To jest punkt odniesienia przed wyrazeniem zgody -- co strona robi, zanim uzytkownik ma jakakolwiek mozliwosc dokonania wyboru. Krok 3: Wykrywanie banera zgody. Korzystajac z naszej biblioteki wykrywania obejmujacej 45 znanych CMP i heurystyk ogolnych, skaner identyfikuje mechanizm zgody i lokalizuje przycisk odrzucenia. Ten krok wykorzystuje podejscie warstwowe: najpierw sprawdza znane sygnatury skryptow CMP i powiazane z nimi struktury DOM, a nastepnie przechodzi do ogolnego wykrywania elementow o stalej pozycji z tekstem zwiazanym ze zgoda i etykietami przyciskow takimi jak „Odrzuc wszystko", „Odmow", „Nie zgadzam sie" lub rownowazne tlumaczenia. Krok 4: Klikniecie odrzuc. Skaner klika przycisk odrzucenia i czeka na stabilizacje strony. „Stabilizacja" oznacza oczekiwanie na zakonczenie oczekujacych zadan sieciowych, zatrzymanie mutacji DOM oraz zakonczenie wszelkich animacji lub przejsc. Stosujemy hojne limity czasowe, aby uniknac falszywych pozytywow z wolnych implementacji CMP. Krok 5: Migawka po odrzuceniu. Skaner ponownie rejestruje kompletny stan: wszystkie pliki cookie, cala aktywnosc sieciowa, wszystkie domeny stron trzecich. Ta migawka jest porownywana z punktem odniesienia sprzed wyrazenia zgody, aby ustalic, co sie zmienilo. Krok 6: Przeladowanie i sprawdzenie consent respawn. Skaner przeladowuje strone i ponownie czeka na jej stabilizacje. Nastepnie wykonuje ostateczna migawke. Ten krok jest kluczowy: ujawnia, czy akcja odrzucenia jest trwala (respektowana miedzy ladowaniami stron), czy tez pliki cookie i sledzenie aktywuja sie ponownie, gdy strona laduje sie na nowo. Jesli pliki cookie usuniete w kroku 5 pojawiaja sie ponownie w kroku 6, to jest consent respawn.

Kazdy krok generuje opatrzone znacznikiem czasu, archiwalne dowody: pelne inwentarze plikow cookie z nazwami, wartosciami, domenami, datami wygasniecia i flagami; kompletne logi zadan sieciowych z adresami URL, metodami, kodami odpowiedzi i czasami; oraz pelnoekranowe zrzuty ekranu. Ten lancuch dowodow pozwala na weryfikacje i zakwestionowanie kazdego pojedynczego ustalenia.

Wyniki: 80,4% awarii

Sposrod 28 891 stron, na ktorych pomyslnie ukonczylismy pelny test procesu odrzucania:

• 5 650 (19,6%) przeszlo pomyslnie. Po kliknieciu odrzuc nieistotne pliki cookie zostaly usuniete, zadania sledzace zostaly zatrzymane, a odrzucenie zostalo utrzymane pomiedzy przeladowaniami strony.
• 23 241 (80,4%) nie przeszlo. Sledzenie kontynuowano w jakiejs formie po tym, jak uzytkownik jednoznacznie kliknal odrzuc.

Awarie nie sa jednolite. Naleza do odrebnych kategorii, ktore sie nakladaja -- pojedyncza strona moze jednoczesnie wykazywac wiele trybow awarii.

Trwale pliki cookie: 10 848 stron

Na 10 848 stronach (37,5% testowanych) nieistotne pliki cookie pozostaly w przegladarce po zakonczeniu procesu odrzucania. Sa to pliki cookie zaklasyfikowane jako analityczne, marketingowe lub sledzace, ktore powinny zostac usuniete lub ktorym powinno sie zapobiec po akcji odrzucenia.

Najczesciej wystepujace trwale pliki cookie naleza do Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) i roznych platform reklamowych. W wielu przypadkach CMP pomyslnie usuwa niektore pliki cookie, ale nie udaje mu sie wychwycic wszystkich -- co sugeruje niepelna integracje miedzy platforma zarzadzania zgoda a pelnym zestawem skryptow stron trzecich na stronie.

Obecnosc tych plikow cookie po odrzuceniu nie jest jedynie problemem estetycznym. Kazdy z nich jest trwalym identyfikatorem, ktory laczy biezaca sesje uzytkownika z przeszlymi i przyszlymi wizytami. Plik cookie `_ga`, na przyklad, jest unikalnym identyfikatorem klienta, ktorego Google Analytics uzywa do budowania podluznego profilu zachowan uzytkownika w sesjach. Jesli pozostaje po odrzuceniu, przegladanie uzytkownika nadal jest sledzone i agregowane niezaleznie od wyrazonej odmowy.

Trwale trackery: 14 547 stron

Na 14 547 stronach (50,3% testowanych) uslugi sledzace pozostaly aktywne po odrzuceniu -- co oznacza, ze przegladarka nadal wykonywala zadania do znanych domen sledzacych nawet po tym, jak uzytkownik kliknal przycisk odrzucenia.

To jest odrebny tryb awarii od trwalosci plikow cookie. Tracker moze byc aktywny bez ustawiania pliku cookie: zadania pikselowe, wywolania beacon i ladowanie skryptow przekazuja informacje (co najmniej adres IP uzytkownika, strone odwolujaca i dane czasowe) do serwerow stron trzecich niezaleznie od tego, czy plik cookie jest przechowywany. Jest to czasem nazywane „sledzeniem bez plikow cookie" i staje sie coraz bardziej powszechne w miare zaostrzania przez przegladarki ograniczen dotyczacych plikow cookie stron trzecich.

Roznica miedzy liczba plikow cookie (10 848) a liczba trackerow (14 547) jest znaczaca. Oznacza to, ze na okolo 3 700 stronach akcja odrzucenia pomyslnie usunela pliki cookie, ale nie zdolala zapobiec kontynuacji zadan sledzacych. CMP obsluzylo czyszczenie plikow cookie, ale nie zablokowalo skryptow generujacych ruch sledzacy. Wskazuje to na czesty problem architektoniczny: CMP jest skonfigurowane do zarzadzania plikami cookie (usuwania ich po odrzuceniu, zapobiegania im przy ladowaniu), ale nie do zarzadzania wykonywaniem skryptow.

Consent respawn: 1 642 strony, 4 932 pliki cookie

Consent respawn jest najbardziej niepokojacym wzorcem, jaki zidentyfikowalismy. Na 1 642 stronach pliki cookie, ktore zostaly pomyslnie usuniete przez akcje odrzucenia, pojawily sie ponownie po przeladowaniu strony. Na tych stronach 4 932 pojedyncze pliki cookie wykazywaly to zachowanie odradzania sie.

Consent respawn nie jest bladem jednego CMP ani jednej konfiguracji. To jest problem strukturalny w sposobie, w jaki zgoda jest implementowana w calym stosie webowym.

Jak plik cookie wraca po usunieciu. Gdy uzytkownik klika odrzuc, prawidlowo skonfigurowane CMP robi dwie rzeczy: usuwa istniejace nieistotne pliki cookie (ustawiajac ich date wygasniecia na przeszla) i aktualizuje zapis zgody (zazwyczaj sam plik cookie lub wpis w localStorage), ktory mowi logice blokujacej CMP, aby zapobiec uruchamianiu nieistotnych skryptow przy przyszlych ladowaniach stron. Jesli oba te elementy dzialaja, uzytkownik jest czysty: bez plikow cookie sledzacych, bez skryptow sledzacych.

Consent respawn nastepuje, gdy usuwanie sie powiodlo, ale blokowanie zawiodlo. Najczestszy scenariusz:

1. CMP usuwa plik cookie `_ga`, gdy uzytkownik klika odrzuc.

2. CMP ustawia plik cookie ze stanem zgody rejestrujacy, ze uzytkownik odmowil analityki.

3. Przy nastepnym zaladowaniu strony CMP sprawdza stan zgody i wie, ze uzytkownik odmowil.

4. Ale: tag skryptu Google Analytics jest osadzony bezposrednio w szablonie strony (poza menedzerem tagow) lub jest ladowany przez regule menedzera tagow, ktora nie sprawdza stanu zgody.

5. Skrypt GA laduje sie, nie widzi pliku cookie `_ga` i tworzy nowy.

6. Decyzja uzytkownika o odrzuceniu zostala nadpisana.

Warianty tego wzorca obejmuja: skrypty stron trzecich ladowane przez zakodowane na stalo tagi `