Trazabilidad del usuario en internet (I): ¿A qué estamos expuestos?

Todo lo que hacemos en internet deja un rastro. Unas píldoras de información que bien usadas, permiten trascender acciones a lo largo del tiempo y del espacio, y mal usadas, permiten espiar comunicaciones y rastrear usuarios.

SuperCookie Monster

Sobre este tema hemos hablado largo y tendido estos últimos años. Pero los tiempos cambian, y las técnicas, como veíamos con el canvas fingerprinting, evolucionan a un ritmo alarmante (sí, alarmante). Por ello, me ha parecido interesante dedicar dos artículos a la evolución del concepto privacidad/identidad en el mundo digital, a las herramientas y estrategias utilizadas actualmente (que ya adelanto que van mucho más allá de las cookies de toda la vida) para rastrear al usuario, y cómo no, qué podemos hacer como usuarios para protegernos del lado negativo de todo esto, sabiendo lo qué sacrificamos en el camino. Empecemos.

Internet como el basto océano gobernado por un reducido número de compañías

Comienzo por el final, echando mierda sobre la filosofía que defendemos desde esta santa casa.

Seguramente si usted es un lector habitual del blog, como un servidor, se alegra de que con filtraciones mediáticas de la talla de Snowden o Wikileaks, hayamos perfilado un panorama en el que las conexiones seguras se anteponen como features a considerar para el éxito de un negocio.

A grandes rasgos, esto es bueno. Sistemas más seguros > comunicaciones más seguras > más privacidad para el usuario.

Pero tiene un lado oscuro. Y es que todo este ecosistema del anonimato frisa de frente con el sistema económico que sustenta buena parte del tercer entorno: la publicidad. Una publicidad basada en la hipersegmentación y el conocimiento adquirido a partir de los datos “suministrados” por el usuario. Unos datos, precisamente, que a cada paso se encuentran más protegidos bajo protocolos de cifrado.

¿Qué conlleva este cambio de paradigma? Que los traders de información, las plataformas publicitarias, tengan que reinventarse en un mercado que a cada paso se vuelve más hostil a su negocio, y que previsiblemente, hará caer a buena parte del mercado.

Menos competencia, a fin de cuentas, y más corralito para los grandes (Facebook, Google, Amazon,..) que son forzados (positivamente para ellos, negativamente para el resto) a levantar murallas más gruesas dentro de sus ecosistemas, no permitiendo la interoperatibilidad entre diferentes plataformas. Es decir, que a este paso, Google será el único que pueda monetizar las búsquedas en internet. Facebook será el único que gestione el mundo social, y Amazon el único que monetice el funnel de compra (Google, Facebook, Amazon, Yahoo!, AOL, o la empresa que de turno que en ese momento gestione los volúmenes masivos de usuarios).

Proveedores de servicios que pasan a ser proveedores de publicidad, y viceversa. Jardines vallados de explotación de datos, que dejan un margen casi nulo para la libre competencia de la red.

¿Cómo nos monitorizan en internet?

A grosso modo, el funcionamiento es el siguiente. Cuando nosotros establecemos comunicación con un servicio web, hacemos llamada a varios sub-servicios con los que este está formado. En esa comunicación, entregamos unas cabeceras con información de nuestro estado (navegador, sistema operativo,…), más otras características propias de la comunicación (protocolo utilizado, puertos de entrada y salida, hora,…). También es posible que compartamos información propia de nuestro navegador, como es la versión y los plugins instalados. Todo con el objetivo de mejorar y adaptar el contenido del servicio a nuestro cliente.

Además, nuestro navegador es capaz de guardar una copia de la información y los datos que compartimos para agilizar la comunicación en sucesivas conexiones (por ejemplo al cambiar de página o volver el día siguiente). Históricamente, esto se realizaba mediante el uso de cookies, ficheros de información guardados en local a los que el servidor accedía para saber quien era cada cliente, y por ejemplo rellenarle nuevamente el carrito con los últimos productos seleccionados en una tienda virtual, o mostrarte el feed de estados en una red social.

El problema viene cuando se utilizan esta y otras herramientas para traficar con los datos, y crear perfiles de usuario que pueden ser rastreados en diferentes webs. Es decir, si yo tengo una plataforma (por ejemplo de publicidad), mediante el uso de las cookies y la información de cabecera enviada por el usuario, y el historial de conexiones de mis clientes, puedo establecer con una certeza muy alta que este usuario es uno que también accedió a estas otras páginas de mi plataforma, y por tanto, conocer sus hábitos y costumbres.

Las cookies entonces pasan a un segundo plano, ya que no se comparten entre dispositivos y dependen del cliente (que puede haberlas borrado queriendo), por lo que hecha la ley, hecha la trampa.

EverCookies (EN) es una de estas nuevas estrategias, basadas en utilizar ya no solo las cookies (que como ya dijimos se guardan en una carpeta fácilmente localizable y eliminable desde la interfaz de cada navegador), sino features de HTML5 como el localstorage o plugins como Adobe Flash para guardar ficheros de información que permitan en conexiones siguientes identificar al usuario, e incluso reescribir las cookies si son borradas. Por supuesto, también pueden borrarse, pero ya no es algo tan sencillo de realizar, y en la práctica (para el grueso de la sociedad) hace que la caducidad de una cookie se alargue hasta considerarse permanente en el sistema.

Ahora, y con la prueba de concepto de Sam Greenhalgh (EN) del que hablaba en el artículo de ayer del CIGTR, nos enteramos de que una plataforma de este calibre es capaz de aprovecharse de una vulnerabilidad presente en la mayoría de navegadores usados masivamente (Chrome, Firefox y Safari principalmente. IE se libra al no tener soporte para esta tecnología) para guardar identificadores únicos bajo el amparo de conexiones HSTS (forzado de HTTPs). Si EverCookie peca de que no funcionar bajo conexiones privadas o en modo incógnito, SuperCookie (sí, no es que se hayan currado mucho el nombre) lo soluciona incluyendo en la comunicación inicial una serie de flags HTTPs en los que va incluido el identificador. Puesto que esta conexión es obligatoria para realizar conexiones HTTPs forzadas (una recomendación de seguridad, de hecho), presenta un grave problema de seguridad y privacidad, y un quebradero de cabeza para los desarrolladores de navegadores (hablamos de una tergiversación del servicio que requeriría repensar cómo gestionar conexiones seguras que no permitan enviar mensajes permanentes que puedan servir de identificador de usuario).

Y esto en sí mismo entra en conflicto con la seguridad de los protocolos de internet, puesto que bien usado, permite descubrir suplantaciones de identidad (casos de Doxing) y, como no, mejorar la experiencia de usuario en la red, evitando campañas de phishing o fake web. Eso sí, a cambio de privacidad.

 

En el siguiente artículo, hablaremos de algunos casos reales de abuso de datos recopilados por conexiones, y qué herramientas tenemos como usuarios para combatirlos. Todo dependiendo del nivel de anonimato al que estamos dispuestos a implantar.