Im modsætning til klientbaseret sporing eller mærkning finder oplysninger om brugeren sted på server side tracking indirekte sted. Fra brugerens browser sendes et sporing-tilfælde til en egen server og fra derfra videre til det egentlige mål. Derved opstår interessante spørgsmål vedrørende privatlivets fred.
Indledning
Serverstyret Tracken eller server side tracking bliver af og til også kaldt serverstyrt Tagging. Dette synonymer kommer nok fra, at Google understøtter serverbaseret trackning med et såkaldt Tagging Tool. Tagging betyder så meget som at forsyne med informationer. Tracking henholdsvis betegner det efterfølgelse af brugere, for at lære deres adfærd til kende.
Serverbaseret sporing
Im modsætning til dette står det klassiske Tracking, der også kan kaldes clientseitiges Tracking. Den Client er f.eks. den Browser af en besøgende på en hjemmeside. Det kan også være en app.
Beim Server Side Tracking bliver normalt et tracking-event sendt fra den egne hjemmeside til den egne server og fra derfra mere eller mindre uændret til den egentlige slutpunkt. Beim Tagging hingegen bliver de oplysninger fra det tracking-event på den egne server først angemærket, inden eventet sendes videre til en eller flere slutpunkter.
Klient- og server-side tracking
Server side tracking var allerede altid muligt, men blev ikke særligt diskuteret og blev på grund af tidligere muligheder også ikke populært. Den voksende trussel fra Sanktioner for Datensvindlere som Google (og alle, der bruger tredjeparts-tjenester uden at overveje det) har ført til en Paradigmenskift.
Følgende diagrammer viser forskellene mellem traditionelt og nytteligt tracking samt de forskellige muligheder. Som eksempel bruger man Google Tag Manager (GTM), der anvendes til at laste Google Analytics (GA) op. Dette er en almindelig situation på websteder. I stedet for Google Analytics bliver ofte andre værktøjer lastet op fra Tag Manager.
Det traditionelle sporing bygger på at GTM og GA hver især lastes ned fra en særlig Google-server. Denne tilgang kaldes klient-side sporing.
Grøn baggrund er den dataskyddsretlige mere uspørgelige server, nemlig den server, hvor hjemmesiden, der netop blev besøgt, drives fra. De gule baggrunde servere er Tredjeparts-server (Third-Party), her Google-servere. Google nævnes kun som et eksempel. Det kunne være servere fra alle mulige leverandører.
De røde pilke viser Dataoverførsel an. Læsningen af GTM kræver to Datentransfers. Den første er en opkald, altså en forespørgsel. Den anden overførsel er svaret på forespørgslen. Ved Google Analytics er det analogt. Så kommer der sammen for at hente GTM og GA fire Datentransfers til. Den femte viste Datentransfer er protokolering af en brugeraktion ved Google Analytics.
Klient-side tracking er kendt leicht eftervirkende. Dertil skal man blot se, til hvilke servere (adresser) en hjemmeside opbygger en forbindelse. Hver ser straks, at en opkald til adresse google-analytics.com har noget med Google Analytics at gøre.
Nu kan man bruge en såkaldt Rørledning eller Proxy, til at Google Analytics indirekte laste og/eller sende tracking- begivenheder til Google Analytics. Fordeelen heri er, at det endelige tracking kan være ens for alle enheder og platforme (Apps, websider). Teknikken ser sådan ud:
Dataskyddsmæssigt er ikke meget sket, for tunnelen, der bliver angrebet af Google Analytics, findes på en tredjeparts-server. Google tilbyder sådanne servere gratis i Google Cloud. Nytten af Google Cloud Platform (GCP) vil være gavnlig for de fleste ikke, da implementeringen ikke er helt let. Tag Manager bliver i denne variant først ladet på den traditionelle måde, hvilket uden samtykke overhovedet ikke er tilladt nogle.
Med transport-tunnellet kunne opkaldet af Google Analytics til en vis grad skjult blive. Man skulle blot ikke komme til at blive fanget. Faren for at blive afsløret er i hvert fald ret stor. Også Tag Manager kunne lastes over denne tunnel. I eksemplet har jeg ikke taget dette med. Længere nede bliver denne situation behandlet.
Nu følger en variant til det ovennævnte model. Her er alt identisk, kun er Transport-Tunnel en egen server. Ideelt set har Transport-Tunnel samme adresse som den netop besøgte hjemmeside.
Google Analytics bliver her helt over en eget tunnel-server tilgået.
I dette model kan det Google Analytics-script hentet fra en Google-server, en server fra en anden leverandør eller en egen server. Den første variant er vist her. Udenfor gør det ikke noget forskel. Retssagelig ville den første variant være dårligere, men den anden eller tredje variant ville være umuligt at skelne fra uden for og dermed ikke direkte påviselige.
Implementeringen af dette scenario er kompleks, fordi en egen transport-tunnel skal installeres. Mulige ændringer i grænseflader skal overvejes og øger Værtsomkostninger.
Den dataskyddretlige bevisning af aktivitet i dette scenario er ikke længere så godt som tidligere mulig. Lædereprocessen for det egentlige Google Analytics Scripts kan ikke følges fra udenfor. Hvis skriptet bliver sendt til hjemmesiden, er det dog påviseligt at skriptet er blevet ladet, men ikke hvorfra. Man kan også bruge en egen logik for at styre Google Analytics via transportrøret. Det kræver lidt indsats og kræver en regelmæssig prøve af funktionsføhigkeit, da Analytics Schnittstelle kan ændres. Således kan en maksimal mulig skjulelse opnås, der dog stadig kan påvises i væsentlige dele.
I det sidste scenario bliver alle datatransfer over en egen proxy-server håndteret.
Man kan se allerede i antallet af dataoverførsler, hvor høj teknisk kompleksitet dette scenario er. Alle dataoverførsler går igennem en egen server. Det er også tænkeligt med flere egne servere. Har tunnel-serveren samme domæne som den netop besøgte hjemmeside, falder tracking- begivenheder ikke så hurtigt op som før.
I dette scenarie er det muligt at forsøge at skjule alle dataoverføringer. Det kan til sidst (til lykke) kun være en forsøg, da hver klient-side skjulte overførsel kan opdages. Der følger mere nedenfor.
Den følgende tabel viser endnu en gang de forskellige varianter i et overblik:
| Scenarie | Egenskaber |
|---|---|
| Klientbaseret sporing | Vanlig tilgangsvej, let at implementere, let at opdage, mange dataoverførsler til tredje part. |
| Server-baseret sporing med tredjeparts-tunnel for sporing | Ny, ikke trivial, let at opdage, men flere muligheder for power-brugere. |
| Server-baseret sporing med egen tunnel for sporing | Nyfødt, kompleks, let overskyglet, mange muligheder for power-bruger. |
| Server-baseret sporing med egen tunnel for alt | Nyfødt, meget kompleks, mange muligheder for at skjule sig, meget mange muligheder for power-brugere. |
Konfiguration af en tunnel til Google Tag Manager
Google tilbyder ikke helt uforpligtende med det Google Tag Manager nye muligheder for at afvikle server-side tracking. Fordi Google Tag Manager er et fremtrædende eksempel på denne tilgang, bruges ofte også betegnelsen server-side tagging.
GTM_ bruges som mellemled til at sende data både til Google Analytics og andre Google-tjenester eller også til tredjeparts-tjenester. Så får Google data fra flere tjenester end før, og kan så udgøre tab på grund af dataskydd-loven.
Konkret ser konfigurationen af Tag Manager så ud:
Med dette kan GTM blive instrueret til at Google Analytics ikke længere sender begivenheder til google-analytics.com, men i stedet til tunnel-adressen analytics.example.com.
Google lover åbenbart en letning ved at følge brugere over flere enheder.
For at en server kan overføre data, som den modtager fra den netsted, der er blevet besøgt, skal denne server være tilrettelagt på en bestemt måde. I hovedsagen skal en ny funktion tilbydes, så serveren kan fungere som en mellemmand mellem klient og tracking-leverandør. En Tagging Server kan selv drives, hvilket er mere datatilsynetvenlig. Alternativt kan en sådan server fra en leverandør som Google hentes i Google Cloud, hvilket fra starten opstår spørgsmål omkring datatilsyn.
Driftmoder
I princip findes der to former for at afbilde server-baseret tagging. Teknisk set er disse sammenlignelige, men med hensyn til dataskydd loven opstår andre spørgsmål.
Den første modus er at bruge en tredjeserver. Praktisk kan denne server også tilhøre sig selv. Server-adressen her er dog ikke den samme som sin egen hjemmeside og viser på en adresse, der pege på en anden. Som eksempel kan nævnes Google Clouds server-instans, der producerer URLs som følgende: https://sturdy-pier-xyz.ab.r.appspot.com
En sådan adresse ser ud til at være mistænkelig fra et dataskyddsperspektiv. Man kan først og fremmest antage, at der er tale om en handling, hvor samtykkekravet gælder. Det nærmere skal undersøges i det enkelte tilfælde.
Tracking er en ikke nærmere bestemt begreb, der i det enkelte tilfælde skal udfyldes med liv. Ved Proxy-modus kommer det i hovedsagen på to spørgsmål:
- Finder en teknisk ikke nødvendig opkald sted, som ikke kan gøre det med den rette interesse berettiget?
- Bliver der ved opkald af cookies overført eller endda skabt?
Hvis en af de to spørgsmål kan besvaredes yes, indebærer det en samtykningspligtighed, altså et slags tracking, hvis man ønsker at udtrykke sig på en mere forkortet måde.
Kiks kan ikke maskeres. Hvis man ønsker at spore brugeren uden kiks, taber man visse fordele ved kiksene. En af disse fordele er den lette genkendelse af en bruger indenfor et enhed og browser, hvis han dagen efter besøger samme hjemmeside igen. Dette kan uden kiks kun gennemføres med hjælp af en digital fingerabdrud. Teoretisk set findes også muligheden for at bruge såkaldte session-identifikatorer (session IDs), der er kodet i adressefeltet til den hjemmeside, man netop besøger. Dette er dog ikke anbefalelsesværdigt på grund af sikkerhed og søgeresorrelation.
En opfordring til sin egen server kan halvvejs skjule, at en bruger følges. Eksempelvis er følgende scenarie med sine forskellige varianter muligt:
- Bruger A tilkalder hjemmesiden første gang
- For bruger A bliver en fingerabtryk taget, der gemmes til hans IP-adresse
- Nogle dage går forbi
- Bruger A åbner siden igen fra samme browser
- Efteråret: IP-adressen er ens og kan sammenføjet med fingerabet
- Efteråret: IP-adressen er let anderledes og kan muligvis sammenfaldende med fingeret på
- Efteråret: IP-adressen er helt anderledes og kan ikke sammenføjes med fingerabetet
I de første to tilfælde under punkt 4 kan brugeren igenkendes. Det er det, man klassisk forstår under forpligtende samtykke til sporing. Jo længere tidsramme der er, efter hvilken et igenkendelse stadig muligt er og aktivt forsøges, desto større er sandsynligheden for, at der er tale om en forpligtende samtykke. Min egen mening er, at 24 timer er en acceptabel værdi for et berettiget interesse. Alt, hvad der ligger over fire uger, er ifølge min mening i enhver situation forpligtende til samtykke. Alt mellem én dag og fire uger skal vurderes hver for sig. De fire uger havde jeg engang hørt fra en landets dataskutzbevægelse i forbindelse med tracking-cookies, men selv finder jeg disse for lange. Som grænse for en halvvejs acceptabel periode indenfor rammerne af en risiko-nutten-abvægning ser jeg kun få dage, selv om jeg tror, at dette ville være juridisk til at kritisere.
Spørgsmålet er også, hvilke data der sendes til sin egen server for at følge en bruger op. Teoretisk er det nok en tom anmodning, fordi på serveren med hver enkelt anmodning på grund af internettets protokol bliver følgende data bragt:
- Adresse (URL) til den aktuelle side
- Tidspunkt
- Brugeragtelse (User Agent)
- Brugerens IP-adresse
Yderligere data, der er interessant for at genkende brugere igen, kan og skal med opkaldet sendes udtrykkeligt med og er således fra udenfor erkendelige. Disse data er især:
- Skærmbilledets opløsning og vindens størrelse
- Sprogindstillinger
- Indsatte plugins og skrifttyper
- Andre karakteristika, som f.eks. om en Touch Screen er til stede
En sådan opfordring til egen tracking-server ville være meget påmærkende:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Hvis man koder tracking-dataene, bliver det lidt sværere at genkende et tracking. Den ovennævnte opfordring kunne f.eks. sende samme informationer kodet (fiktiv eksempel):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Til trods her kan også her sandsynligvis en tracking-intention påvises. Først og fremmest er Værdien i slutningen af URL'en synes meget lang. Da falder det allerede svært, at finde en undskyldning til, hvorfor netop en så længere tegnekedde skal overføres til sin egen server.
Til at begynde med må værdien i brugerens browser kodificeres ud fra de ægte data. Denne kodifikation kan også bevises igen. Her kan den onde gerningsmand gøre det sværere for dataspionen at opdage, f.eks. ved at gøre kilden ukendelig. Det vil sige Obfuskation. Som altid gælder det, at hver enkelt krypteringsprocess kan omsvøres, også den af Quellcode. Hvis nogen taler sig ud på grund af ovenstående lange værdi og kan bevises ved at dechiffrere Quellcoden til noget modsatt, bliver det hurtigt meget pinligt.
Fordelene og ulemperne ved serverbaseret sporing
Hvad fordele og ulemper der er, afhænger af synsvinklen. Set fra Googles side åbner det sig en ny mulighed for at erstattere dataskyddsforskriftens tvivlsomme praksisser med lignende tvivlsomme praksisser, men som er sværere at dokumentere. Desuden får Google potentielt flere data fra andre værktøjer, der nu integreres over Googles server i stedet for at blive lastet direkte.
Fordelene
Fra et Datenschutzperspektiv er det nu muligt, færre persondata om besøgende på en hjemmeside at sende til Google og andre leverandører.
Server-baseret tracking baserer sig ikke på cookies, hvilket i første omgang synes at være gunstigt med hensyn til dataskyddet.
For udbydere af websteder og apps er det nu muligt at følge brugeren over enhed- og applikationsskridt.
For Google er tilgangen til en kompensation for tabte dataleverancer på lignende vis af den stigende juridiske situation.
Ulemper
Det er muligt at misbruge cookies og et sporings af brugere at skjule. Lige så godt kan man et logge af IP-adresser skjule, fordi sporingshændelsen finder sted i baggrunden. Dette er ulemper set fra Datenschutzens synspunkt.
Hvis en hjemmeside bruger Google Tag Manager til serverbaseret tracking, får Google automatisk samme data som før ved ladning af Tag Manager. Herunder er personbehandlet IP-adresse. Google Tag Manager er viljestemmeppligt, hvilket gør ham utilgængelig fra min side. Dette ændrer også ikke Google Consent Mode. Ansvarlige skal være underkastet dataskyddskompleksitet af Google og deres Tagging-løsning. En populær løsning er principielt angrebsbarere end mindre kendte leverandører.
Hvis Google Tag Manager skal bruges til at nå Google Analytics, er Google selv den latterlige tredje part. Brugeren bliver således stadig efterfølgende, og hjemmesiden ejer må acceptere en potentielt dårligere datakvalitet, hvis ikke cookies eller lignende konstruktioner anvendes. Dog foreslår Google selv en mulighed for at tildele brugeren en identifikation, der gemmes i et cookie. I Googles eksempel har dette cookie en levetid på to år. Dette ville være vilkårligt. For de fleste hjemmesideejere og brugere ville ingen fordel være synlig, men der ville være en *højere indsats og større afhængighed til Google.
Implementeringen bliver sværere for webstedets ejer i første omgang. Kun hvis en ejer har nået en vis størrelse eller relevans, er det værd at implementere mine meninger, da dette så ville gøre det til en fordel for ejeren at kunne indsamle data fra mehrere endpunkter (app, hjemmeside osv.) på en enhedlig måde.
Reservestyrke
De mange enkelte slutpunkter hos brugerne er deres browser. Hver browser arbejder over sin egen netværksadresse. Disse brugere-slutpunkter bliver erstattet af en enkelt slutpunkt, nemlig proxyen. Proxyen har kun én netværksadresse.
Deraf følger ofte et Problem med Kontingenter. Lad os antage, at omkostningerne for en tjeneste bestemmer sig efter antallet af opkald. Et opkald kan tælles ved hjælp af netværksadressen til den person der har gjort opkaldet. Det er ikke altid sådan, men denne situation findes også. Hvis nu en enkelt netværksadresse kalder på tjenesten, dannes der hurtigt mange opkald for hver enkelt bruger. Tidligere ville der være opstået få opkald per enkelt bruger og hans netværksadresse.
Der kunne også være en blokering ved målsted, fordi der er for mange opkald fra proxyen til at fastsætte hvem der har givet opkaldet. Det ville heller ikke være et problem hvis hver enkelt bruger selv havde givet opkaldet.
Konklusion
Serverbaseret tracking er ifølge min mening ikke relevant for de fleste. Det vil være funktionelt irrelevant for mange. Jeg gætter, at Google følger denne tilgang, for at kompensere for fremtidige tab af data på grund af manglende brugeraccept. (Note: I kept the "" untouched as per your request).
Beviset for at der er tale om en willig handling, er sværere at få frem på server siden tracking end før. Hvis Kiks bruges, ændrer det sig ikke meget ved beviset. Cookies kan ikke skjules. Det spiller her ingen rolle, om det drejer sig om såkaldte First Party eller Third Party Cookies, da fagligt handler det altid om Third Party data, hvis Google er blevet indsat.
Hvis data ikke bliver kodet, er beviset for at tracking foregår sandsynligvis også ret let muligt. Hvis data bliver kodet, har webseiten-ejer først mere besvær at gøre. Han vil så sjældent blive fanget, men kan stadig blive afsløret.
Det insgeheime Abgleichen af IP-adresser med tracking-data, der kan finde sted på en egen server i baggrunden, synes mig sandsynligere. Dette er også allerede muligt og bliver sikkert også brugt af nogle.
Den følgende tabel viser i grove træk, hvilke dataindsamlinger der kan skjules ved serverbaseret tracking. Jeg vil beskæftige mig med dette selvstændigt og ikke gå nærmere ind på detaljerne her.
| Aspekt | Kan man skjule sig? |
|---|---|
| Kiks | Nej |
| Lydtryk | Yes, men kun tilnærmelsesvis |
| Udvidet fingerabtryk | Slet ingen |
| Anden type brugeridentifikator | Yes, men kun tilnærmelsesvis |
| Tracking IP-Adresse | Yes |
| Dataoverførsel til USA | Yes |
| IP-adresse sammenligning med andre data | Yes |
Google forsøger at undgå cookies med tilgange som FloC (Federated learning of Cohorts) . Dette er uafhængigt af server-baseret tracking. Her finder du mine bidrag til Google FloC:
Jeg ser det server side Tracking meget afslappet. Hvis man ønsker at spionere intensivt på sine brugere, bruger man ikke kun Google Analytics, men mange andre værktøjer og mekanismer. Opgaven ved at skjule alle disse processer kræver en omfattende indsats og også kriminel energi. Skjulningen af beviser vil i hvert fald ikke blive positivt vurderet i retten.
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.
