In contrasto con il tracciamento o etichettatura client-side, le registrazioni degli utenti avvengono in modo indiretto nel tracciamento server-side. Da browser dell'utente viene inviato un evento di tracciamento a un proprio server e da lì verso il vero obiettivo. Ciò comporta interessanti domande sulla protezione dei dati.
Introduzione
Il tracciamento dal lato del server o server-side tracking viene occasionalmente chiamato anche con il nome di server-side tagging. Questo sinonimo deriva probabilmente dal fatto che Google supporta l'approccio del server con un cosiddetto Tagging Tool. Tagging significa così tanto quanto arricchire le informazioni. Tracking invece indica il seguimento degli utenti, per conoscere il loro comportamento.
Il tracciamento dal lato del server
In contrasto con ciò, c'è il classico tracciamento, che viene anche chiamato tracciamento client-side. Il client è ad esempio il browser del visitatore di un sito web. Può trattarsi anche di un'app.
Al Server Side Tracking si invia di solito un evento di tracciamento dalla propria pagina web al proprio server e da lì, più o meno invariato, all'endpoint reale. Al Tagging invece vengono aggiunte informazioni dall'evento di tracciamento sul proprio server prima che l'evento sia inviato a uno o più endpoint.
Raccolta di dati client e server
Il tracciamento server-side è sempre stato possibile, ma non è mai stato particolarmente tematizzato e non era popolare a causa delle possibilità precedenti. La crescente minaccia di sanzioni per i trasgressori dei dati come Google (e tutti quelli che utilizzano servizi terzi senza riflessione) ha portato a un cambiamento di paradigma.
I seguenti diagrammi a schermo mostrano le differenze tra il tracking tradizionale e quello innovativo e le diverse possibilità. Esempio è il Google Tag Manager (GTM), che viene utilizzato per caricare Google Analytics (GA). Questo è un caso molto comune nelle pagine web. Al posto di Google Analytics, vengono spesso caricati altri strumenti dal Tag Manager.
Il tracking tradizionale si basa sul caricamento di GTM e GA ciascuno da un server Google specifico. Quest'approccio viene chiamato tracking client-side.
Il server che è stato lasciato in verde è quello che riguarda la protezione dei dati, e quindi non è particolarmente critico. È il server su cui si trova la pagina web appena visitata. I server evidenziati in giallo sono Server di terze parti (Third-Party), qui Google-server. Google è stato citato solo come esempio, ma potrebbero essere qualsiasi altro fornitore.
I frecce rosse indicano i Datentransfers. Il caricamento del GTM richiede due Datentransfers. Il primo è un richiamo, quindi una richiesta. Il secondo trasferimento è la risposta alla richiesta. In Google Analytics è analogo. Quindi si verificano insieme quattro Datentransfers per il caricamento di GTM e GA. Il quinto datetransfer rappresentato è la registrazione di un'azione dell'utente da parte di Google Analytics.
Il tracciamento client-side è notoriamente facilmente verificabile. Per questo basta guardare a quali server (indirizzi) una pagina web stabilisce una connessione. Ognuno vede subito che un richiamo all'indirizzo google-analytics.com ha qualcosa a che fare con Google Analytics.
Ora si può utilizzare un cosiddetto Tunellato o Proxy, per caricare Google Analytics in modo indiretto e/o inviare eventi di tracciamento a Google Analytics. Il vantaggio è che il tracciamento finale può essere lo stesso per tutti i dispositivi e le piattaforme (applicazioni, siti web). Tecnicamente tutto si presenta così:
Il diritto alla protezione dei dati non è cambiato molto, poiché il tunnel attraverso cui si accede a Google Analytics si trova su un server terzo. Google offre tali server gratuitamente attualmente nella nuvola di Google. Il vantaggio della piattaforma Google Cloud Platform (GCP) non dovrebbe essere dato per scontato da pochi, perché l'implementazione non è facile. Il gestore delle pagine viene caricato inizialmente in modo tradizionale, il che senza consenso è non consentito.
Con il tunnel di trasporto, l'appello di Google Analytics potrebbe essere nasconduto fino a un certo punto. Bisogna solo non farsi prendere. La pericolosità dell'essere scoperti è comunque piuttosto grande. Anche il Tag Manager potrebbe essere caricato attraverso questo tunnel. Nell'esempio, non ho tenuto conto di questo caso. Più in basso verrà esaminato questo caso.
Nun segue una variante al modello appena menzionato. Ecco tutto identico, solo che il Tunnel di trasporto è un server a sé. Ideale sarebbe che il tunnel di trasporto avesse la stessa indirizzo della pagina web appena visitata.
Google Analytics viene qui completamente gestito attraverso un server tunnel proprio.
In questo modello il Google Analytics-Script può essere richiesto da un server Google o di un altro fornitore o da un proprio server. Ecco rappresentata la prima variante. Esternamente non fa differenza. Dal punto di vista della protezione dei dati, la prima variante sarebbe peggiore, ma la seconda o terza variante per un osservatore esterno non sarebbero distinguibili e quindi non direttamente verificabili.
L'implementazione di questo scenario è complessa, perché deve essere installato un proprio tunnel di trasporto. Devono essere prese in considerazione possibili modifiche alle interfacce e aumentano il Manutenzione necessaria.
Il riscontro dei dati sulla protezione della privacy delle attività in questo scenario non è più così facile come nel caso precedente. Il processo di caricamento del vero Google Analytics Scripts non può essere riprodotto dall'esterno. Se lo script viene inviato alla pagina web, comunque, è possibile dimostrare che lo script è stato caricato, ma non da dove. Si può anche utilizzare una logica propria per guidare il tunnel di trasporto Google Analytics. Ciò richiede un po' di sforzo e richiede una regolare verifica della funzionalità, perché la Analytics Schnittstelle può cambiare. In questo modo si può raggiungere una massima possibile di occultamento, ma che comunque può essere scoperto in parte significativa.
Nell'ultimo scenario tutti i trasferimenti di dati vengono gestiti tramite un proprio server proxy .
Al numero di trasferimenti dei dati si può già capire la grande complessità tecnica di questo scenario. Tutti i trasferimenti dei dati passano attraverso un proprio server. Sono naturalmente possibili anche più server propri. Se il server del tunnel ha la stessa dominio della pagina web appena visitata, gli eventi di tracciatura non si manifestano così rapidamente come prima.
In questo scenario è possibile provare a nascondere tutti i trasferimenti di dati. Potrebbe essere solo un tentativo (fortunatamente) perché ogni tipo di nascondimento da parte del client può essere scoperto. Di seguito ci sarà più informazioni in merito.
La seguente tabella mostra ancora una volta le diverse varianti in un quadro d'insieme:
| Scenario | Caratteristiche |
|---|---|
| Raccolta dei dati dal lato del cliente | Approccio tradizionale, facile da implementare, facilmente individuabile, molti trasferimenti di dati a terzi. |
| Raccolta dati dal server con tunnel di terze parti per il tracciamento | Nuovo, non banale, facile da scoprire, ma con più possibilità per gli utenti avanzati. |
| Il tracciamento dal server con proprio tunnel per il tracciamento | Nuovo, complesso, leggera copertura, molte possibilità per l'utente avanzato. |
| Raccolta dei dati dal server con proprio tunnel per tutto | Nuovo, molto complesso, molte possibilità di occultamento, molte possibilità per gli utenti avanzati. |
Configurazione di un tunnel per il Google Tag Manager
Google offre non del tutto disinteressatamente con il Google Tag Manager nuove possibilità per risolvere il problema del tracking server-side. Poiché il Google Tag Manager è un esempio prominente di questo approccio, spesso si utilizza anche il termine tagging server-side.
Il GTM viene utilizzato come strato di intermediazione per inviare dati sia a Google Analytics che ad altri servizi Google o anche a servizi terzi. In questo modo, Google ottiene dati da più servizi rispetto al passato e può quindi compensare le perdite di dati a causa delle leggi sulla protezione dei dati.
La configurazione del Tag Manager è la seguente:
Con ciò il GTM può essere istruito a far sì che Google Analytics non invii più gli eventi a google-analytics.com, ma alla Tunnel-Adresse analytics.example.com.
Google promette così una maggiore facilità nel tracciare gli utenti attraverso più dispositivi.
Perché un server possa trasmettere i dati che riceve dalla pagina web appena visitata, deve essere preparato in modo appropriato. In sostanza, è necessario fornire una nuova funzionalità per far sì che il server funga da intermediario tra il client e l'azienda di tracciamento. Un Tagging Server può essere gestito autonomamente, il che è più rispettoso della privacy. Alternativamente, un tale server può essere acquistato da un fornitore come Google nella Google Cloud, il che solleva fin dall'inizio problemi relativi alla protezione dei dati.
Modalità di funzionamento
In generale ci sono due tipi di etichettatura da server a rappresentare. Tecnicamente sono paragonabili, ma dal punto di vista del diritto sulla protezione dei dati si pongono altre domande.
Il primo modo è l'utilizzo di un server terzo. In pratica, questo server può anche appartenere a sé stesso. L'indirizzo del server è qui diverso dall'indirizzo della propria web site e punta su un indirizzo che fa pensare a un terzo. Esempio di ciò è la server istanza fornita da Google Cloud che produce URL come le seguenti: https://sturdy-pier-xyz.ab.r.appspot.com
Una tale indirizzo sembra sospetto dal punto di vista della protezione dei dati. A priori si può presumere che sia un procedimento obbligatorio per l'assenso. Dettagli sono da esaminare nel caso specifico.
Il secondo modo lo chiamerò Modalità di proxy. Un proxy è un rappresentante che trasmette i dati. Anche un terzo server, che funge da tunnel, è tecnicamente un server di proxy. Tuttavia, il terzo server non è in questo contesto una vera e propria proxy dal punto di vista dei diritti sulla protezione dei dati. In questo contesto quindi, secondo la mia definizione, un proxy è un proprio server.
Il modulo del proxy utilizza un indirizzo di server che si trova nella stessa domanda della pagina web appena visitata. Ad esempio, se un utente visita la pagina una-webseite-081516.de , l'indirizzo per il server di tagging potrebbe essere una-webseite-081516.de/tagging. Poiché spesso una pagina web riceve richieste da parte di se stessa, il richiamo al tagging o tracking del server scompare nella massa delle richieste innocue.
Nel proxy-mode possono essere nascosti abbastanza bene richiami obbligatori di consenso. Quando viene chiamata una pagina, un richiamo di tracciatura sulla propria dominio non si nota veramente. Tuttavia, se l'utente si sposta su una pagina già caricata, ad esempio scorrere la finestra e facendo un server-richiamo, può essere abbastanza facile dedurre che ci sia un tracciamento.
Il tracking è un concetto non meglio definito che deve essere riempito di senso in base al contesto. Nel modo proxy si riduce sostanzialmente a due domande:
- Si verifica un invito tecnico non necessario che non può essere giustificato con un interesse legittimo?
- Vengono trasferiti o addirittura creati cookie al chiamare?
Se una delle due domande può essere risposto con sì, ciò comporta un obbligo di consenso, ovvero quasi un tracciamento, se si vuole esprimere la cosa in modo abbreviato.
I cookie non si possono nascondere. Chi vuole tracciare senza utilizzare i cookie, perde certi vantaggi dei cookie. Uno di questi vantaggi è la facile riconoscibilità di un utente all'interno di un dispositivo e browser, se torna sulla stessa pagina dopo alcuni giorni. Ciò può essere fatto senza cookie solo con l'aiuto di un impronta digitale. Teoricamente esiste anche la possibilità di utilizzare identificatori di sessione (Session IDs) codificati nell'indirizzo della pagina attualmente visitata. Questo però non è consigliabile per motivi di sicurezza e ottimizzazione per motori di ricerca.
Un invito al proprio server può nascondere in parte il fatto che un utente venga seguito. Ad esempio, è possibile questo scenario con le sue diverse varianti:
- L'utente A richiama per la prima volta il sito web
- Per l'utente A viene tratto un impronta digitale che viene registrata alla sua indirizzo IP
- Passano alcuni giorni
- L'utente A richiama nuovamente il sito web dallo stesso browser
- Autunno: l'indirizzo IP è uguale e può essere collegato al dito unico
- Autunno: l'indirizzo IP è leggermente diverso e può essere collegato al dito unico
- Autunno: l'indirizzo IP è tutto diverso e non può essere conciliato con la impronta digitale
Nel primo e nel secondo caso sotto punto 4 il utente può essere riconosciuto nuovamente. È questo ciò che si intende per tracking obbligatorio in senso classico. Quanto più lunga è la durata di tempo dopo cui un riconoscimento ancora possibile e attivo viene cercato, tanto più probabile è l'obbligo di consenso. La mia opinione personale è che i 24 ore siano un valore accettabile per un interesse legittimo. Tutto ciò che supera le quattro settimane è, secondo la mia opinione, in ogni caso obbligatorio. Tra un giorno e quattro settimane tutto dipende dal caso specifico. Le quattro settimane avevo sentito parlare di un difensore della protezione dei dati del paese in relazione ai cookie di tracciamento, ma ritengo che sia troppo alta. Come limite per una durata accettabile nel quadro di una valutazione rischio-necessità vedo solo pochi giorni, anche se credo che ciò sarebbe da criticare legalmente.
La domanda è anche quale tipo di dati vengono inviati al proprio server per tracciare un utente. Teoricamente basta una richiesta vuota, perché con ogni richiesta sul server, a causa del protocollo Internet, tra l'altro, arrivano i seguenti dati:
- Indirizzo (URL) della pagina attuale
- Momento
- Identificativo del browser (User Agent)
- Indirizzo IP dell'utente
Ulteriori dati interessanti per riconoscere gli utenti possono e devono essere inviati esplicitamente con l'appello e sono quindi riconoscibili dall'esterno. Questi dati sono soprattutto:
- Risoluzione dello schermo e dimensione della finestra
- Impostazioni della lingua
- Plugins e caratteri installati
- Altre caratteristiche, ad esempio se è presente un touch screen
Il seguente appello per il proprio server di tracciamento sarebbe molto evidente:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Codificando i dati di tracciamento, diventa un po' più difficile riconoscere il tracciamento. L'appello appena citato potrebbe, ad esempio, inviare le stesse informazioni codificate (esempio fittizio):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Tuttavia può anche essere dimostrata una intenzione di tracciamento qui. Innanzitutto il valore alla fine dell'URL è sorprendentemente lungo. E già si fa fatica a immaginare un motivo per cui debba essere inviato proprio questo tipo di sequenza di caratteri al proprio server.
In secondo luogo, il valore nel browser dell'utente deve essere codificato a partire dai dati autentici. Questa codifica può poi essere verificata. Anche in questo caso, il cattivo soggetto può rendere più difficile all'investigatore di riconoscimento, ad esempio rendendo illeggibile il codice sorgente. Ciò significa Obfuskation. Come sempre vale la pena che ogni processo di crittografia può essere annullato, così come l'alterazione del codice sorgente. Se qualcuno si dichiara per via del valore sopra citato troppo lungo e può essere dimostrato tramite decrittazione del codice sorgente qualcosa di contrario, diventa molto imbarazzante.
Vantaggi e svantaggi del tracciamento dal lato del server
Quali sono i vantaggi e gli svantaggi, dipendono dalla prospettiva. Da parte di Google si apre una nuova possibilità per sostituire pratiche datenschutzfragili con altre altrettanto fragili ma più difficili da dimostrare. Inoltre, Google potrebbe ottenere dati potenzialmente maggiori da altri strumenti che ora sono integrati sui server di Google anziché essere caricati direttamente.
Benefici
Dal punto di vista della protezione dei dati personali è ora possibile inviare a Google e altri fornitori meno dati personali relativi al visitatore di un sito web.
Il tracciamento dal lato del server non si basa sui cookie, il che sembra inizialmente vantaggioso per la protezione dei dati.
Per i proprietari di siti web e app, è ora possibile un rilevamento degli utenti oltre le barriere di dispositivo e applicazione.
Per Google, l'approccio di compensazione dei dati mancanti in un'altra sede è equiparato alla legge sempre più severa attuale.
Svantaggi
È possibile usare i cookie in modo scorretto e un tracciamento degli utenti nascondere. Allo stesso modo, è possibile nascondere la registrazione delle indirizzi IP, perché l'evento di tracciamento si svolge in background. Questi sono svantaggi dal punto di vista della protezione dei dati.
Se una pagina web utilizza il Google Tag Manager per il tracciamento server-side, Google ottiene automaticamente le stesse informazioni del visitatore durante l'accesso al Tag Manager. Ciò include l'indirizzo IP personale. Il Google Tag Manager è obbligatorio per la conformità, il che lo rende inutile ai miei occhi. Anche il modo di consenso Google non cambia nulla. Le autorità competenti devono sottoporsi alla complessità del trattamento dei dati di Google e della loro soluzione Tagging. Una popolare soluzione è in principio più vulnerabile rispetto a fornitori meno noti.
Se il Google Tag Manager viene utilizzato per interagire con Google Analytics, è sempre Google a trarre vantaggio. L'utente continua quindi ad essere monitorato e l'amministratore di un sito web deve accettare una potenziale qualità dei dati peggiorata, a meno che non vengano utilizzati cookie o costrutti simili. Tuttavia, Google suggerisce anche la possibilità di assegnare all'utente un identificativo memorizzato in un cookie. Nel loro esempio, il cookie ha una durata di due anni. Ciò richiederebbe l'autorizzazione dell'utente. Per la maggior parte degli amministratori di siti web e utenti non ci sarebbe alcun vantaggio evidente, ma solo un *maggiore sforzo e una maggiore dipendenza da Google.
La implementazione diventa più difficile per il gestore di un sito web. Solo se un gestore raggiunge una certa dimensione o rilevanza, a mio avviso, si giustifica l'implementazione, perché allora il beneficio per il gestore diventa rilevante, ovvero poter raccogliere dati da più punti di fine (app, sito web ecc.) in modo unico.
Contingente
I numerosi punti di fine per gli utenti sono i loro browser. Ogni browser opera attraverso un'indirizzo di rete proprio. Questi punti di fine degli utenti vengono sostituiti da un singolo punto finale, cioè la proxy. La proxy ha solo un indirizzo di rete.
Dalla cosa in questione si origina spesso un problema con i limiti. Supponiamo che i costi per un servizio siano determinati dal numero di chiamate. Una chiamata può essere contata attraverso l'indirizzo di rete del chiamante. Non è sempre così, ma esiste questo caso. Se ora una sola indirizzo di rete chiama il servizio, si verificano rapidamente molti chiamate per un singolo utente. Fino adesso erano sorte solo poche chiamate per ogni singolo utente e la sua rete.
Un blocco potrebbe essere necessario al momento dell'invio, perché troppi invii vengono rilevati dalla proxy come unico mittente. Anche questo non sarebbe stato problematico per l'invio da parte di ogni singolo utente.
Conclusione
Il tracciamento dal lato del server è, secondo la mia opinione, per la maggior parte non rilevante. Rimarrà funzionalmente irrilevante per molti. Sospetto, Google sta promuovendo questo approccio per compensare le perdite di dati future a causa della mancanza di autorizzazioni degli utenti ecc.
La dimostrazione di attività che richiedono il consenso è più difficile con il tracciamento server-side rispetto al passato. Se vengono utilizzati Biscotti, poco cambia nella dimostrazione. I Biscotti non possono essere nascosti. Non fa differenza se si usano i cosiddetti First Party o Third Party Cookies, poiché in termini tecnici si tratta sempre di dati Third Party quando viene inserita Google.
Se i dati non sono codificati, è probabile che il riscontro del tracciamento sia anche relativamente semplice. Se i dati sono codificati, l'editore della pagina web dovrà sostenere un maggior impegno iniziale. Egli sarà quindi meno probabile di essere scoperto, ma può sempre essere smascherato.
Il riconoscimento segreto di indirizzi IP con dati di tracciamento, che può avvenire su un proprio server in background, è secondo la mia opinione più probabile. Ciò è già possibile oggi e viene probabilmente anche eseguito da alcuni.
La seguente tabella mostra approssimativamente quali rilevazioni di dati possono essere oscurate da un tracciamento server-side in quale misura. Io dedicherò un articolo specifico a questo argomento e non ci soffermerò qui sulle sfumature.
| Aspetto | Ritocco possibile? |
|---|---|
| Biscotti | No |
| Impressione digitale | Sì, ma solo approssimativamente |
| Impressione allargata | Appena |
| Altri identificatori di utenti | Sì, ma solo approssimativamente |
| Tracking IP-Adresse | Yes |
| Trasferimento di dati negli Stati Uniti | Yes |
| Confronto dell'indirizzo IP con altre informazioni | Yes |
Google cerca di evitare i cookie con approcci come FloC (Federated learning of Cohorts). Ciò è indipendente dal tracciamento server-side. Ecco alcuni miei contributi su Google FloC:
Vedo il server side Tracking piuttosto rilassato. Chi vuole spiare intensamente i propri utenti non utilizza solo Google Analytics, ma molti altri strumenti e meccanismi. Lo sforzo per nascondere tutti questi procedimenti richiede un notevole impegno e anche energia criminale. Nascondere comunque le prove in questo caso sarebbe sicuramente negativamente valutato in tribunale.
Messaggi chiave
Il tracciamento server-side è un modo più sicuro per raccogliere dati degli utenti rispetto al tracciamento client-side perché i dati vengono inviati a un server intermedio prima di arrivare a Google o ad altri fornitori di servizi terzi.
Esistono diversi modi per tracciare le attività degli utenti in modo più privato, usando tunnel o proxy per nascondere le richieste a Google Analytics.
Esistono diverse tecniche per tracciare gli utenti online, alcune più complesse e difficili da individuare rispetto ad altre.
È possibile tracciare gli utenti in modo più privato usando un proprio server per gestire i dati di Google Analytics, invece di affidarsi direttamente a Google.
Per tracciare gli utenti senza usare i cookie, si possono usare altri metodi, ma sono meno efficaci e spesso meno sicuri.
Il tracciamento server-side di Google permette di raccogliere dati degli utenti in modo più nascosto e difficile da rilevare, ma non garantisce una reale protezione della privacy.
Il tracciamento server-side di Google è poco utile per la maggior parte degli utenti e dei siti web.
Il tracciamento server-side è il modo più efficace per monitorare gli utenti online, anche se si cerca di nascondere le proprie tracce.
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.
