En opposition au suivi client ou marquage, les enregistrements des utilisateurs se font de manière indirecte lors du suivi côté serveur. Un événement de suivi est envoyé à partir du navigateur d'un utilisateur vers un serveur propre et ensuite vers la cible réelle. Cela soulève des questions intéressantes sur la protection des données.
Introduction
Le suivi côté serveur ou server side tracking est parfois également appelé suivi côté serveur. Ce synonyme vient probablement du fait que Google soutient l'approche côté serveur du suivi avec un outil appelé Tagging Tool. Tagging signifie enrichir d'informations. Le suivi désigne au contraire le suivi des utilisateurs, afin de connaître leur comportement.
Qu'est-ce que le suivi côté serveur ?
En revanche, il y a le classique tracking, qui est également appelé tracking client. Le client peut par exemple être le navigateur du visiteur d'un site web. Il peut s'agir aussi d'une application.
Au Server Side Tracking , un événement de suivi est généralement envoyé à partir de la propre page web vers son propre serveur et d'y a été transmis plus ou moins inchangé au véritable point final. Au Tagging , cependant, les informations provenant de l'événement de suivi sont enrichies sur le propre serveur avant que l'événement ne soit transmis à un ou plusieurs points finals.
Suivi côté client et côté serveur
La traçabilité côté serveur était toujours possible, mais n'a jamais été particulièrement mise en avant et n'était pas populaire en raison des possibilités antérieures. La menace croissante de sanctions pour les délinquants en matière de données comme Google (et tous ceux qui utilisent sans réflexion les services de tiers) a entraîné un changement de paradigme.
Les schémas suivants montrent les différences entre le suivi classique et le suivi innovant ainsi que les différentes possibilités. L'exemple du Google Tag Manager (GTM), qui est utilisé pour charger Google Analytics (GA) est souvent utilisé dans les cas de sites web. Au lieu de Google Analytics, d'autres outils sont souvent chargés par le Tag Manager.
Le tracking classique repose sur le chargement de GTM et GA chacun d'un serveur Google spécifique. Cette approche est appelée suivi client.
Le serveur qui est derrière la page web que vous venez de visiter, et qui est donc responsable du traitement des données collectées par cette page, n'est pas critiqué en matière de protection des données. Il s'agit d'un serveur Third-Party (Tierce partie), ici un serveur Google. Google est mentionné comme exemple pour illustrer le concept, mais il pourrait s'agir de serveurs de tous les autres fournisseurs possibles.
Les flèches rouges indiquent les transferts de données. La charge du GTM nécessite deux transferts de données. Le premier est un appel, donc une requête. Le deuxième transfert est la réponse à la requête. Pour Google Analytics, c'est analogue. Ainsi, pour le chargement de GTM et GA ensemble, il y a quatre transferts de données. Le cinquième transfert de données représenté est l'enregistrement d'une action utilisateur par Google Analytics.
Le suivi client est bien entendu facile à prouver. Il suffit de regarder vers quelles adresses un site web établit une connexion. Chacun voit immédiatement que l'appel à l'adresse google-analytics.com a quelque chose à voir avec Google Analytics.
On peut maintenant utiliser un tunnel ou un proxy pour charger Google Analytics de manière indirecte et/ou envoyer des événements de suivi à Google Analytics. L'avantage est que le suivi final peut être identique pour tous les appareils et plateformes (applications, sites web). Techniquement, c'est ainsi:
La protection des données n'a pas beaucoup changé, car le tunnel que l'on utilise pour accéder à Google Analytics se trouve sur un serveur tiers. Google offre actuellement ces serveurs gratuitement dans la Google Cloud. Le bénéfice de la plateforme Google Cloud Platform (GCP) ne sera probablement pas donné à beaucoup, car son implantation n'est pas très simple. Le Tag Manager est chargé d'abord de la manière traditionnelle, ce qui sans consentement n'est d'ailleurs plutôt pas autorisé.
Avec le tunnel de transport, l'appel à Google Analytics pourrait être masqué à un certain niveau . Il ne faut pas se faire prendre. Le risque d'être démasqué est en effet assez grand. Même Tag Manager pourrait être chargé par ce tunnel. Dans l'exemple, je n'ai pas pris cela en compte. Plus bas, on examinera ce cas.
Une variante du modèle précédent suit. Ici, tout est identique, sauf que le tunnel de transport est un serveur propre. Idéalement, le tunnel de transport a la même adresse que le site Web visité récemment.
Analytics Google est ici complètement accédé par un serveur de tunnel propre.
Dans ce modèle, le script Google Analytics peut être appelé à partir d'un serveur Google ou d'un serveur d'un autre fournisseur ou d'un serveur propre. La première variante est représentée. À l'extérieur, cela ne fait aucune différence. Juridiquement, la première variante serait moins bonne, mais la deuxième ou troisième variante serait indiscernable pour un tiers et donc non directement vérifiable.
L'implémentation de ce scénario est complexe, car un tunnel de transport doit être installé en propre. Des modifications possibles aux interfaces doivent être prises en compte et augmentent le travail d'entretien.
La preuve de l'activité en matière de protection des données dans ce scénario n'est plus aussi facile à obtenir que dans le cas précédent. Le processus de chargement du script Google Analytics proprement dit ne peut pas être suivi depuis l'extérieur. Lorsque le script est transmis à la page Web, il est toutefois possible de prouver qu'il a été chargé, mais non d'où il provient. On peut également utiliser une logique personnalisée pour accéder au tunnel de transport Google Analytics. Cela nécessite un certain effort et exige une vérification régulière de la fonctionnalité, car l'interface Analytics peut changer. Ainsi, une dissimulation maximale peut être atteinte, mais qui peut toujours être en partie révélée.
Dans le dernier scénario, tous les transferts de données sont gérés par un serveur proxy propre.
On peut déjà deviner la grande complexité technique de ce scénario en regardant le nombre de transferts de données. Tous les transferts de données passent par un serveur propre. Il est également possible qu'il y ait plusieurs serveurs propres. Si le serveur du tunnel a la même domaine que la page web visitée, les événements de suivi ne sont pas détectés aussi rapidement qu'auparavant.
Dans ce scénario, il est possible de tenter de masquer tous les transferts de données. Il s'agit finalement (heureusement) d'une tentative, car chaque masquage côté client peut être démasqué. Ensuite, on en sait plus sur le sujet.
La table suivante présente à nouveau les différentes variantes dans un aperçu:
| Scénario | Caractéristiques |
|---|---|
| Suivi client | Approche classique, facile à mettre en œuvre, facilement détectable, nombreux transferts de données vers des tiers. |
| Suivi côté serveur avec tunnel tiers pour le suivi | Nouveau, non trivial, facile à découvrir, mais plus de possibilités pour les utilisateurs avancés. |
| Suivi côté serveur avec son propre tunnel pour le suivi | Nouveau, complexe, camouflage léger, nombreuses possibilités pour les utilisateurs avancés. |
| Suivi côté serveur avec son propre tunnel pour tout | Nouveau, très complexe, de nombreuses possibilités d'évitement, très nombreuses possibilités pour les utilisateurs avancés. |
Configuration d'un tunnel pour le Google Tag Manager
Google offre des possibilités non entièrement altruistes avec le Google Tag Manager pour gérer le suivi côté serveur. Puisque l' Google Tag Manager est un exemple éminent de cette approche, on utilise souvent aussi le terme de tagging côté serveur.
Le GTM est utilisé comme couche intermédiaire pour envoyer des données à la fois vers Google Analytics et d'autres services Google ou encore des services tiers. Ainsi, Google reçoit des données de plus en provenance de plusieurs sources que par le passé et peut ainsi compenser les pertes de données dues aux lois sur la protection des données.
La configuration du Tag Manager est la suivante:
Ainsi, le GTM peut être instruit pour que les événements de Google Analytics ne soient plus envoyés à google-analytics.com, mais à l'adresse tunnel analytics.example.com.
Google promet ainsi une facilité d'identification des utilisateurs sur plusieurs appareils.
Pour que le serveur puisse transmettre les données qu'il reçoit de la page web visitée, il doit être préparé en conséquence. En substance, une nouvelle fonctionnalité doit être fournie pour que le serveur puisse agir comme intermédiaire entre le client et l'éditeur de suivi. Un serveur de Tagging peut être exploité par soi-même, ce qui est plus conforme à la protection des données. Alternativement, un tel serveur peut être obtenu auprès d'un fournisseur comme Google dans la Google Cloud, ce qui soulève dès le début des questions sur la protection des données.
Modes de fonctionnement
En général, il existe deux façons de représenter un tagging côté serveur. Techniquement, ils sont comparables, mais des questions juridiques différentes s'élèvent en matière de protection des données.
Le premier mode est l'utilisation d'un serveur tiers. En pratique, ce serveur peut même appartenir à soi-même. L'adresse du serveur n'est ici pas la même que celle de sa propre page web et pointe vers une adresse qui fait allusion à un tiers. Comme exemple, on pourrait citer l'instance de serveur fournie par Google Cloud, qui produit des URLs comme les suivantes: https://sturdy-pier-xyz.ab.r.appspot.com
Une telle adresse a l'air d'un abus de confiance au regard du droit à la protection des données. A priori, on peut supposer qu'il s'agit d'une opération qui nécessite une autorisation. Il faut examiner le cas individuel pour en savoir plus.
Le deuxième mode que je nomme Proxy-Mode. Un proxy est un représentant qui transmet des données. Même un serveur tiers, qui sert de tunnel, est techniquement un serveur proxy. Cependant, le serveur tiers n'est pas une vraie proxy en matière de protection des données. Dans ce contexte, une proxy est donc selon ma définition un serveur propre.
Le mode proxy utilise une adresse de serveur qui se trouve dans la même domaine que le site web visité récemment. Si un utilisateur par exemple appelle la page eine-webseite-081516.de , l'adresse du serveur de tagging pourrait être eine-webseite-081516.de/tagging. Puisque les appels à une page web sont souvent internes, le appel au tagging ou au suivi du serveur se fond dans la masse des appels inoffensifs.
Dans le mode proxy, des appels nécessitant une autorisation peuvent être relativement bien cachés. Lorsqu'une page est appelée, un appel de suivi sur la propre domaine ne se remarque pas vraiment au début. Cependant, si l'utilisateur bouge dans une page déjà chargée, par exemple en faisant défiler la fenêtre et en effectuant ainsi un appel serveur, il peut être relativement facile d'en déduire qu'il s'agit d'un suivi.
Tracking est un terme non défini plus précisément, qui doit être rempli d'après le cas. Lorsque le mode proxy est utilisé, il s'agit en substance de deux questions:
- Trouve-t-on un appel technique non nécessaire qui ne peut être justifié par aucun intérêt légitime ?
- Sont-ils transmis ou créés lors de l'appel à des cookies ?
Si l'une des deux questions peut être répondue par oui, il y a une obligation de consentement, c'est-à-dire quasi un suivi si on veut exprimer cela en termes raccourcis.
Les cookies ne peuvent pas être masqués. Qui souhaite suivre les utilisateurs sans cookies, perd certains avantages des cookies. L'un de ces avantages est la reconnaissance facile d'un utilisateur au sein d'un appareil et d'un navigateur, lorsqu'il relance la même page quelques jours plus tard. Cela peut être réalisé sans cookies uniquement à l'aide d'un empreinte digitale. Théoriquement, il existe également la possibilité d'utiliser des identificateurs de session (Session IDs) codés dans l'adresse de la page visitée actuellement. C'est cependant non recommandable pour des raisons de sécurité et d'optimisation pour les moteurs de recherche.
Un appel vers son propre serveur peut masquer en partie que le suivi d'un utilisateur a lieu. Par exemple, voici un scénario avec ses différentes variantes possibles:
- L'utilisateur A accède à la page Web pour la première fois
- Un empreinte digitale est prise pour l'utilisateur A, qui est associée à son adresse IP
- Quelques jours passent
- L'utilisateur A appelle à nouveau la page Web depuis le même navigateur
- Automne: L'adresse IP est la même et peut être associée à l'empreinte digitale
- Automne: L'adresse IP est légèrement différente et peut éventuellement être associée à l'empreinte digitale
- Automne: L'adresse IP est tout à fait différente et ne peut pas être associée au empreinte digitale
Dans les deux premiers cas sous point 4, l'utilisateur peut être reconnu à nouveau. C'est ce que l'on entend classiquement par suivi obligatoire. Plus la période de temps est longue pendant laquelle un reconnaissance est encore possible et active, plus il y a une obligation d'informer. Mon opinion personnelle est que 24 heures sont un bon seuil pour un intérêt légitime. Tout ce qui dépasse quatre semaines est à mon avis obligatoire dans tous les cas. Toute chose entre 1 jour et 4 semaines doit être évaluée au cas par cas. J'avais entendu parler de quatre semaines d'un Landesdatenschutzbeauftragten en relation avec les cookies de tracking, mais je considère cela comme trop long. Comme limite pour une durée raisonnable dans le cadre d'une évaluation risque-avantage, je vois que ce sont seulement quelques jours, même si je pense qu'il s'agit là d'un point juridique à redire.
La question est également de savoir quelles données sont envoyées vers son propre serveur pour suivre un utilisateur. Theoretiquement, une requête vide suffit, car sur le serveur, avec chaque requête en raison du protocole Internet notamment les données suivantes arrivent:
- L'adresse (URL) de la page actuelle
- Moment précis
- Identifiant du navigateur (Agent Utilisateur)
- Adresse IP de l'utilisateur
D'autres données, qui sont intéressantes pour reconnaître les utilisateurs, peuvent et doivent être envoyées explicitement avec l'appel et sont donc reconnaissables de l'extérieur. Ces données sont notamment:
- Résolution de l'écran et taille de la fenêtre
- Réglages de langue
- Plugins et polices installés
- Autres caractéristiques, comme la présence d'un écran tactile
L'appel suivant à son propre serveur de suivi serait très saillant:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Si on crypte les données de suivi, cela devient un peu plus difficile à reconnaître. L'appel mentionné précédemment pourrait, par exemple, envoyer ces informations codées (exemple fictif):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
Malgré tout, il est probable que l'intention de suivi puisse être démontrée ici également. Tout d'abord, le valeur à la fin de l'URL est particulièrement longue. Il est déjà difficile de se faire une excuse pour savoir pourquoi exactement cette séquence de caractères doit être transmise vers son propre serveur.
Au deuxième lieu, la valeur dans le navigateur de l'utilisateur doit être codée à partir des données authentiques. Cette codification peut également être vérifiée. Ici encore, le malhonnête individu peut rendre plus difficile la reconnaissance au détective de données en rendant inintelligible le code source. Cela signifie Obfuskation. Comme toujours, chaque processus de cryptage peut être annulé, ainsi que la modification du code source. Si quelqu'un se trahit à cause de cette valeur longue et peut être prouvé par décryptage du code source quelque chose d'opposé, cela devient très gênant rapidement.
Avantages et inconvénients du suivi côté serveur
Quels avantages et inconvénients existent-ils ? Ils dépendent de la perspective. D'un point de vue de Google, une nouvelle possibilité s'ouvre pour remplacer des pratiques à risque en matière de protection des données par d'autres qui sont tout aussi risquées mais plus difficiles à prouver. De plus, Google obtient potentiellement davantage de données provenant d'autres outils qui ont été récemment intégrés sur les serveurs Google au lieu d'être chargés directement.
Avantages
Du point de vue de la protection des données, il est maintenant possible d'envoyer moins de données personnelles sur le visiteur d'un site web à Google et autres fournisseurs.
Le suivi côté serveur s'appuie en soi sur rien de cookies, ce qui semble d'abord avantageux du point de vue de la protection des données.
Pour les propriétaires de sites web et d'applications, un suivi des utilisateurs au-delà des frontières des appareils et des applications est désormais possible.
Pour Google, l'approche d'une compensation pour les données manquantes se rapproche de la situation juridique qui s'aggrave actuellement.
Inconvénients
Il est possible de s'abuser les cookies et de faire un suivi des utilisateurs sans être détecté. De même, il est possible de cacher le protocole d'enregistrement des adresses IP, car l'événement de suivi se déroule en arrière-plan. C'est là que les inconvénients du point de vue de la protection des données.
Si une page Web utilise le Google Tag Manager pour le suivi côté serveur, Google reçoit automatiquement les mêmes données que précédemment de l'utilisateur lors du chargement du Tag Manager. Il s'agit notamment de l'adresse IP personnelle. Le Google Tag Manager est obligatoire en matière d'autorisation, ce qui le rend, à mon avis, sans intérêt. Même le mode de consentement Google ne change rien à cela. Les responsables doivent également se soumettre à la complexité du traitement des données de Google et de sa solution Tagging. Une solution populaire est en principe plus vulnérable qu'un fournisseur moins connu.
Si le Google Tag Manager est utilisé pour répondre à Google Analytics, c'est encore Google qui en profite. L'utilisateur continue donc d'être suivi et l'exploitant d'un site Web doit accepter une qualité des données potentiellement inférieure, à moins qu'il ne utilise des cookies ou des constructions similaires. Cependant, Google propose même la possibilité de donner au utilisateur une identification stockée dans un cookie. Dans l'exemple de Google, ce cookie a une durée de vie de deux ans. Cela nécessiterait une autorisation. Pour la plupart des exploitants de sites Web et d'utilisateurs, il n'y aurait aucun avantage à relever, mais plutôt un *plus grand effort et une plus grande dépendance envers Google.
L'implémentation devient plus difficile pour l'hébergeur d'un site web au début. Seulement si un hébergeur a atteint une certaine taille ou pertinence, je pense que l'implémentation est justifiée, car alors le bénéfice pour l'hébergeur devient pertinent, de pouvoir collecter uniformément des données à partir de plusieurs points d'extrémité (application, site web etc.).
Contingent
Les nombreux points d'arrêt individuels chez les utilisateurs sont leurs navigateurs. Chaque navigateur fonctionne sur une adresse réseau propre. Ces points d'arrêt des utilisateurs sont remplacés par un seul point d'arrêt, à savoir la proxy. La proxy a seule une adresse réseau.
De là résultent souvent un Problème de quotas. Supposons que les coûts d'un service soient mesurés en fonction du nombre d'appels. Un appel peut être compté à partir de l'adresse réseau du demandeur. Ce n'est pas toujours le cas, mais il existe ce type de situation. Si une seule adresse réseau appelle le service, un grand nombre d'appels se créent rapidement pour chaque utilisateur individuel et son adresse réseau respective. Jusqu'à présent, il y avait eu très peu d'appels par utilisateur individuel et son adresse réseau respective.
Une autre mesure pourrait être prise si un blocage est nécessaire à l'objectif d'appel, car trop d'appels sont identifiés comme venant de la proxy unique appelante. Même cela ne poserait pas de problème lorsqu'il s'agit d'un appel par chaque utilisateur individuel.
Conclusion
Le suivi côté serveur est, à mon avis pour la plupart non pertinent. Il restera fonctionnellement sans intérêt pour de nombreux utilisateurs. Je suppose que Google adopte cette approche afin de compenser les pertes de données dues à l'absence d'autorisation des utilisateurs et ainsi de suite.
La preuve d'opérations obligatoires est plus difficile à prouver avec le suivi côté serveur que par le passé. Lorsque des Biscuits sont utilisés, peu de choses changent quant à la preuve. Les cookies ne peuvent pas être masqués. Il n'y a là aucune différence entre les surnommés First Party ou Third Party Cookies, car il s'agit toujours de données Third Party lorsqu'on utilise Google.
Si les données ne sont pas codées, la preuve que le suivi a lieu est probablement aussi simple à établir. Si les données sont codées, l'exploitant du site web doit d'abord faire plus d'efforts. Il sera alors moins souvent démasqué, mais il peut toujours être démasqué.
L'abaissement discret des adresses IP avec les données de suivi, qui peut se dérouler sur un serveur propre en arrière-plan, me semble probable. C'est déjà possible aujourd'hui et certainement pratiqué par certains.
La table suivante donne une idée très approximative des mesures de collecte de données qui peuvent être masquées par le suivi côté serveur. Je vais consacrer un article à cela et ne pas entrer dans les détails ici.
| Aspect | Est-ce que la dissimulation est possible ? |
|---|---|
| Biscuits | Non |
| Empreinte digitale | Oui, mais seulement à peu près |
| Empreinte élargie | Peu à peu |
| Identifiant d'utilisateur autre que le sien | Oui, mais seulement à peu près |
| Tracking IP-Adresse | Yes |
| Transfert de données aux États-Unis | Yes |
| Vérification de l'adresse IP avec d'autres données | Yes |
Google tente d'éviter les cookies avec des approches comme FloC (Federated learning of Cohorts). Cela est indépendant du suivi côté serveur. Voici mes contributions à Google FloC:
- Les fondamentaux de Google FloC
- Le Google FloC est tout aussi soumis à l'autorisation que les cookies
Je vois l'tracking côté serveur comme quelque chose de relativement facile. Si quelqu'un veut espionner intensément ses utilisateurs, il ne se contente pas seulement d'Analytics Google, mais utilise également beaucoup d'autres outils et mécanismes. L'effort nécessaire pour cacher tous ces processus est considérable et nécessite même une certaine énergie criminelle. Cacher les preuves de toute façon ne serait pas jugé positivement en justice.
Messages clés
Le suivi côté serveur est une méthode plus sécurisée pour collecter des données utilisateurs car les informations sont traitées sur le serveur du site web plutôt que directement sur le navigateur de l'utilisateur.
Il existe des moyens de suivre les utilisateurs sur un site web de manière plus discrète en utilisant des tunnels ou des serveurs intermédiaires.
Il existe différentes façons de suivre les utilisateurs sur un site web, certaines plus discrètes que d'autres.
Le serveur de Tagging permet de suivre les utilisateurs de manière plus discrète et conforme à la protection des données.
Si vous voulez suivre les utilisateurs sur votre site web sans utiliser de cookies, vous devez être transparent et informer les utilisateurs.
Le suivi côté serveur permet de collecter des données sur les utilisateurs de manière plus cachée et difficile à détecter, ce qui soulève des inquiétudes quant à la protection des données.
L'utilisation du Google Tag Manager peut poser des problèmes de protection des données car il permet à Google d'accéder aux informations personnelles des utilisateurs, comme l'adresse IP, sans leur consentement explicite.
Le suivi côté serveur est une méthode de collecte de données difficile à détecter, mais qui peut être démasquée.
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.
