Por Alex Masip, Head of Data en Labelium
Dentro de los cambios que los principales navegadores como Safari y Firefox están realizando en la gestión de cookies de tercera parte, Chrome tiene también previsto cambios importantes en su versión 80, prevista para febrero del 2020.
En este post se explican el contexto, los cambios que realiza Chrome y qué implicaciones tienen dichos cambios. Veremos también cómo testear si nuestro site está preparado para gestionarlos correctamente.
Cookies de primera y de tercera parte
En general entendemos como datos de primera parte aquellos datos que nos pertenecen directamente, sin intervención de terceros. En el contexto de las cookies son cookies de primera parte aquellas que se gestionan directamente desde el dominio principal del site. Es decir, todas las cookies en las que el dominio principal sea el mismo que el site en el que nos encontramos.
Por contra las cookies de tercera parte son aquellas que pertenecen a otros dominios principales del site al que nos encontramos.
Las cookies de tercera parte tienen utilidad para mantener una coherencia global en la navegación del usuario. Por ejemplo, si ponemos un video de Youtube en nuestro site el hecho de que el usuario esté logueado en Youtube, haya visto el vídeo anteriormente o lo haya marcado para ver más tarde, se gestiona con una cookie de tercera parte. Sin esta cookie el usuario deberá salir de nuestro site e ir a Youtube a loguearse de nuevo.
El problema es que hay muchos usos no tan benignos de este tipo de cookies. El más conocido es su uso para trackear al usuario por toda su navegación a efectos de profiling y publicidad online. Pero hay también potenciales abusos de seguridad mucho más graves.
La gestión de las cookies de tercera parte en los principales navegadores
Los cambios legislativos como el GDPR y la sensibilización del gran público sobre la gestión de la privacidad online han provocado grandes cambios en cómo los principales navegadores como Safari o Firefox gestionan estas cookies de tercera parte.
Safari inició esta cruzada contra el tracking online en el 2017 con su ITP (Intelligent Tracking Prevention) que prevenía ya el uso de cookies de tercera parte. El ITP ha ido evolucionando y nos encontramos ya en el 2.3, con el que Apple se protege también contra cierto uso de cookies de primera parte y el uso de otras tácticas como local storage.
Firefox ha optado por una táctica similar, pero menos agresiva. En lugar de bloquear todas las cookies por defecto utiliza un método de blacklisting. Comprueba si la cookie pertenece a un dominio identificado en la lista de dominios que ejecutan publicidad y tracking (lista de disconnect.me)
Chrome hasta ahora ha optado por tácticas mucho menos agresivas. No bloquea cookies de primera ni tercera parte por defecto, aunque sí ofrece esa opción a sus usuarios a través de su gestión de privacidad.
El gran cambio que viene en la versión 80 de Chrome es que los cambios están activos por defecto, sin que el usuario deba activarlos explícitamente.
Gestión de cookies en Chrome 80
Chrome, a partir de su versión 80, va a empezar a forzar la utilización segura del atributo SameSite para aplicaciones de tercera parte.
El atributo SameSite no es nuevo, pero no se estaba utilizando hasta ahora con regularidad. El atributo SameSite ofrece tres opciones de valor:
SameSite=Strict.- Uso puramente de primera parte SameSite=Lax.- Punto intermedio que permite ciertos usos en contexto de tercera parte. Se permite el uso de la cookie en dominios externos cuando provienen de un enlace directo, por ejemplo para mantener a un usuario logueado. Pero no permite el uso de la cookie por otros métodos como POST SameSite=None.- Uso de tercera parte standard.
La gran diferencia en esta actualización de Chrome es que se fuerza a declarar el SameSite=None como seguro. Es decir, se rechazará lo siguiente:
Set-Cookie: promo=abc123; SameSite=None
Y deberá utilizarse lo siguiente:
Set-Cookie: promo=abc123; SameSite=None; Secure
En el primer caso Chrome rechazará la cookie y si no se declara SameSite gestionará la cookie como si fuera SameSite=Lax, con lo cual bloqueará su uso en tercera parte.
Cómo me afecta este cambio
No es necesario preocuparse por la gestión de las cookies de Google, pero si tenemos funcionalidades cross-site con otras cookies es importante asegurarse que cumplen con el standard. De lo contrario nos encontraremos con funcionalidades que dejarán de estar operativas.
Dificultades importantes a tener en cuenta:
- No todos los lenguajes y librerías permiten el valor None a día de hoy. En estos casos deberá declararse directamente en el cookie header. Para más información podéis consultar el siguiente repositorio Github.
- Algunos navegadores antiguos son incapaces de gestionar el atributo None adecuadamente. Lista de navegadores incompatibles
Cómo testear el efecto en mi site
Es muy recomendable comprobar lo antes posible si este cambio va a tener un efecto importante en nuestras propiedades online.
Para testear en versiones de Chrome 76+:
- Ir a chrome://flags y activar #same-site-by-default-cookies y #cookies-without-same-site-must-be-secure. Reiniciar el navegador.
- Iniciar los tests. Especialmente importante comprobar todo lo relativo a flujos de navegación que deban mantener un login, cambios entre dominios y contenido cross-site. Importante también tener en cuenta que por la limitación de 2 minutos de “Lax+POST” es recomendable testear cualquier flujo que conlleve POST con retrasos de menos y más de dos minutos.
- Si el site deja de funcionar cómo debe:
- a. Empezar por desactivar #cookies-without-same-site-must-be-secure. Si esto soluciona el problema es que tenemos cookies con el valor SameSite=None que no son seguras
- b. Desactivar ambas flags. Si esto soluciona el problema es necesario identificar las cookies a las que se accede cross-site y aplicarles los atributos SameSite y Secure.
