Problemy Kombinexu - jak (nie) wdrażać zewnętrznych skryptów

W zeszłym tygodniu obejrzałem krótki film (link Invidious) od Google. Pokazuje on, jak wdrożyć tzw. consent mode w Google Analytics. O ile o samym narzędziu pisałem już w zeszłym roku, o tyle dziś chciałbym skupić się szerzej na typowych problemach przy wdrażaniu skryptów analitycznych i zewnętrznych narzędzi na stronach internetowych.

Na czym polega problem?

Znaczna większość narzędzi do analityki oraz innych, takich jak chat, zewnętrzne formularze czy inne widgety przetwarza dane osobowe użytkowników strony. Co więcej, zgodnie z orzeczeniem niemieckiego sądu w sprawie dotyczącej używania Google Fonts, nasuwa się przypuszczenie, że każdy zewnętrzny skrypt przetwarza dane osobowe co najmniej w zakresie adresu IP użytkownika.

Wiadomo, że gdy użytkownik wchodzi na naszą stronę, pozyskujemy jego adres IP. To całkowicie normalne działanie związane z wymianą ruchu w protokole HTTP. Sytuacja jest jednak zgoła inna, gdy nasza strona (a ściślej: przeglądarka użytkownika na „polecenie” strony) wykonuje żądania do innych podmiotów, udostępniając im adres IP użytkownika. Jeżeli odwoływanie się do zasobów zewnętrznych nie jest konieczne, gdyż nie obsługują one usług wymienionych na początku, to nie powinniśmy ich używać.

W tym miejscu warto przypomnieć fragment motywu 39 preambuły RODO:

[...] Dane osobowe powinny być przetwarzane tylko w przypadkach, gdy celu przetwarzania nie można w rozsądny sposób osiągnąć innymi sposobami. [...]

Zatem w sytuacji, gdy odwołujemy się do zewnętrznych zasobów, takich jak np. biblioteki, czcionki, style, powinny być one wczytywane z naszego serwera (a nie z zewnętrznych CDN-ów dostawców owych zasobów). Nie będę dziś jednak skupiał się na takich przypadkach, ponieważ temat ten świetnie i rzeczowo opracowała Pani Mecenas Agnieszka Rapcewicz z Fundacji Internet. Czas Działać!

Co jednak w przypadku zewnętrznych narzędzi, których nie jesteśmy w stanie wczytywać z naszego serwera? Tym właśnie dziś się zajmiemy.

Przykład

Wyobraźmy sobie pewną firmę, nazwijmy ją Kombinex (podobieństwo do istniejących podmiotów jest przypadkowe i niezamierzone). Zatrudnia ona kilkunastu pracowników, a jej głównym obszarem działania jest doradztwo marketingowe. Podstawowym źródłem pozyskiwania klientów jest dla nich strona internetowa.

Pewnego dnia dyrektor Kombinexu wpada na pomysł, by zacząć korzystać na stronie z narzędzi do analityki online. Chce użyć Google Analytics. Narzędzie to przetwarza dane osobowe, więc po analizie biznesowej projekt trafia do kancelarii prawnej, która świadczy usługi dla Kombinexu. Prawnicy dostarczają dokumentację: aktualizacje do polityki prywatności i klauzule zgód na stronę internetową (zakładamy, że Kombinex nie prowadzi Rejestru Czynności Przetwarzania ani żadnych innych dokumentów, które wymagałyby zmiany przy wdrożeniu).

Następnie projekt przekazywany jest do działu IT odpowiedzialnego m.in. za stronę internetową firmy. Otrzymują oni dokumentację od prawników i instrukcje w zakresie narzędzi i dostępów, które należy potem udzielić. Mając uprawnienia administracyjne w domenie Kombinexu (każdy pracownik ma konto w Google Workspace) tworzą specjalne konto, służące do obsługi narzędzia. Korzystając z niego, konfigurują analitykę i generują skrypty na stronę. Tu właśnie dochodzimy do punktu kulminacyjnego.

Standardowy kod Google Analytics wygląda tak:

Konieczne było jednak uwzględnienie zaleceń prawników. Na potrzeby artykułu założę dwa warianty, na które mogli zdecydować się pracownicy Kombinexu.

Wariant 1: wdrożenie consent mode

Dział IT wdrożył skrypt, używając consent mode. Domyślnie skrypt wczytywany był w trybie odmowy, tzn. że wszystkie zgody miały ustawioną wartość denied. Wiązało się to z dodaniem takiego kodu:

