W przeciwieństwie do śledzenia lub oznaczania na stronie klienta, rejestrowanie użytkowników odbywa się w przypadku śledzenia serwerowego w sposób pośredni. Z browsera użytkownika jest wysłane zdarzenie śledcze do własnego serwera i dalej do ostatecznego celu. Z tego wynikają interesujące kwestie dotyczące ochrony danych osobowych.
Wprowadzenie
Serwerowe śledzenie lub s_erver side tracking_ nazywane jest czasem również serwerowym taggingiem. To synonim pochodzi prawdopodobnie od tego, że Google wspiera podejście serwerowe do śledzenia za pomocą takiego narzędzia jak Tagging Tool. Tagging oznacza tak naprawdę uzupełnienie informacji. Śledzenie natomiast oznacza śledzenie użytkowników, aby poznać ich zachowanie.
Co to jest śledzenie serwerowe?
W przeciwieństwie do tego stoi klasyczne śledzenie, które również nazywane jest śledzeniem z klienta. Klientem może być np. przeglądarka użytkownika odwiedzającego stronę internetową. Może to być także aplikacja.
Podczas Server Side Tracking zazwyczaj jest wysyłane zdarzenie tracking z własnej strony internetowej do własnego serwera i stamtąd w większości niezmienione jest przekazywane do właściwego punktu końcowego. Podczas Tagging natomiast informacje z zdarzenia tracking są na własnym serwerze najpierw uzupełniane, przed tym, żeby zdarzenie to zostało przekazane do jednego lub kilku punktów końcowych.
Pobieranie danych na stronie klienta i serwera
Technika śledzenia serwerowego była zawsze możliwa, ale nie była szczególnie omawiana i nie była popularna ze względu na dotychczasowe możliwości. Rosnąca groźba kary dla osób naruszających dane takich jak Google (i wszyscy, którzy usługę trzeciej strony używają bezrefleksyjnie) spowodowała przełom.
Poniższe schematy przedstawiają różnice między tradycyjnym a nowoczesnym śledzeniem oraz dostępne opcje. Na przykład Google Tag Manager (GTM), który jest używany do załadowania Google Analytics (GA). Jest to częsty przypadek na stronach internetowych. Zamiast Google Analytics są czasem załadowywane inne narzędzia przez Tag Manager.
Zwykłe śledzenie opiera się na załadowaniu GTM i GA z osobnego serwera Google. Ten podejście nazywa się Monitoring z punktu widzenia klienta.
Grasem tło stanowi serwer, który pod kątem ochrony danych jest raczej niekrityczny, a mianowicie ten na którym działa odwiedzana strona internetowa. Serwery zielone są serwerami trzeciej strony (Third-Party), tutaj serwery Googlea. Google został wymieniony jedynie jako przykład ilustracyjny. Możliwe są serwery od każdego możliwego dostawcy.
Czerwone strzałki wskazują na przesyłanie danych. Załadunek GTM wymaga dwóch przesyłań danych. Pierwszy jest pobieraniem, czyli zapytaniem. Drugi transfer to odpowiedź na zapytanie. W przypadku Google Analytics jest to analogiczne. Zatem dla pobrania GTM i GA razem powstają cztery przesyłania danych. Piąte pokazane przesyłanie danych to protokowanie akcji użytkownika przez Google Analytics.
Klienckie śledzenie jest oczywiście łatwe do wykrycia. Wystarczy się tylko przyjrzeć, do jakich serwerów (adresów) strona internetowa nawiązuje połączenie. Każdy widzi natychmiast, że wywołanie adresu google-analytics.com ma coś wspólnego z Google Analytics.
Teraz można użyć takiego zwanej Tunel lub Proxy, aby Google Analytics pośrednio załadować i/lub wysłać zdarzenia śledzące do Google Analytics. Zaletą jest to, że ostateczne śledzenie może być takie samo dla wszystkich urządzeń końcowych i platform (aplikacje, strony internetowe). Technicznie wygląda to następująco:
Prawo ochrony danych nie przyniosło wieku, bo tunel, przez który dostęp jest do Google Analytics, znajduje się na serwerze trzecim. Google oferuje takie serwery za darmo w ramach Google Cloud. Zyski z Platformy chmurowej Google (GCP) nie powinny być dla większości osób istotne, bo implementacja jest dość skomplikowana. Tag Manager jest w tej wersji wcześniej załadowany w sposób tradycyjny, co bez zgody nie jest dopuszczalne.
Z transportowym tunelem można zataić wywołanie Google Analytics do pewnego stopnia. Trzeba się tylko nie dopuścić do tego, by się go złapać. Wielka jest bowiem szansa ujawnienia się. Można również załadunkiem przez ten tunel załadować Tag Managera. W przykładzie nie rozważyłem tej sytuacji. Poniżej opiszę tę sytuację.
Następnie przedstawiam alternatywę do opisanego wcześniej modelu. Wszystko jest identyczne, tylko Transport-Tunnel jest osobnym serwerem. Idealnie byłoby, gdyby Transport-Tunnel miał tę samą adres jak właśnie odwiedzona strona internetowa.
Analityka Google jest tu całkowicie dostępna za pomocą własnego serwera tunelowego.
W tym modelu skrypt Google Analytics może być ładowany z serwera Google, innego dostawcy lub własnego serwera. Przedstawiono pierwszą z tych opcji. Z zewnątrz nie ma różnicy. Prawnie ochrona danych byłaby w tej pierwszej wersji gorsza, ale drugiej lub trzeciej dla osoby spoza systemu nie dostrzeżalna i tym samym nieprzekazalna.
Implementacja tego scenariusza jest skomplikowana, ponieważ musi być zainstalowany własny tunel transportowy. Przyszłe zmiany w interfejsach należy uwzględnić i zwiększą one Zapobieganie awarii.
Prawidłowy udokumentowanie zgodności z prawem ochrony danych w tym scenariuszu nie jest już tak dobrze możliwe jak w poprzednim przypadku. Proces ładowania samego Google Analytics Scripts nie może być odzwierciedlony z zewnątrz. Jeśli skrypt zostanie przekazany na stronę, to przynajmniej można udowodnić, że skrypt został załadowany, ale nie z jakiego źródła. Można również używać własnej logiki do sterowania tunelami transportu Google Analytics. Jest to związane z pewnym nakładem pracy i wymaga regularnych sprawdzeń funkcjonalności, ponieważ Punkt analityczny może ulegać zmianom. Tak więc można osiągnąć maksymalną możliwą ukrycie, ale wciąż można je odgadnąć w istotnych częściach.
W ostatnim scenariuszu wszystkie przesyłania danych są obsługiwane przez własny serwer proxy.
Wielkość przesyłanych danych wskazuje już na wysoką techniczną złożoność tego scenariusza. Wszystkie transfele danych odbywają się za pośrednictwem własnego serwera. Możliwe są również kilka własnych serwerów. Jeśli serwer tunelu ma tę samą domenę co ostatnio odwiedzona strona internetowa, zdarzenia trackingu nie będą się tak szybko pojawiały jak dotąd.
W tym scenariuszu można próbować próbować wszystkich przesyłań danych ukryć. Może być to ostatecznie (szczęśliwie) tylko próba, ponieważ każda klient-strona ukrycia może zostać ujawniona. Więcej informacji znajduje się dalej niżej.
Poniższa tabela przedstawia jeszcze raz różne warianty w jednym przeglądzie:
| Scenariusz | Charakterystyka |
|---|---|
| Następujące śledzenie klienta | Zwykły sposób postępowania, łatwy do zastosowania, łatwy do odkrycia, wiele przesyłań danych do stron trzecich. |
| Monitoring serwerowy z użyciem tunelu trzeciej strony dla celów monitorowania | Nowy, niezwykły, łatwy do odkrycia, ale dla użytkowników z dużymi możliwościami. |
| Monitoring serwerowy z własnym tunikiem do monitorowania | Nowy, skomplikowany, łatwy do zatuszowania, wiele możliwości dla użytkowników zaawansowanych. |
| Obsługa serwerowa z własnym tunikiem dla wszystkich | Nowy, bardzo skomplikowany, wiele możliwości ukrywania się, bardzo wiele możliwości dla użytkowników z dużymi uprawnieniami. |
Konfiguracja tunelu dla Google Tag Managera
Google nie całkiem niesamowicie oferuje z Google Tag Managerem nowe możliwości, aby rozwiązać problem serwerowego śledzenia. Ponieważ Google Tag Manager jest wybitnym przykładem tego podejścia, często używa się również terminu serwerowe tagowanie.
GTM_ jest używany jako warstwa pośrednia do przesyłania danych zarówno do Google Analytics, jak i innych usług Google lub usług trzecich. W ten sposób Google otrzymuje dane z więcej usług niż dotąd, co umożliwia mu wyrównanie strat danych spowodowanych przez przepisy dotyczące ochrony prywatności.
Konkret wygląda konfiguracja Tag Managera tak:
Dzięki temu GTM może być poinformowany, że Google Analytics nie powinien już wysyłać danych do google-analytics.com, ale raczej do adresu analytics.example.com.
Google obiecuje tym ułatwienie śledzenia użytkowników przez kilka urządzeń jednocześnie.
Aby serwer mógł przekazywać dane otrzymane z odwiedzonej strony, musi być odpowiednio przygotowany. W istocie należy dostarczyć nową funkcjonalność, aby serwer mógł pełnić rolę pośrednika między klientem a dostawcą danych o śledzeniu. Tagging Server może być uruchomiony samodzielnie, co jest bardziej przyjazne dla ochrony prywatności. Alternatywnie takowy serwer może zostać pozyskany od dostawcy takiego jak Google w ramach Google Cloud, co od samego początku budzi kwestie dotyczące ochrony danych osobowych.
Tryby pracy
Zasadniczo is możliwe przedstawienie dwóch rodzajów tagowania z serwerowej strony. Technicznie są one porównywalne, ale w kwestiach ochrony danych osobowych pojawiają się inne pytania.
Pierwszy tryb to wykorzystanie serwera trzeciego. W praktyce może on należeć do samego siebie. Adres serwera jest tu jednak inny niż własna strona internetowa i wskazuje na adres, który sugeruje istnienie trzeciej osoby. Przykładem może być serwer instancji udostępniana przez Google Cloud, która generuje adresy URL takie jak: https://sturdy-pier-xyz.ab.r.appspot.com
Takie adresy wyglądają podejrzanie z punktu widzenia ochrony danych osobowych. Z góry można przypuszczać, że jest to procedura wymagająca zgody. W każdym przypadku należy dokładniej sprawdzić.
Drugi tryb nazywałem Proxy-tryb. Proxy jest zastępcą, który przepuszcza dane. Także serwer trzeci, który służy jako tunel, jest technicznie rzecz biorąc serwerem proxy. Jednakże serwer trzeci nie jest w aspekcie ochrony danych prawdziwym proxy. W tym kontekście proxy to według mojej definicji sam serwer.
Mode proxy używa adresu serwera, który znajduje się w tej samej domenie co odwiedzona strona internetowa. Jeśli np. użytkownik odwiedzi stronę eine-webseite-081516.de, to adres dla serwera tagowania mógłby wyglądać tak: eine-webseite-081516.de/tagging. Ponieważ na stronie internetowej często występują samouczynne odwołania, znikają one wśród innych niegroźnych odwołań.
W trybie pośrednictwa można zobowiązującego się do zgodności wywołania ukryć na pół. Gdy strona jest odwiedzana, nie widać prawie żadnego wywołania śledczego na własnej domenie. Jeśli użytkownik jednak przemieszcza się po już załadowanej stronie, np. przesuwając okno i znajduje tu serwerowe wywołanie, można już dość dobrze wnioskować o śledzeniu.
Tracking to jest nieokreślony pojęcie, które w zależności od sytuacji musi być uzupełnione o życie. W trybie proxy głównie chodzi o dwa pytania:
- Jeśli nieuzasadniony technicznie wywołanie następuje, które nie może być uzasadnione prawem do informacji?
- Czy przy wezwaniu są przesyłane pliki cookie, czy też tworzone?
Jeśli jedną z pytań można odpowiedzieć "tak", istnieje obowiązek zgody, co oznacza quasi śledzenie, jeśli chcemy wyrazić się krótko.
Ciasteczka nie da się ukryć. Kto chce śledzić użytkownika bez użycia ciasteczek, traci pewne zalety związane z nimi. Jedną z tych zalet jest łatwa rozpoznawalność użytkownika w danym urządzeniu i przeglądarce internetowej, jeśli on po kilku dniach odwiedzi tę samą stronę internetową. Można to zrobić bez użycia ciasteczek tylko przy pomocy cyfrowego odbicia palca. Teoretycznie istnieje również możliwość użycia takich identyfikatorów sesji (Session IDs), które są kodowane w adresie strony, którą użytkownik odwiedza. Jest to jednak z powodów bezpieczeństwa i optymalizacji dla wyszukiwarek nie zalecane.
Wezwanie do własnego serwera może trochę zakamuflować fakt, że użytkownik jest śledzony. Na przykład możliwe są następujące scenariusze z różnymi wariantami:
- Użytkownik A odwiedza stronę po raz pierwszy
- Dla użytkownika A jest pobierany palce, który jest zapisany do jego adresu IP
- Niektóre dni mijały
- Użytkownik A odwiedza stronę z tego samego przeglądarki ponownie
- Spał: Adres IP jest taki sam i może być związany z palcem
- Spał: Adres IP jest trochę inny i może być zgodny z palcem
- Spadek: Adres IP jest zupełnie inny i nie można go skojarzyć z palcem
W pierwszych dwóch przypadkach pod punktem 4 użytkownik może być ponownie rozpoznany. To jest to, co zwykle rozumie się przez obowiązkowe śledzenie. Imię dłuższa jest okres czasu, po którym możliwe jest jeszcze ponowne rozpoznanie, a aktywnie próbuje się to osiągnąć, tym bardziej istnieje obowiązek zgody. Osobista moja opinię jest taka, że 24 godziny są akceptowalnymi wartościami dla uprawnionego interesu. Wszystko, co przekracza cztery tygodnie, według mnie w każdym przypadku jest obowiązkowe. Wszystko między jednym dniem a czterema tygodniami jest do oceny w zależności od okoliczności. Cztery tygodnie słyszałem kiedyś o tym od Landesdatenschutzbeauftragten w kontekście Tracking-Cookies, ale sam uważam to za zbyt wysokie. Jako granicę dla czasu, który jest dość uzasadniony w ramach oceny ryzyka i korzyści, widzę tylko kilka dni, nawet jeśli uważam, że to prawne jest nieprawidłowe.
Pytanie jest również, które dane są wysyłane do własnego serwera, aby śledzić użytkownika. Teoretycznie wystarczy pusta prośba, ponieważ na serwerze z każdą prośbą ze względu na protokół internetowy m.in. następujące dane trafiają:
- Adres URL strony obecnej
- Czasownik
- Oznaczenie przeglądarki (Agent Użytkownika)
- Adres IP użytkownika
Dodatkowe dane, które są interesujące do rozpoznania użytkownika, mają być i muszą zostać wyraźnie wysłane z żądaniem i są w ten sposób widoczne z zewnątrz. Te dane to głównie:
- Rozdzielczość ekranu i rozmiar okna
- Ustawienia języka
- Zainstalowane rozszerzenia i czcionki
- Inne cechy, takie jak czy jest dostępny ekran dotykowy
Poniższy apel do własnego serwera śledzenia byłby bardzo widoczny:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Kodując dane śledzenia, staje się już trochę trudniej rozpoznać śledzenie. Wymieniony wyżej wywołanie mogło np. wysłać te same informacje w kodowanej postaci (przykład fikcyjny):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Dennoch można tu również prawdopodobnie wykazać zamiar śledzenia. Po pierwsze, wartość na końcu adresu URL jest auffällig długa. Wtedy już trudno sobie wyobrazić, dlaczego właśnie tak długą ciąg znaków należy przesłać do własnego serwera.
Drugi aspekt dotyczy kodowania wartości w przeglądarce użytkownika zgodnie z prawdziwymi danymi. Kodowanie to może być potem zweryfikowane. Tutaj złoczyńca może utrudnić detektorowi danych odkrycie, np. przez zamaskowanie kodu źródłowego. Oznacza to obfuskację. Jak zawsze każdy proces szyfrowania może być odwrócony, tak samo jak modyfikacja kodu źródłowego. Gdy ktoś wyjdzie na jaw z powodu tego długiego wartości i można mu udowodnić coś przeciwnego poprzez odszyfrowanie kodu źródłowego, staje się to bardzo nieprzyjemne.
Wady i zalety serwerowego śledzenia
Jakiś korzyści i wady istniejące są zależne od perspektywy. Z punktu widzenia Google otwiera się nowa możliwość, aby zastąpić praktyki danych ochrony prawnej wątpliwe przez takie same praktyki, ale trudniejsze do udowodnienia. Ponadto Google może potencjalnie uzyskać więcej danych z innych narzędzi, które teraz są połączone z serwerami Google, a nie załadowane bezpośrednio.
Zalety
Z punktu widzenia ochrony danych osobowych teraz jest możliwe, mniej danych osobowych przesyłanie do Google i innych dostawców odwiedzających strony internetowe.
Serwerowe śledzenie opiera się nie na plikach cookie, co w pierwszej kolejności wydaje się korzystne z punktu widzenia ochrony danych osobowych.
Dla administratorów stron internetowych i aplikacji teraz jest możliwe monitorowanie użytkowników przez granice urządzeń i aplikacji.
Dla Google podejście do kompensacji za utracone dane jest porównywalne z pogarszającą się sytuacją prawną.
Wady
Jest możliwe, wykorzystanie plików cookies i ukrycie śledzenia użytkowników. Tak samo można ukryć protokowanie adresów IP, ponieważ zdarzenie śledzenia odbywa się w tle. Są to wady z punktu widzenia ochrony danych osobowych.
Jeśli strona internetowa używa Google Tag Managera do serwerowego śledzenia, Google automatycznie otrzymuje te same dane od użytkownika podczas ładowania Tag Managera. Do nich należy adres IP związany z osobą. Google Tag Manager jest obowiązkowy w kwestii zgody, co mnie zdaniem czyni go niezainteresującym. Nie zmienia to faktu, że Google Consent Mode niczego nie zmienia. Podmiotom odpowiedzialnym należy się podporządkować złożoności dotyczącej ochrony danych Google i ich rozwiązaniu taggingiem. Popularna rozwiązanie jest w istocie bardziej narażone na atak niż mniej znane oferty.
Jeśli Google Tag Manager ma być używany do obsługi Google Analytics, to Google znów jest trzecim, który się śmieje. Użytkownik wciąż jest śledzony i administrator strony musi zaakceptować potencjalnie gorszą jakość danych, chyba że są używane pliki cookies lub podobne konstrukcje. Google nawet proponuje możliwość przypisania użytkownikowi identyfikacji przechowywanej w pliku cookie. W przykładzie Google tego plik cookie ma dwa lata ważności, co byłoby wymaganiem zgody. Dla większości administratorów stron i użytkowników nie jesteśmy w stanie zauważyć żadnych korzyści, ale wyższe koszty i większa zależność od Google.
Implementacja staje się trudniejsza dla administratora strony internetowej. Tylko gdy administrator osiągnie pewną wielkość lub istotność, zdaniem mnie jest to warte zrobienia, ponieważ wtedy korzyści dla administratora będą miały znaczenie, jeśli będzie mógł jednorodnie zebranie danych z większej liczby punktów końcowych (aplikacji, strony internetowej itp.).
Kwota
Wielokrotnie występujące punkty końcowe u użytkowników to ich przeglądarki. Każda z nich działa za pomocą własnej adresu sieciowej. Te punkty końcowe użytkownika są zastępowane przez jeden punkt końcowy, czyli proxy. Proxy ma tylko jedną adres sieciową.
Z tego wynika często problem z limitem. Załóżmy, że koszty usługi są ustalane na podstawie liczby połączeń. Połączenie może być liczone przez adres IP użytkownika. Nie zawsze jest tak, ale taki przypadek istnieje. Jeśli teraz jedna tylko adresem IP użytkownik wezwał usługę, to przy jednym użytkowniku szybko powstają bardzo wiele połączeń. Do tej pory było tak, że przy każdym użytkowniku i jego adresie IP powstałyby tylko kilka połączeń.
Dalej mogłoby się okazać, że blokada przy celu wywoławczym jest potrzebna, ponieważ zbyt wiele wywołań jest identyfikowanych przez proxy jako jedyny wywołujący. Także w przypadku każdego użytkownika byłoby to nieproblemowe.
Wnioski
Monitoring serwerowe jest moim zdaniem dla większości nieistotne. Będzie dla wielu funkcjonalnie nieistotne pozostawać. Przyjmuję, że Google wprowadza ten kierunek rozwoju, aby w przyszłości wyniki strat danych z powodu braku zgody użytkowników itp. kompensować.
Dowód zdarzeń wymagających zgody jest przy śledzeniu serwerowym trudniejszy niż dotychczas. Gdy używane są pliki cookie, nie zmienia się wiele w dowodzie. Pliki cookie nie mogą być ukryte. Nie ma znaczenia, czy są to tak zwane pliki cookie First Party lub Third Party Cookies, ponieważ z punktu widzenia technicznego są to zawsze dane Third Party, jeśli włączony jest Google.
Jeśli dane nie są kodowane, prawdopodobnie również łatwo udowodnić, że odbywa się śledzenie. Jeśli dane są kodowane, właściciel strony internetowej musi początkowo wykazać większe działanie. Zostanie on rzadziej ujęty, ale może być wciąż wykryty.
Skrupulatne porównywanie adresów IP z danymi śledczymi, które mogą odbywać się na własnym serwerze w tle, uważam za bardziej prawdopodobne. Jest to już dziś możliwe i być może jest wykorzystywane przez niektórych.
Poniższa tabela pokazuje w sposób bardzo ogólny, jakie dane mogą być zatajane przez śledzenie serwerowe. Yes będę poświęcił temu osobny artykuł i tu nie będę się zajmował szczegółami.
| Aspekt | Możliwa maskowanie? |
|---|---|
| Ciasteczka | Nie |
| Palcieprint | Tak, ale tylko w przybliżeniu |
| Pojedynczy Palcownik Rozszerzony | Lekko |
| Inny identyfikator użytkownika | Tak, ale tylko w przybliżeniu |
| Tracking IP-Adresse | Yes |
| Przesyłanie danych do USA | Yes |
| Porównanie adresu IP z innymi danymi | Yes |
Google próbuje uniknąć użycia plików cookies przy pomocy podejść takich jak FloC (Federated learning of Cohorts). To jest niezależne od śledzenia z serweru. Oto moje wpisy na temat Google FloC:
Patrzę na server side Tracking z pewnym spokojem. Ktoś, kto chce intensywnie wyłapywać swoich użytkowników, nie używa jedynie Google Analytics, ale wielu innych narzędzi i mechanizmów. Wymaga to znacznej pracy i również energii przestępczej. Zabieranie spraw przed sądem byłoby na pewno negatywnie ocenione.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
