En contraste con el seguimiento o etiquetado desde el lado del cliente, las grabaciones de usuarios ocurren indirectamente en el seguimiento del lado del servidor. Un evento de seguimiento es enviado desde el navegador del usuario a un propio servidor y desde allí se envía al objetivo real. De ello surgen interesantes preguntas sobre la protección de datos.
Introducción
El seguimiento desde el servidor o server-side tracking se conoce ocasionalmente como tagging del lado del servidor. Este sinónimo proviene de que Google apoya la aproximación del lado del servidor del seguimiento mediante un herramienta llamada Tagging Tool. Tagging significa enriquecer con información. Por otro lado, tracking se refiere al seguimiento de usuarios para conocer su comportamiento.
¿Qué es el seguimiento desde el servidor?
En contraste con eso está el clásico rastreo, que también se denomina rastreo desde el cliente. El cliente es, por ejemplo, el navegador del visitante de una página web. También puede tratarse de una aplicación.
Al Server Side Tracking se le envía normalmente un evento de seguimiento desde la propia página web hasta el propio servidor y desde allí, más o menos sin cambios, al verdadero punto final. Al Tagging, por otro lado, se enriquecen las informaciones del evento de seguimiento en el propio servidor antes de enviarlo a uno o varios puntos finales.
Seguimiento lado del cliente y servidor
Tracking desde el lado del servidor siempre ha sido posible, pero hasta ahora no se había tratado especialmente y tampoco era popular debido a las posibilidades anteriores. La creciente amenaza de sanciones para los infractores de datos como Google (y todos aquellos que utilizan servicios de terceros sin reflexionar) ha provocado un cambio de paradigma.
Los siguientes gráficos muestran las diferencias entre el rastreo tradicional y el moderno, así como las diferentes posibilidades. Como ejemplo se utiliza el Google Tag Manager (GTM), que se utiliza para cargar Google Analytics (GA). Esto es un caso común en sitios web. En lugar de Google Analytics, a menudo también se cargan otros herramientas desde el Tag Manager.
El tracking tradicional se basa en la carga de GTM y GA cada uno desde un servidor Google especializado. Este enfoque se conoce como tracking desde el cliente.
El servidor que se encuentra detrás de la página web visitada es el que está marcado en verde, y es relativamente inofensivo desde el punto de vista del derecho a la protección de datos. Los servidores resaltados en amarillo son Servidores de terceros (Third-Party), aquí se encuentran los servidores de Google. Se menciona a Google solo como ejemplo ilustrativo, pero es posible que sean servidores de cualquier otro proveedor.
Las flechas rojas muestran los Transferencias de datos. La carga del GTM requiere dos Datentransfers. El primero es un llamado, por lo que una solicitud. El segundo transferido es la respuesta a la solicitud. En Google Analytics es análogo. Por lo tanto, se producen cuatro Datentransfers para el llamado de GTM y GA juntos. El quinto Datentransfer representado es la protocolización de una acción del usuario por parte de Google Analytics.
El seguimiento desde el lado del cliente es conocido como fácilmente verificable. Para ello basta con mirar a qué servidores (direcciones) una página web establece una conexión. Cada uno puede ver inmediatamente que un llamado a la dirección google-analytics.com tiene algo que ver con Google Analytics.
Ahora se puede utilizar un llamado Túnel o Proxy para cargar Google Analytics de manera indirecta y/o enviar eventos de seguimiento a Google Analytics. La ventaja aquí es que el seguimiento final puede ser igual para todos los dispositivos finales y plataformas (aplicaciones, sitios web). Técnicamente todo se ve así:
El derecho a la protección de datos no ha cambiado mucho, ya que el túnel sobre el que se accede a Google Analytics se encuentra en un servidor tercero. Google ofrece actualmente dichos servidores gratuitamente en la nube de Google. El beneficio de la plataforma de nubes de Google (GCP) probablemente no estará disponible para la mayoría, ya que la implementación no es muy sencilla. El administrador de etiquetas se carga inicialmente de manera convencional, lo cual, sin consentimiento, no está permitido en absoluto.
Con el túnel de transporte podría ser que la llamada a Google Analytics se desconcierte hasta cierto punto. Hay que tener cuidado para no caer en la trampa. El riesgo de descubrirlo es bastante grande. También el Tag Manager podría cargarse por este túnel. En el ejemplo, no lo he tenido en cuenta. Más abajo se considerará ese caso.
A continuación sigue una variante del modelo mencionado anteriormente. Aquí todo es idéntico, solo que el túnel de transporte es un servidor propio. Idealmente, el túnel de transporte tiene la misma dirección que la página web recién visitada.
Google Analytics se accede aquí completamente a través de un servidor de túnel propio.
En este modelo el script de Google Analytics puede ser llamado desde un servidor de Google o de otro proveedor, o desde un servidor propio. Se muestra la primera variante. Desde fuera no hay diferencia alguna. En lo que respecta a la protección de datos, la primera variante es peor, pero las dos últimas son indistinguibles para un tercero y por tanto no directamente verificables.
La implementación de este escenario es compleja, porque debe instalarse un túnel de transporte propio. Es necesario considerar posibles cambios en las interfaces y aumentan el trabajo de mantenimiento.
El registro de protección de datos de las actividades en este escenario no es tan posible como en el caso anterior. El proceso de carga del script Google Analytics real puede no ser reproducible desde fuera. Si se envía el script a la página web, al menos es posible demostrar que el script se ha cargado, pero no de dónde. Se puede utilizar también una lógica propia para acceder a través del túnel de transporte Google Analytics. Esto conlleva un cierto esfuerzo y requiere una revisión regular de la funcionalidad, ya que la interfaz de Analytics puede cambiar. De esta manera se puede lograr una máxima posible ocultación, pero que siempre puede ser descubierta en parte fundamental.
En el último escenario se tratan todos los transferencias de datos a través de un propio servidor proxy.
En la cantidad de transferencias de datos se puede apreciar ya la alta complejidad técnica de este escenario. Todos los transferidos de datos corren sobre un servidor propio. Es natural que también puedan ser varios servidores propios. Si el servidor del túnel tiene la misma dominio que la página web visitada recientemente, las trazas de seguimiento no caen tan rápido como antes.
En este escenario es posible intentar ocultar todos los transferencias de datos. Al final (afortunadamente) solo puede ser un intento, ya que cada intento de ocultación desde el lado del cliente puede descubrirse. Más abajo se dice más al respecto.
La siguiente tabla muestra nuevamente las diferentes variantes en una visión general:
| Escenario | Características |
|---|---|
| Seguimiento desde el lado del cliente | Enfoque habitual, fácilmente implementable, fácil de detectar, muchos intercambios de datos con terceros. |
| Seguimiento desde el servidor con túnel de tercera parte para seguimiento | Novedoso, no trivial, fácilmente descubrible, pero con más posibilidades para usuarios avanzados. |
| Seguimiento desde el servidor con su propio túnel para seguimiento | Novedoso, complejo, ligera ocultación, muchas posibilidades para usuarios avanzados. |
| Seguimiento desde el servidor con su propio túnel para todo | Novedoso, muy complejo, muchas posibilidades de ocultación, muchas opciones para usuarios avanzados. |
Configuración de un túnel para el Google Tag Manager
Google ofrece no del todo generosamente con el Google Tag Manager nuevas posibilidades para resolver el tracking desde el servidor. Porque el Google Tag Manager es un ejemplo prominente de este enfoque, se utiliza a menudo también el término tagging desde el servidor.
El GTM se utiliza como capa intermedia para enviar datos tanto a Google Analytics como a otros servicios de Google o incluso a servicios terceros. De esta manera, Google obtiene datos de más servicios que antes y puede compensar pérdidas de datos debido a leyes de protección de datos.
La configuración del Tag Manager es la siguiente:
Con esto se puede instruir al GTM para que Google Analytics envíe eventos no a google-analytics.com, sino a la dirección de túnel analytics.example.com.
Google promete así una mayor comodidad al seguir a los usuarios a través de varios dispositivos.
Para que un servidor pueda retransmitir los datos que recibe de la página web visitada, debe ser preparado adecuadamente. En esencia, se necesita una nueva funcionalidad para que el servidor actúe como intermediario entre el cliente y el proveedor de seguimiento. Un Tagging Server puede ser gestionado por sí mismo, lo cual es más amigable con la privacidad. Alternativamente, un servidor así puede ser obtenido de un proveedor como Google en la Google Cloud, lo que plantea desde el principio preguntas sobre privacidad.
Modos de funcionamiento
En general, existen dos formas de representar un tagging desde el servidor. Técnicamente son comparables, pero en lo que respecta a la protección de datos surgen otras preguntas.
El primer modo es el uso de un servidor tercero. En la práctica, este servidor también puede ser propiedad propia. La dirección del servidor aquí no es igual a la propia página web y apunta a una dirección que sugiere un tercer servidor. Como ejemplo se puede mencionar la instancia de servidor proporcionada por Google Cloud, que produce URLs como las siguientes: https://sturdy-pier-xyz.ab.r.appspot.com
Una dirección de este tipo parece sospechosa desde el punto de vista del protección de datos al principio. A priori se puede suponer que es un procedimiento obligatorio por consentimiento. Se debe investigar más en cada caso individual.
Llamo al segundo modo Proxy-Modo. Una proxy es un representante que filtra datos. También un tercer servidor, que actúa como túnel, es técnicamente una proxy del servidor. Sin embargo, el tercer servidor no es en realidad una verdadera proxy desde el punto de vista de la protección de datos. En este contexto, según mi definición, una proxy es un servidor propio.
El modo de proxy utiliza una dirección del servidor que se encuentra en la misma dominio como la página web visitada recientemente. Por ejemplo, si un usuario accede a la página eine-webseite-081516.de, la dirección para el servidor de etiquetado podría ser eine-webseite-081516.de/tagging. Dado que las llamadas a una página web suelen estar dirigidas a ella misma, la llamada al tagging o tracking del servidor se pierde en la multitud de llamadas inocuas.
En el modo de proxy se pueden realizar llamadas obligatorias con cierta discreción. Al llamar a una página, no se nota realmente un llamado de seguimiento a la propia dominio. Sin embargo, si el usuario se mueve en una página ya cargada, por ejemplo, desplazándose hacia abajo y encontrando aquí un servidor llamado, puede deducirse bastante bien que es un seguimiento.
Tracking es un término no definido más a fondo, que debe ser llenado con vida en cada caso particular. Al modo de proxy se reduce básicamente a dos preguntas:
- Se realiza un llamado técnico innecesario que no puede justificarse con un interés legítimo?
- Se transmiten o se crean cookies al llamar?
Si una de las dos preguntas puede ser respondida con un sí, existe una obligación de consentimiento, es decir, un seguimiento, si se quiere expresar algo abreviado.
Los cookies no se pueden ocultar. Quien quiera rastrear sin cookies, perderá ciertas ventajas de los cookies. Uno de estos beneficios es la fácil reconocimiento de un usuario dentro de un dispositivo y navegador, si él vuelve a visitar la misma página web unos días después. Esto solo puede lograrse sin cookies mediante un huella digital. Teóricamente también existe la posibilidad de utilizar identificadores de sesión (Session IDs) codificados en la dirección de la página que se está visitando actualmente. Sin embargo, esto no es recomendable por razones de seguridad y optimización para motores de búsqueda.
Un llamado a un servidor propio puede ocultar en cierta medida que se está siguiendo a un usuario. Por ejemplo, es posible lo siguiente con sus diferentes variantes:
- El usuario A accede a la página web por primera vez
- Se le toma una huella digital a un usuario A y se almacena su dirección IP
- Algunos días pasan
- El usuario A vuelve a acceder a la página web desde el mismo navegador
- Otoño: La dirección IP es igual y puede coincidir con la huella dactilar
- Otoño: La dirección IP es ligeramente diferente y puede coincidir con la huella dactilar en algunos casos
- Otoño: la dirección IP es completamente diferente y no se puede conciliar con el huella dactilar
En los primeros dos casos bajo el punto 4, el usuario puede ser reconocido nuevamente. Eso es lo que se entiende por tracking obligatorio de manera clásica. Cuanto más larga sea la duración del tiempo después de un reconocimiento aún posible y activamente intentado, más probable será una obligación de consentimiento. Mi opinión personal es que 24 horas son un valor aceptable para un interés legítimo. Todo lo que dure más de cuatro semanas es, a mi parecer, en cualquier caso obligatorio de consentimiento. Todo entre un día y cuatro semanas debe ser evaluado según el caso individual. Las cuatro semanas las había oído una vez de un defensor del estado de protección de datos en relación con cookies de seguimiento, pero considero que son demasiado altas. Como límite para una duración más o menos razonable dentro de un análisis de riesgo-nutre-veredicto veo solo unos pocos días, aunque creo que esto sería legalmente cuestionable.
La cuestión es también qué datos se envían al propio servidor para seguir a un usuario. Teóricamente basta con una solicitud vacía, porque en el servidor, con cada solicitud debido al protocolo de Internet entre otras cosas llegan los siguientes datos:
- Dirección URL de la página actual
- Momento
- Identificador del navegador (Agente de usuario)
- Dirección IP del usuario
Otros datos interesantes para reconocer a los usuarios pueden y deben enviarse explícitamente con la llamada y son por tanto reconocibles desde fuera. Estos datos son sobre todo:
- Resolución de pantalla y tamaño de ventana
- Ajustes de idioma
- Plugins y fuentes instaladas
- Otros rasgos, como si estuviera presente un touch screen
El siguiente llamado al propio servidor de seguimiento sería muy llamativo:
https://meine-webseite-471112.de/tracking?resolution=1920-1080&spras=de&plugins=plugin_tc1&fonts=arial,verdana&touch=yes
Si se codifican los datos de seguimiento, resulta más difícil reconocer un seguimiento. El llamado mencionado anteriormente podría, por ejemplo, enviar las mismas informaciones codificadas (ejemplo ficticio):
https://meine-webseite-471112.de/t?i=dhfkjjh7828763kjkHKJHJhkjjhkjbmnvghfzgjhgkjhkgjhg
A pesar de todo, aquí también se puede demostrar probablemente una intención de seguimiento. En primer lugar, el valor al final de la URL es notablemente largo. Ya es difícil imaginarse una excusa para que justamente esta cadena tan larga deba ser transferida a su propio servidor.
Zum zweiten muss el Wert im Browser des Nutzers aus den Echtdaten kodiert werden. Diese Kodierung wiederum kann nachgewiesen werden. Auch hier kann el villain dem Datenschnüffler el Erkennung erschweren, etwa durch Desconocer el código fuente. El heißt Obfuskation. Wie immer gilt, dass jeder Verschlüsselungsvorgang rückgängig gemacht werden kann, so auch el Verfremdung von Quellcode. Redet sich jemand wegen des o.g. langen Wertes raus und kann ihm about Entschlüsselung des Quellcodes etwas Gegenteiliges nachgewiesen werden, wird es schnell sehr peinlich. Traducción: En segundo lugar, el valor en el navegador del usuario debe codificarse a partir de los datos verdaderos. Esta codificación también puede ser verificada. Aquí también, el malvado puede dificultar la detección al Datenschnüffler, por ejemplo, haciendo desaparecer el código fuente. Es decir, Obfuskation. Como siempre, cada proceso de cifrado se puede revertir, así como la manipulación del código fuente. Si alguien habla sobre el citado valor largo y se le puede demostrar algo contrario mediante la descifrado del código fuente, pronto será muy incómodo.
Ventajas e inconvenientes del seguimiento desde el servidor
Existen ventajas y desventajas que dependen de la perspectiva. Desde la visión de Google se abre una nueva posibilidad para reemplazar prácticas poco claras en materia de protección de datos por otras igualmente cuestionables pero más difíciles de demostrar. Además, Google podría obtener potencialmente más datos de otros herramientas que ahora están integradas a través de los servidores de Google en lugar de ser cargadas directamente.
Ventajas
Desde el punto de vista del protección de datos, ahora es posible enviar menos datos personales sobre el visitante de una página web a Google y otros proveedores.
El seguimiento desde el servidor no se basa en cookies, lo que al principio parece favorable en cuanto a la protección de datos.
Para los propietarios de sitios web y aplicaciones, ahora es posible un seguidor del usuario a través de las fronteras de dispositivos y aplicaciones.
Para Google, el enfoque de compensación por pérdidas de datos en otro lugar se asemeja a la situación legal cada vez más estricta.
Desventajas
Es es posible, usar cookies de manera fraudulenta y un siguimiento de usuarios para ocultarlo. De igual manera se puede ocultar el registro de direcciones IP, porque el evento de seguimiento tiene lugar en segundo plano. Esto son desventajas desde la perspectiva del protección de datos.
Si una página web utiliza el Google Tag Manager para el seguimiento desde el servidor, Google obtiene automáticamente los mismos datos que antes del usuario durante la carga del Tag Manager. Esto incluye la dirección IP personalizada. El Google Tag Manager es obligatorio por consentimiento, lo cual me hace poco interesante. Ni siquiera el modo de consentimiento de Googlecambia esto. Las responsables deben someterse a la complejidad del tratamiento de datos de Google y su solución Tagging. Una popular solución es en principio más vulnerable que menos conocidos proveedores.
Si se utiliza el Google Tag Manager para interactuar con Google Analytics, Google es nuevamente la tercera persona que ríe. El usuario sigue siendo rastreado y el propietario de una página web debe aceptar una calidad potencialmente peor de los datos, a menos que se utilicen cookies o estructuras similares. Sin embargo, Google incluso sugiere la posibilidad de asignar al usuario un identificador que se almacena en un cookie. En el ejemplo de Google, el cookie tiene una vida útil de dos años. Esto sería obligatorio. Para la mayoría de los propietarios de sitios web y usuarios no hay ningún beneficio aparente, pero sí un *mayor esfuerzo y mayor dependencia de Google.
La implementación se vuelve más difícil para el propietario de una página web al principio. Sólo si un propietario ha alcanzado cierta tamaño o relevancia, me parece que vale la pena la implementación, porque entonces el beneficio para el propietario es relevante cuando puede recopilar datos de más de un punto final (aplicación, página web, etc.) de manera uniforme.
Contingente
Los numerosos puntos finales individuales en los usuarios son sus navegadores. Cada navegador trabaja a través de una propia dirección de red. Estos puntos finales de usuario se reemplazan por un solo punto final, a saber, la proxy. La proxy tiene sólo una dirección de red.
De ahí se deriva a menudo un problema con contingentes. Supongamos que los costos de un servicio se miden por la cantidad de llamadas. Una llamada puede contarse mediante la dirección de red del llamante. No siempre es así, pero este caso existe. Si una sola dirección de red llama al servicio, surgen rápidamente muchos llamados para cada uno. Hasta ahora, habrían surgido solo unas pocas llamadas por cada usuario y su dirección de red individualmente.
Una restricción en el objetivo de llamada podría surgir, porque demasiados llamamientos desde la proxy se determinan como único llamador. Esto tampoco habría sido un problema si cada usuario hubiera realizado una llamada individualmente.
Conclusión
El seguimiento desde el servidor es, a mi parecer para la mayoría no relevante. Funcionará para muchos como irrelevantemente irrelevante. Supongo que Google promueve este enfoque para compensar futuras pérdidas de datos debido a la falta de consentimiento del usuario, etc.
La prueba de procesos obligatorios es más difícil en el seguimiento desde el servidor que antes. Si se utilizan Galletas, apenas cambia la prueba. Los Galletas no pueden ser ocultados. No importa si se utilizan los llamados First Party o Third Party Cookies, ya que, desde un punto de vista técnico, siempre se trata de datos de terceros cuando se incorpora a Google.
Si los datos no se codifican, es probable que el seguimiento sea fácilmente demostrable. Si los datos están codificados, al webmaster le corresponde un mayor esfuerzo inicial. Él será menos detectado, pero todavía puede ser desenmascarado.
El comparación secreta de direcciones IP con datos de seguimiento, que puede realizarse en un servidor propio en segundo plano, es más probable a mi juicio. Esto ya es posible hoy en día y algunos lo están llevando a cabo seguramente.
La siguiente tabla muestra aproximadamente en qué medida las recopilaciones de datos pueden ser ocultadas mediante rastreo desde el servidor. Me dedicaré a un artículo propio y no entraré aquí en los detalles.
| Aspecto | ¿Es posible el velo? |
|---|---|
| Galletas | No |
| Huella dactilar | Sí, pero solo aproximadamente |
| Huella extendida | Casi |
| Identificador de usuarios distintos | Sí, pero solo aproximadamente |
| Tracking IP-Adresse | Yes |
| Transferencia de datos a los EE.UU | Yes |
| Comparación de la dirección IP con otros datos | Yes |
Google intenta evitar cookies con enfoques como FloC (Federated learning of Cohorts). Esto es independiente del rastreo desde el servidor. Aquí encontrarás mis contribuciones a Google FloC:
Veo el tracking de lado del servidor bastante relajado. Quién quiera espionar intensivamente a sus usuarios no solo utiliza Google Analytics, sino muchas otras herramientas y mecanismos. El esfuerzo por ocultar todos estos procesos requiere un gran trabajo y también energía criminal. Ocultar los hechos, en cualquier caso, no sería bien visto en la corte.
Mensajes clave
El seguimiento del lado del servidor es una forma más segura de rastrear a los usuarios porque los datos se envían a través de un servidor intermedio antes de llegar a su destino final.
Se pueden usar túneles para enviar datos a Google Analytics de forma más privada, ya que ocultan la conexión directa con Google.
Hay diferentes maneras de rastrear a los usuarios en internet, desde métodos simples hasta métodos más complejos que intentan ocultar el rastreo.
El Tag Manager de Google permite enviar datos a través de un servidor intermedio, lo que mejora la privacidad al evitar que los datos se envíen directamente a Google.
El rastreo de usuarios en internet implica recopilar información sobre sus actividades, como las páginas que visitan o los enlaces que siguen. Para hacerlo legalmente, se necesita el consentimiento del usuario, a menos que el rastreo sea necesario para un propósito legítimo y se limite en el tiempo.
El seguimiento de usuarios en sitios web puede hacerse de forma más oculta enviando datos codificados al servidor, lo que dificulta la identificación del usuario.
El seguimiento del servidor de Google puede parecer beneficioso al principio, pero en realidad presenta problemas para la privacidad.
El seguimiento del servidor es una forma de rastrear a los usuarios que es difícil de ocultar, a diferencia de las cookies.
Me llamo Klaus Meffert. Soy doctor en informática y llevo más de 30 años dedicándome profesional y prácticamente a las tecnologías de la información. También trabajo como experto en informática y protección de datos. Obtengo mis resultados analizando la tecnología y el Derecho. Esto me parece absolutamente esencial cuando se trata de protección de datos digitales.