Użytkownik mógł wyrazić zgodę, klikając odpowiedni przycisk w stworzonym przez programistów oknie. Jego zmiany były uwzględniane przez konfigurację gtag (jak w powyższym przykładzie). Na potrzeby artykułu optymistycznie założę, że okno to było w pełni zgodne z prawem, tzn. że zgoda wyrażona w nim spełniała warunki RODO (głównie chodzi art. 7 ust. 3 RODO, według którego wyrażenie zgody musi być równie łatwe jak jej niewyrażenie).

Okazuje się jednak, że mimo zastosowanej konfiguracji, skrypt zbiera i przekazuje dane użytkownika do Google. Gdy po otwarciu strony zajrzymy w narzędzia deweloperskie przeglądarki, naszym oczom ukazują się następujące żądania HTTP:

Identyfikatory wysyłane do Google zdają się być unikalne, co pozwala wyodrębnić wpisy dotyczące jednego użytkownika. Mimo że nie wiadomo, co się z nimi dzieje dalej, można wysnuć hipotezę, że taki stan rzeczy łamie RODO. Konfiguracja zgód zmienia tylko tyle, że gdy dane użytkownika wysyłane są do Google, dokładana jest do nich adnotacja użytkownik nie wyraził zgody, proszę nie przetwarzać tych danych. Jeżeli dane nie są dalej przechowywane/utrwalane, po co skrypt Google je zbiera i wysyła? Takie działanie stoi w sprzeczności z art. 5 ust. 1 lit. c) RODO.

Wariant 2: obsługa zgód przez zewnętrzny CMP

Drugim sposobem na wdrożenie Google Analytics było użycie zewnętrznego systemu CMP (Consent Management Platform). Na potrzeby artykułu uznajmy, że Kombinex skorzystał z prostej usługi Cookie Banner Generator (warto zaznaczyć, że zgoda na przetwarzanie danych osobowych, to nie to samo co „zgoda na cookies” – można przetwarzać dane osobowe bez użycia cookies, ale i używać cookies i nie przetwarzać danych osobowych).

Po wdrożeniu strona wyglądała tak:

Jedynym problemem są teraz czcionki (o których wspomniałem na początku), ale tym się teraz nie zajmujemy – nie modyfikowałem CMP, bo to tylko przykład. Sam kod odpowiedzialny za jej działanie jest hostowany na tym samym serwerze, co strona (nie jest importowany z serwerów dostawcy usługi, co wiązałoby się z przetwarzaniem co najmniej adresów IP). Wszystko więc jest tu zgodne z RODO – dopóki użytkownik nie wyrazi zgody, żadne dane nie są wysyłane do Google.

Ważne jest, by wszystko działało dokładnie w taki sposób. Skrypty nie mogą wczytywać się poza CMP, ponieważ wtedy nie spełnia ona swojego celu, a jakakolwiek zgoda wyrażona przez użytkownika przestaje być respektowana. Niestety praktyka pokazuje, że takich przypadków nie brakuje. Nierzadko spotkać można stronę z poprawnie stworzonym bannerem, który jednak realnie jest widmem, bo dane zostały przesłane podmiotom trzecim, zanim w ogóle został on wyświetlony.

Jak wdrożyć skrypty zewnętrzne zgodnie z RODO

Jeśli wdrożenie zewnętrznego narzędzia jest naprawdę konieczne, a przetwarza ono dane osobowe, najlepszym wyborem będzie zastosowanie zewnętrznego (lub autorskiego) CMP. Warto pamiętać, by wszystkie pliki związane z działaniem CMP były serwowane z Twojego serwera, a nie CDN-ów dostawcy narzędzia. Istotne jest również zadbanie o to, by wyrażenie zgody było równie łatwe jak jej niewyrażenie (art. 7 ust. 3 RODO). Możliwe, że ukaże się druga część tego artykułu, w której przyjrzę się privacy sandbox (Google) i rozwiązaniom opartym o proxy.

Skąd biorą się takie problemy…

Tak jak wspomniałem, w przypadku Kombinexu projekt wdrożenia skryptów Google Analytics na stronie przeszedł przez ręce prawników, którzy zadbali o zgodne z RODO klauzule. Błędy pojawiły się dopiero przy podjęciu tematu przez dział IT, który odpowiadał za wdrożenie od strony technicznej.

Warto pamiętać, że większość programistów raczej nie zna RODO na tyle, by zwrócić uwagę na takie błędy w tworzonych rozwiązaniach. Sam fakt, że projekt został zaopiniowany przez prawnika, nie wyklucza problemów przy tworzeniu czy wdrażaniu rozwiązania.

Źródła, materiały

Dostęp: 25.01.2024

• Wyrok w sprawie Google Fonts
• Treść RODO
• https://www.internet-czas-dzialac.pl/google-fonts-i-rodo/
• https://github.com/googleanalytics/ga4-tutorials

Zdjęcie z okładki jest autorstwa Tiger Lily i pochodzi z serwisu Pexels.