I motsats till klientbaserat spårning eller märkning sker uppgifter om användare indirekt vid serverbaserad spårning. Från användarens webbläsare sänds ett spårningshändelse till en egen server och från där vidare till det egentliga målet. Därav uppstår spännande frågor kring integritetsskydd.
Inledning
Serverbaserat spårning eller server side tracking kallas ibland också för serverbaserad märkning. Detta synonymer kommer nog från att Google stödjer serveransatsen av spårningen med ett så kallat märkningsverktyg. Märkning betyder så mycket som att anrika med information. Spårning hänvisar till att följa användare, för att lära sig om deras beteende.
Serverbaserat spårning
I motsats till det står klassiskt spårning, som också kallas klientbaserat spårning. Klienten är till exempel den webbläsare som besökaren använder för att besöka en webbsida. Det kan också vara en app.
Beim Server Side Tracking skickas vanligtvis ett spåringshändelse från den egna webbplatsen till den egna servern och från där mer eller mindre oförändrat till den riktiga slutpunkten. Beim Tagging hingegen anrikas informationerna från det spåringshändelsen på den egna servern innan eventet skickas vidare till en eller flera slutpunkter.
Klient- och server-sidigt spårning
Server sida spårning har alltid varit möjlig, men har aldrig särskilt mycket uppmärksammats och har inte heller blivit populärt på grund av tidigare möjligheter. Den växande hotbilden från Sanktioner för dataspillare som Google (och alla andra som använder tredjeparts tjänster utan att reflektera) har lett till en paradigmshift.
Följande diagram visar skillnaderna mellan traditionellt och nytt tracking samt olika möjligheter. Som exempel används Google Tag Manager (GTM), som används för att ladda ned Google Analytics (GA). Detta är ett vanligt fall på webbplatser. Istället för Google Analytics laddas ofta andra verktyg från Tag Manager.
Det vanliga spårningen bygger på att ladda ner GTM och GA från ett särskilt Google-server. Denna metod kallas klientbaserad spårning.
Grön bakgrund har den dataskyddslagstiftningssmärtare server, nämligen den server som webbsidan du just besökt körs på. De gula bakgrunderna är Tredjeparts-servrar (Third-Party), här Google-servrar. Google nämns bara för att illustrera exemplet. Tänkbara servrar kan finnas hos alla möjliga leverantörer.
De röda pilarna visar Datatransfer. Laddningen av GTM kräver två Datentransfers. Den första är en begäran, så en fråga. Den andra överföringen är svaret på frågan. Vid Google Analytics är det analogt. Så kommer det till antalet fyra Datentransfers att läsa in GTM och GA. Den femte visade Datentransfären är protokollet för en användarhandling av Google Analytics.
Klientbaserat spårning är välkänt lätt att upptäcka. Då måste man bara titta på vilka servrar (adresser) en webbsida bygger upp en anslutning till. Varje person ser omedelbart att ett utrop till adressen google-analytics.com har något med Google Analytics att göra.
Nu kan man använda en så kallad Rördunge eller Proxy för att Google Analytics indirekt laddas och/eller skicka spårningshändelser till Google Analytics. Fördelen härvid är, att det slutliga spårandet kan vara likvärdigt för alla enheter och plattformar (appar, webbplatser). Tekniskt sett ser hela saken ut såhär:
Dataskyddslagstiftningssynpunkt har inte mycket hänt, eftersom tunneln som Google Analytics ansträngt sig genom befinner sig på en tredjeparts-server. Google erbjuder sådana servrar kostnadsfritt i den nuvarande Google Cloud. Nytta av Google Cloud-plattformen (GCP) borde för de flesta vara givet, eftersom implementeringen inte är helt enkel. Tag Manager laddas in på traditionellt sätt i denna variant, vilket utan samtycke faktiskt inte tillåts.
Med transport-tunneln kunde anropet från Google Analytics till en viss grad förskönkas. Man borde inte bli upptäckt. Faran för avslöjande är i alla fall ganska stor. Även Tag Manager kunde laddas över denna tunnel. I exemplet har jag inte beaktat detta. Längre ned kommer detta fall att behandlas.
Nu följer en variant till det tidigare nämnda modellen. Här är allt identiskt, men Transport-Tunneln är en egen server. I idealet har Transport-Tunneln samma adress som den webbplats som precis besökts.
Google Analytics hanteras här helt via en egen tunnel-server.
I detta modell kan det Google Analytics-scriptet hämtas från en Google-server, en server hos en annan leverantör eller en egen server. Den första varianten visas här. Från utsidan gör det ingen skillnad. Dataskyddslagstiftningsskäl skulle den första varianten vara sämre, men den andra eller tredje varianten skulle inte kunna skiljas från varandra av en utomstående och därmed inte direkt spåras.
Implementeringen av detta scenario är komplex, eftersom en egen transporttunnel måste installeras. Möjliga ändringar vid gränssnitt ska beaktas och ökar underhållskostnaderna.
Dataskyddslagen bevisar aktiviteterna i detta scenario inte lika bra som tidigare. Laddningsprocessen för det egentliga Google Analytics Scripts kan inte följas från utsidan. När skriptet överförts till webbplatsen är det åtminstone möjligt att bevisa att skriptet har laddats, men inte varifrån. Man kan också använda en egen logik för att styra Google Analytics via transportröret. Detta kräver något arbete och kräver regelbunden kontroll av funktionseffektivitet, eftersom Analytics Interface kan ändras. Så kan maximal möjlig doldhet uppnås, men den kan fortfarande delvis avslöjas.
I det sista scenariot hanteras alla datatransfer över en egen proxy-server.
På antalet datatransfer kan man redan se den höga tekniska komplexiteten i detta scenario. Alla datatransfer går via en egen server. Det är också tänkbart att det finns flera egna servrar. Om tunnel-servraren har samma domän som den webbplats man precis besökt, kommer spårningshändelser inte att synas lika snabbt som tidigare.
I detta scenario är det möjligt att försöka dölja alla datatransfer. Det kan till slut (tack vare lyckan) bara vara ett försök, eftersom varje klient-sidig doldhet kan upptäckas. Mer om detta kommer nedan.
Den följande tabellen visar ännu en gång de olika varianterna i en översikt:
| Scenario | Karaktäristik |
|---|---|
| Kundspårning | Vanligare tillvägagångssätt, lätt att implementera, lätt att upptäcka, många dataöverföringar till tredje part. |
| Serverbaserat spårning med tredjeparts-tunnell för spårning | Nyttjningsbara, icke-triviala, lätt upptäckbara, men med fler möjligheter för power-användare. |
| Serverbaserat spårning med egen tunnel för spårning | Nytt, komplext, lätt doldhet, många möjligheter för power-användare. |
| Serverbaserat spårning med egen tunnel för allt | Nytt, mycket komplext, många möjligheter till doldhet, mycket för avancerade användare. |
Inställning av en tunnel för Google Tag Manager
Google erbjuder inte helt utan syfte med Google Tag Manager nya möjligheter att hantera serverbaserat spårning. Eftersom Google Tag Manager är ett framstående exempel på denna tillvägagångssätt används ofta även begreppet serverbaserad märkning.
GTM_ används som mellanlagringsutrymme för att skicka data både till Google Analytics och andra Google-tjänster eller även till tredjeparts tjänster. Så får Google data från fler tjänster än tidigare och kan därmed kompensera för dataförluster på grund av dataskyddslagstiftning.
I konkreten ser konfigurationen av Tag Manager ut såhär:
Med detta kan GTM anvisas att Google Analytics händelser inte längre skickas till google-analytics.com, utan istället till tunneladressen analytics.example.com.
Google lovar härmed en lättnad vid spårning av användare över flera enheter.
För att en server ska kunna överföra data som den fått från den webbplats man just besökt, måste servern förberedas på ett sätt. I grunden måste en ny funktion tillhandahållas så att servern kan fungera som mellanhand mellan klient och spårningsleverantör. En Tagging Server kan drivas själv, vilket är mer dataskyddsvänligt. Alternativt kan en sådan server hämtas från en leverantör som Google i den Google Cloud, vilket redan från början väcker frågor om dataskydd.
Arbetssätt
I princip finns det två sätt att avbilda serverseitigt taggande. Tekniskt sett är dessa jämförbara, men från ett dataskyddsperspektiv uppstår andra frågor.
Den första modus är att använda en tredjeparts-server. I praktiken kan den här servern också tillhöra sig själv. Serverns adress är dock annorlunda än sin egen webbplats och pekar på en adress som antyder ett tredje parti. Som exempel nämns en av Google Cloud tillhandahöllen serverinstans, som producerar URL:er som dessa: https://sturdy-pier-xyz.ab.r.appspot.com
En sådan adress ser ut som om den är misstänkt enligt dataskyddslagen. Man kan i förväg anta att det rör sig om ett åtgärdsförfarande som kräver samtycke. Mer information måste undersökas i varje enskilt fall.
Den andra modus kallar jag Proxy-modus. En proxy är en representant som smyger igenom data. Även en tredjeserver, som fungerar som ett tunnel, är tekniskt sett en proxy-server. Men den tredjeservern är inte dataskyddslagstiftningssmässigt en riktig proxy. En proxy i detta sammanhang är enligt min definition en egen server.
Proxy-läget använder en serveradress som ligger i samma domän som den webbplats som just besökts. Om till exempel en användare besöker webbplatsen eine-webseite-081516.de så kunde adressen för taggservern vara eine-webseite-081516.de/tagging. Eftersom det ofta sker inläsningar på en webbplats till sig själv, försvinner anropet till taggings- eller spårnings-server i mängden av vanliga inläsningar.
I Proxy-läget kan krav på samtycke för inbjudningar till största delen döljas. När en sida besöks, uppmärksammas inte ett spårningsanrop mot den egna domänen i princip. Men om användaren rör sig på en redan laddad sida, t.ex genom att skrolla fönstret och hittar härvid en serveranrop, kan man redan ganska bra dra slutsatsen att det är ett spårning.
Tracking är en icke närmare bestämd term som i varje enskilt fall måste fyllas med innehåll. Vid proxy-läge handlar det huvudsakligen om två frågor:
- Finns det en tekniskt inte nödvändig anrop som inte kan motiveras med ett berättigat intresse?
- Är cookies överförda eller till och med skapade vid anropet?
Om en av de två frågorna kan besvaras med yes, finns det ett samtyckeskrav, alltså ett spårning förekommer, om man vill uttrycka sig på ett förkortat sätt.
Kakor kan inte döljas. Den som vill spåra utan kakor förlorar vissa fördelar med kakor. En av dessa fördelar är den lätta igenkännandet av en användare inom ett enhet och webbläsare, om han dagar senare återupprättar samma webbplats. Detta kan utan kakor bara uppnås med hjälp av digitala fingeravtryck. Teoretiskt finns det också möjligheten att använda så kallade sittningssignaturer (Session IDs) som kodas i adressen till den webbplats man besöker just nu. Detta är dock inte rekommenderbart av säkerhetshänsyn och för sökmotoroptimeringens skull.
En uppmaning till egen server kan delvis dölja att en användares spårning sker. Till exempel är följande scenario med sina olika varianter möjligt:
- Användaren A besöker webbplatsen första gången
- För användare A tas en fingeravtryck och sparas ihop med hans IP-adress
- Några dagar går förbi
- Användaren A besöker webbsidan igen från samma webbläsare
- Höst: IP-adressen är densamma och kan överensstämma med fingeravtrycket
- Höst: IP-adressen är lätt annorlunda och kan eventuellt överensstämma med fingeravtrycket
- Hösten: IP-adressen är helt annorlunda och kan inte överensstämma med fingeravtrycket
I de första två fallen under punkt 4 kan användaren igenkännas. Det är det som man traditionellt förstår under obligatoriskt spårning. Ju längre tid som går efter att ett igenkännande fortfarande är möjligt och aktivt försöks, desto mer ligger en obligatorisk samtycke inom ramen för ett berättigat intresse. Min personliga mening är att 24 timmar är en acceptabel värde för ett berättigat intresse. Allt som överstiger fyra veckor är i min mening alltid obligatoriskt. Allt mellan ett dygn och fyra veckor är beroende på enskilda fall att bedöma. De fyra veckorna hade jag en gång hört från en landets dataskyddsförvaltare i samband med spårningssnurror, men jag håller själv dem för alltför långa. Som gräns för en halvvägs acceptabel tid inom ramen för en risk-nytta-värdering ser jag bara några dagar, även om jag tror att detta är rättsligt felaktigt.
Frågan är också vilka data som skickas till sin egen server för att spåra en användare. Teoretiskt räcker en tom begäran, eftersom på servern landar följande data med varje begäran enligt internetprotokollet:
- Adress (URL) till den här sidan
- Tidpunkt
- Webbläsaridentifiering (User Agent)
- Användarens IP-adress
Ytterligare data som är intressant för att igenkänna användare kan och måste skickas med i kallelsen uttryckligen och är därmed synliga från utsidan. Dessa data är främst:
- Skärmupplösning och fönsterstorlek
- Språkinställningar
- Installade tillägg och skrifttyper
- Övriga egenskaper, som till exempel om en touch-skärm finns
En sådan här upprop till egen spårningsserver skulle vara mycket påfallande:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Om man krypterar spårningsdata blir det lite svårare att upptäcka ett spårningssystem. Den tidigare nämnda anropen kunde exempelvis skicka samma informationer kodad (fiktivt exempel):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Ändå kan man här också sannolikt visa att det finns en spårningsintention. Först och främst är värdet vid slutet av URL:n synnerligen lång. Därmed blir det redan svårt att komma med en ursäkt för varför just en sådan långa teckensträng ska överföras till sin egen server.
För det andra måste värdet i användarens webbläsare kodas från de verkliga datorna. Denna kodning kan också bevisas. Även här kan den onda guden göra det svårare för datainträngaren att identifiera, till exempel genom Unkenntlich maken av källkoden. Det vill säga Obfuskation. Som vanligt gäller det att varje krypteringsprocess kan ånås, så även den förändringen av källkod. Om någon talar ut sig på grund av det ovan nämnda långa värdet och kan bevisas genom avkryptering av källkoden att det är motsatt, blir det snabbt mycket pinsamt.
Fördelar och nackdelar med serverbaserat spårning
Vilka fördelar och nackdelar som finns beror på perspektivet. Från Googles synvinkel öppnas en ny möjlighet att ersätta dataskyddslagstiftningsetiska metoder med lika etiska men svårare bevisbara metoder. Dessutom får Google potentiellt mer data från andra verktyg som nu är integrerade på Googles servrar istället för att laddas direkt.
Fördelar
Från ett dataskyddsperspektiv är det nu möjligt att sända mindre personuppgifter om en webbplatsbesökare till Google och andra leverantörer.
Serverbaserat spårning baseras inte på kakor, vilket först verkar vara till fördel för dataskyddet.
För webbplatsägare och appar är ett användaruppföljning över enhets- och applikationsgränser nu möjligt.
För Google liknar tillvägagångssättet att kompensera för förlorade dataleveranser den förändrade och alltmer stränga rättsliga situationen.
Nackdelar
Det är möjligt att missbruka cookies och dölja spårning av användare. Likaså kan man protokolleringen av IP-adresser dölja, eftersom spårningshändelsen sker i bakgrunden. Detta är nackdelar ur dataskyddssynvinkel.
Om en webbplats använder Google Tag Manager för serverbaserat spårning, får Google automatiskt samma data som tidigare från användaren vid laddningen av Tag Manager. Här tillhör personbehandlade IP-adresser. Google Tag Manager är en villkor för samtycke, vilket gör honom från min synvinkel inte intressant. Även om det inte ändrar på att Google Consent Mode inte kan göra något åt detta. Ansvariga måste också underordna sig komplexiteten i dataskyddet hos Google och deras tagging-lösning. En populär lösning är principiellt mer angreppsvärd än mindre kända leverantörer.
Om Google Tag Manager ska användas för att nå Google Analytics, är Google återigen den skrattande tredje part. Användaren följs alltså fortfarande och webbplatsägaren måste acceptera en potentiellt sämre datakvalitet, om inga kakor eller liknande konstruktioner används. Även Google föreslår dock att man kan ge användaren en identifiering som lagras i ett kaks, med en livslängd på två år. Detta skulle kräva samtycke. För de flesta webbplatsägare och användare är det inget fördelaktigt, men snarare en *högre arbetsbelastning och större beroende av Google.
Implementeringen blir svårare för webbplatsägaren att genomföra i början. Endast om en webbplatsägare har uppnått en viss storlek eller relevans är det min åsikt värt implementering, eftersom då blir fördelen för webbplatsägaren relevant, att kunna samlas in data från flera slutpunkter (app, webbplats etc.) på ett enhetligt sätt.
Truppstyrka
De många enskilda slutpunkter hos användarna är deras webbläsare. Varje webbläsare arbetar över en egen nätadress. Dessa användar-slutpunkter ersätts av en enda slutpunkt, nämligen proxyservern. Proxyservern har bara en nätadress.
Utifrån det här följer ofta ett problem med kontingenter. Låt oss anta att kostnaderna för en tjänst beror på antalet anrop. Ett anrop kan räknas genom den nätverksadress som gjort anropet. Det är inte alltid så, men det finns också detta fall. Om nu bara en nätverksadress gör ett anrop, uppstår för varje enskild användare snabbt många anrop. Hittills hade vi per enskild användare och dess nätverksadress endast få anrop uppstått.
Förutom det kunde en blockering vid måluppringning inträffa, eftersom för många uppringningar från proxyen fastställdes som enda uppringare. Även detta hade inte varit ett problem om man ringt upp genom varje enskild användare.
Sammandrag
Serverbaserat spårning är enligt min mening för de flesta inte relevant. Det kommer att vara funktionellt irrelevant för många. Jag antar att Google driver fram denna ansats för att i framtiden kompensera för dataförluster på grund av saknade användarinriktningar med mera.
Beviset av åtgärder som kräver samtycke är svårare att uppnå vid serverbaserat spårning än tidigare. Om cookies används förändras beviset knappt. Cookies kan inte döljas. Det spelar ingen roll om så kallade First Party eller Third Party cookies används, eftersom det i princip handlar om third party data när Google är inbunden.
Om data inte kodas är beviset för att spårning sker troligen också relativt enkelt att upptäcka. Om data kodas har webbplatsägaren i första hand mer arbete att göra. Han kommer då sällan att upptäckas, men kan ändå avslöjas.
Det hemliga jämförande av IP-adresser med spårningsdata, som kan ske på en egen server i bakgrunden, tycks mig vara mest sannolikt. Det är också redan idag möjligt och säkert kommer det att drivas av vissa.
Den följande tabellen visar ungefär hur mycket datainsamling som kan döljas genom serverbaserat spårning. Jag kommer att ägna en egen artikel åt det och inte gå in på detaljerna här.
| Aspekt | Kan man dölja sig? |
|---|---|
| Kakor | Yes |
| Fingeravtryck | Yes, men bara på ett sätt |
| Uppskjutad Fingeravtryck | Sällan |
| Annan användaridentifierare | Yes, men bara på ett sätt |
| Tracking IP-Adresse | Yes |
| Datatransfer till USA | Yes |
| Jämför IP-adress med andra uppgifter | Yes |
Google försöker undvika cookies med tillvägagångssätt som FloC (Federated learning of Cohorts). Detta är oberoende av serverbaserat spårning. Här hittar du mina inlägg om Google FloC:
Jag ser det server side Tracking som ganska avslappnat. Vem som vill spionera intensivt på sina användare använder inte bara Google Analytics, utan många andra verktyg och mekanismer. Ansträngningen att dölja alla dessa händelser kräver en hel del möda och även kriminell energi. Att dölja bevis för brott skulle i varje fall inte få ett positivt utslag i domstol.
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.
