Automatyczne blokowanie skryptów: jak działa blokowanie przed wyrażeniem zgody
Automatyczne blokowanie skryptów (nazywane też blokowaniem przed zgodą lub auto-blokowaniem) uniemożliwia uruchamianie nieistotnych skryptów, dopóki użytkownik nie wyrazi zgody. Jest to wymóg prawny wynikający z art. 5 ust. 3 dyrektywy ePrivacy: żadne pliki cookie ani technologie śledzące nie mogą być umieszczane na urządzeniu użytkownika bez uprzedniej świadomej zgody, chyba że są ściśle niezbędne do świadczenia usługi, o którą użytkownik poprosił.
Bez automatycznego blokowania strona internetowa ładująca Google Analytics, Facebook Pixel lub jakikolwiek zewnętrzny skrypt marketingowy będzie ustawiać pliki cookie i zbierać dane, zanim użytkownik zdąży dokonać wyboru dotyczącego zgody. Stanowi to naruszenie przepisów niezależnie od tego, czy wyświetlany jest baner zgody.
Dlaczego ręczne oznaczanie skryptów nie wystarcza
Tradycyjne podejście do ładowania skryptów w oparciu o zgodę wymaga od programistów ręcznego oznaczenia każdego skryptu na stronie. Każdy skrypt trzeba zmodyfikować tak, aby domyślnie się nie ładował, a następnie warunkowo aktywować go, gdy użytkownik wyrazi zgodę na odpowiednią kategorię. Zazwyczaj polega to na zmianie type="text/javascript" na type="text/plain" oraz dodaniu atrybutu data wskazującego kategorię zgody.
To podejście ma poważne wady:
- Każdy nowy skrypt dodany do strony musi zostać ręcznie oznaczony. Jeśli zespół marketingowy doda nowy piksel śledzący za pomocą menedżera tagów, uruchomi się on bez zgody, chyba że ktoś pamięta o skonfigurowaniu reguły blokowania.
- Skrypty zewnętrzne często dynamicznie ładują kolejne skrypty. Zablokowanie skryptu nadrzędnego niekoniecznie blokuje skrypty podrzędne, które by załadował.
- Skryptów osadzonych bezpośrednio w kodzie HTML strony nie da się łatwo przechwycić.
- To podejście jest zawodne. Jeden pominięty skrypt oznacza niezgodne z przepisami zbieranie danych.
Jak działa automatyczne blokowanie
Platforma do zarządzania zgodami z funkcją automatycznego blokowania stosuje inne podejście. Zamiast wymagać od programistów oznaczania poszczególnych skryptów, CMP przechwytuje całe ładowanie skryptów na poziomie przeglądarki i blokuje wszystko, co nie jest ściśle niezbędne.
Proces przebiega następująco:
- CMP ładuje się jako pierwszy skrypt w sekcji
<head>strony, przed wszystkimi innymi skryptami. - Przechwytuje mechanizmy ładowania skryptów przeglądarki, w tym
document.createElement('script'), wykonywanie skryptów inline oraz skrypty wstrzykiwane dynamicznie. - Każdy skrypt jest porównywany z bazą klasyfikacyjną. Skrypty pochodzące ze znanych domen analitycznych, reklamowych i mediów społecznościowych są identyfikowane i kategoryzowane.
- Skrypty sklasyfikowane jako nieistotne są przetrzymywane w kolejce. Nie uruchamiają się, nie ustawiają plików cookie i nie wykonują żądań sieciowych.
- Gdy użytkownik wyrazi zgodę na określoną kategorię, skrypty z tej kategorii oczekujące w kolejce zostają zwolnione i mogą się normalnie wykonać.
- Jeśli użytkownik odrzuci kategorię, skrypty z tej kategorii pozostają zablokowane przez cały czas trwania sesji.
Co jest blokowane
Automatyczne blokowanie zazwyczaj klasyfikuje skrypty w czterech kategoriach zgodnych ze standardowymi kategoriami zgód na pliki cookie:
| Kategoria | Przykłady | Blokowane przed zgodą |
|---|---|---|
| Ściśle niezbędne | Procesory płatności, uwierzytelnianie, zarządzanie sesją, samo CMP | Nie (zawsze dozwolone) |
| Analityczne | Google Analytics, Hotjar, Matomo, Plausible | Tak |
| Marketingowe | Google Ads, Facebook Pixel, LinkedIn Insight, TikTok Pixel | Tak |
| Preferencje | Preferencje językowe, personalizacja interfejsu, narzędzia do testów A/B | Tak |
Problem z czasem ładowania
Aby automatyczne blokowanie działało prawidłowo, CMP musi być pierwszym skryptem ładowanym na stronie. Jeśli jakikolwiek nieistotny skrypt załaduje się przed CMP, wykona się bez zgody. Dlatego znacznik skryptu CMP nie może korzystać z atrybutów defer ani async i musi znajdować się przed każdym innym skryptem w sekcji <head>.
Jest to ta sama architektura stosowana przez każde zgodne z przepisami CMP: Cookiebot, OneTrust, CookieYes i Passiro — wszystkie wymagają synchronicznego ładowania jako pierwszy skrypt w nagłówku dokumentu.
Współpraca z Google Consent Mode
Automatyczne blokowanie skryptów działa równolegle z Google Consent Mode v2. Podczas gdy Consent Mode dostosowuje zachowanie własnych tagów Google w przypadku odmowy zgody (przełączając na pomiary bez plików cookie), automatyczne blokowanie w ogóle uniemożliwia uruchamianie wszystkich nieistotnych skryptów.
Oba mechanizmy się uzupełniają: Consent Mode elegancko obsługuje tagi Google (umożliwiając modelowanie konwersji), natomiast auto-blokowanie zajmuje się całą resztą (zewnętrzne piksele, widżety społecznościowe, skrypty reklamowe od dostawców spoza Google).
Automatyczne blokowanie a Passiro
Passiro oferuje automatyczne blokowanie skryptów w swoim bezpłatnym widżecie zgody. Gdy skrypt Passiro się załaduje, identyfikuje i blokuje nieistotne skrypty, zanim zdążą się wykonać. Nie jest wymagane żadne ręczne oznaczanie skryptów.
Baza klasyfikacyjna opiera się na społecznościowej liście blokad EasyPrivacy (GPL-3.0), która obejmuje ~4900 domen śledzących, analitycznych i reklamowych i jest odświeżana codziennie. Jest ona znacznie obszerniejsza niż zastrzeżone, ręcznie kuratorowane listy stosowane przez większość komercyjnych CMP — Cookiebot, OneTrust i inne zazwyczaj opierają się na bazach o rząd wielkości mniejszych.
W połączeniu z IAB TCF v2.3 oraz Google Consent Mode v2 automatyczne blokowanie gwarantuje, że żadne dane nie są zbierane przed udzieleniem zgody, spełniając wymogi art. 5 ust. 3 dyrektywy ePrivacy oraz art. 6 GDPR.
Czy Twoja strona jest zgodna z przepisami o cookies?
Przeskanuj swoją stronę za darmo i znajdź wszystkie cookies w kilka minut.
Przeskanuj cookies za darmo