¡Cookiegeddon! Bye a las cookies de terceros y cómo afectará a tu software

¡Cookiegeddon!
Adiós a las cookies de terceros y cómo afectará a tu software
Francisco Javier Barrena

● Now: Principal Engineer at Labster Inc.
● Former CTO of Kyso (now open source)
● Former Head of Engineering and Head of Cybersecurity Research Group
at ITI
● Former Professor at Big Data Analytics Master - UPV
● Former Professor at Specialist ENS Course - Univ. Mondragón
● Teacher (+30 courses)
● Speaker (+40 talks)
● +14 years of professional experience
https://fjbarrena.dev

El viaje
- Francisco Javier Barrena
Francisco Javier Barrena - @dogdeveloper

where the fuck are my cookies?
● Desde el 4 de enero de 2024, Google empezó a testear con
usuarios reales sus nuevas features sobre privacidad,
deshabilitando el uso de cookies de terceros (Third Party
Cookies) para el 1% de los usuarios
● Del 4 de enero al 1 de Abril de 2024 se considera periodo
de gracia
● A partir del 1 de Abril, Google empezará a aumentar el % de
usuarios con las cookies de terceros deshabilitadas por
defecto, hasta llegar al 100% a finales de año
Cookie

@DogDeveloper - Francisco Javier Barrena

.400.000.000

● Ene. 2021 - Mar. 2022. EL ARMAGGEDDÓN
○ Refactor de la API en Typescript con NestJS - ACIERTO
○ Refactor del modelo de datos siguiendo patrones SOLID -
ACIERTO
○ Deployment en plain Kubernetes - ACIERTO
○ Ni de coña pudimos refactorizar el front
○ Se pone en staging en el cliente en tiempo
○ La calidad del producto no es la que nos gustaría, pero es
suficiente
● Mar. 2022 - Jun. 2022. Aquí la liamos un poco
○ El cliente empieza a pedir cambios
○ Pero nosotros nos volvemos locos y empezamos a desarrollar
features a cascoporro - ERROR
El viaje

un poco de historia
● Las cookies fueron creadas en 1994 por un empleado de
Netscape, mientras implementaba un carrito de la compra
● No quería guardar la información del carrito en el servidor,
prefería guardarlo en lado del cliente, para ahorrarse unos
duros en el servidor
● Internet Explorer no tardó en seguir a Netscape en 1995
● Y en 1996 se publicó el primer artículo acerca de los problemas
de privacidad que las cookies traían consigo

como funcionan las cookies?
● Imaginemos que tenemos un sitio web que requiere a sus
usuarios que se logueen
● Al loguearse, envían una petición HTTP con su usuario y
password al servidor, que autoriza o deniega el acceso

● Y aquí es donde está el matiz… el protocolo HTTP es
stateless
● Esto significa que cuando hagamos otra petición al mismo
servidor, éste habrá olvidado quién eres, y por lo tanto,
volverá a preguntarte quién eres
● Esto es extremadamente time-consuming e ineficiente

Fuente: https://www.youtube.com/watch?v=QWw7Wd2gUJk

● Aquí es donde entran las cookies. Siguiendo el mismo flujo
descrito anteriormente, el servidor, además de autorizarte,
envía una cookie a tu navegador
● Esta cookie se almacena en tu ordenador, y se “reenvía”
automáticamente en cada petición subsiguiente que hagas
al mismo sitio web
● Estas cookies contienen un identificador único que permiten
al servidor “recordar” quién eres (token JWT, etc.)

que es una cookie de terceros?
● Explicar que es una cookie de terceros

● Las cookies también se pueden usar para más cosas, como
por ejemplo almacenar settings, recordar en qué capítulo y
segundo te quedaste viendo una serie, etc.
● Así que las cookies son un mecanismo útil que “añade”
memoria a un protocolo que por diseño es stateless

qué limites tienen las cookies?
● Las cookies además, ya tienen limitaciones,
principalmente
○ Número máximo de cookies por browser/domain
■ Safari - 600
■ Chrome - 180
■ Firefox - 150
■ Opera - 60
■ ¿ Y Edge?

qué limites tienen las cookies?
● Las cookies además, ya tienen limitaciones,
principalmente (cont.)
○ Máximo 4096 bytes de datos
○ Y la más importante, las cookies están acotadas al
dominio que las creó
○ Es decir, si yo creo una cookie en
https://fjbarrena.dev las cookies solo se adjuntarán
a las peticiones a https://fjbarrena.dev

entonces cuál es el problema?
● Si una cookie de un dominio no puede ser leído por otro
dominio… ¿cómo nos trackean? ¿cómo puede Google
saber a qué sitios hemos visitado?
● Todo el proceso de tracking empieza cuando entras a tu
cuenta de Google (o de Facebook, o de Twitter,
ponga-aquí-la-gran-empresa-que-usted-quiera)
● Como ya hemos visto, Google guarda una cookie en tu
navegador en su proceso de login, hasta aquí nada fuera de
lo normal

● Esta cookie es scoped, es decir, está bindeada al dominio
google.com, por lo que nadie excepto Google va a poder
leerla
● Ahora imaginemos que sales de Google, y visitas una tienda
online para comprar unos Plenny Shake, tus batidos
nutricionales 100% Veganos que sustituyen tu desayuno,
comida y cena
● Y de repente…

● Si la cookie que haya puesto https://esjoy.es solo la puede
leer https://esjoy.es porqué carajo ahora entro en Youtube y
me sale un fucking anuncio de Plenny Shake

● No, no nos han engañado, pero han sido muy listos. Google
no puede leer la cookie de la tienda online, ni viceversa, el
scope lo impide, pero imaginemos que la tienda online
tiene Google Analytics, o un botón de compartir en
Facebook, o un tweet (me niego a llamarlo ‘post’)
embebido…
● Para usar Google Analytics, o lo que sea, el navegador
necesita descargarse código del dominio de Google
● Como ya hemos visto, todas las cookies se mandan
autoḿaticamente al dominio, y así es como se manda la
cookie de Google a través de esjoy.es

y ese es el truco…
● El truco es sencillo… convence al mayor número de sitios
web posibles de que pongan en algún sitio un trocito de tu
código en su página…
○ Un botón de “Me gusta”
○ Un “Logueate con Google”
○ Una librería de analítica web
○ Una librería para poner algún anuncio y poder
monetizar tu blog
○ Etc.
● Y qué curioso que todas estas cosas sean “gratis”...

como de grave es?

third party cookies
● Esto precisamente es una third-party cookie. Una cookie
configurada por alguien que no es del dominio del website.
● En el ejemplo anterior, la cookie de Google es una
third-party cookie, porque se envía a través de
https://esjoy.es
● Una third-party cookie es una especie de cookie “parásito”

first party cookie
● En contraposición, una first-party cookie es una cookie que
el dueño del website “settea” directamente. En este ejemplo,
las cookies setteadas por https://esjoy.es son first-class
cookies.
● Estas cookies no se ven afectadas por el cambio de
Chrome, solo las third-party cookies

third-party cookies malas! malas!
● Aunque se utilicen, efectivamente, para trackear y
personalizar anuncios, las third-party cookies también se
utilizan para el bien
● Son perfectas para interoperabilidad entre sistemas, por
ejemplo, permitiendo Single Sign On entre diferentes
dominios
● Son muy utilizadas también en diferentes protocolos (por
ejemplo, en LMSs como Moodle), asi que quizá te veas
afectado por este cambio más de lo crees.

el caso labster
● Labster sds es un software educativo que utiliza
simulaciones virtuales en el sector STEM
● Los usuarios de Labster son estudiantes (bueno, y
profesores) de todo el mundo, pero los clientes de Labster
no son ellos, son las instituciones educativas
(universidades, institutos, colegios…)
● Estas instituciones tienen sus propios sistemas de gestión
académica (LMS: Learning Management System), en los
cuales Labster debe integrarse

el caso labster
● Pero además es que hay un montón de LMSs
○ Blackboard
○ Moodle
○ Canvas API
○ Schoology
○ Vitalsource*
○ Classlink
○ Clever
○ Brightspace
○ Sakai
○ …
● En cada LMS, Labster se integra a través de un IFRAME y
un protocolo estándar de comunicación llamado LTI

el caso labster
● Este protocolo LTI, en su versión más extendida (la 1.3)
utiliza por debajo third-party cookies
● Es además el protocolo… y los protocolos hay que
seguirlos, a menos que seas Microsoft…
● LTI está trabajando en una actualización del protocolo,
pero…

alternativas
● El nuevo Privacy Sandbox ofrece 4 alternativas
○ CHIPS, o Partitioned Cookies
○ Storage Access API
○ Related Website Sets
https://developers.google.com/privacy-sandbox/3pcd

CHIPS
● Cookies Having Independent Partitioned State, o cookies
particionadas
● Con este tipo de cookies, se evita que cookies de terceros
activen servicios para trackear usuarios en sitios web de los
que no sean dueños del dominio o cross-site tracking
(exactamente lo que se quiere evitar)

CHIPS
● Así funcionan las cookies no particionadas (las normales
vamos)

CHIPS
● Y así funcionan las cookies particionadas

CHIPS
● Pero sobretodo… evitan esto

CHIPS
● Pros
○ Súper fácil de implementar. Simplemente crea tu third-party
cookie como siempre, y añádele un ; Partitioned al final
○ Transparente para los usuarios. No se darán cuenta del
cambio
● Contras
○ La mayoría de APIs de servidores aún no lo contemplan,
aunque se puede transformar a string y hacerle un append
manualmente
○ No es una solución completa, si se abre una pestaña nueva
se pierden las cookies, aunque sea en el mismo dominio
○ Solo soportado por Chrome, Edge y Opera de momento
■ Pero es un estándar, todos los browsers terminarán por
implementarlo

Storage access API
● Nueva API de Javascript que permite que los iframes
soliciten permisos de acceso al almacenamiento de sus
padres
● Permite proporcionar acceso a cookies específicas entre
sitios (explícito y mínimo), evitando el uso de cookies
genéricas para tracking de usuarios
● De momento, solo se permite el acceso a las cookies del
iframe hijo al sitio padre, aunque se están planteando
extenderlo a más objectos (LocalStorage, SessionStorage,
etc.)

Storage access API
● Básicamente, son dos métodos
● Al solicitar acceso, le aparecerá al usuario un mensaje como
este

Storage access API
● El mecanismo es bastante sencillo en realidad

storage access api
● Pros
○ Es la solución donde se programa más (no se si es un
contra…)
○ Más control fino, pero a costa de más mantenimiento
después
● Contras
○ Ni dios va a decir “Acepto” al mensajito
○ Implica muchos cambios en el código, a muchos
niveles

related website set (RWS)
● Registro donde las empresas declaran las relaciones entre
sitios a los navegadores, de modo que éstos permitan un
acceso limitado a las third-party cookies para fines
específicos
● Para hacer esto (en el caso de Chrome), solo hay que hacer
una PR a un repo con un JSON específico, declarando
estas relaciones
● A mi me parece una puta mierda…

related website set

related website set
● Pros
○ Solución política (o quizá es un contra…)
○ Hyperfácil (si funciona la política)
● Contras
○ Declarar todas las relaciones entre sitios puede ser
complicado
○ Cada browser tendrá su propia lista… así que hay que
multiplicar ese esfuerzo mínimo x3
○ En realidad no arreglas tu dependencia con las third
party cookies, simplemente le metes una excepción
que te deja a merced del proveedor del browser

solución escogida
● Evaluando todas las opciones, nosotros nos decantamos
por utilizar CHIPS
○ Son las más transparentes para el usuario
■ Básicamente, el usuario ni se entera
■ Storage API le pide al usuario que acepte
○ Son las que nos dan más control del resultado final
■ Storage API depende de que el usuario acepte, y
de que el frame padre también lo permita
■ RWS depende del cada fabricante de browser, si
un día Google decide cobrarte por estar en el
registro, pues a pagar
● Pero las CHIPS no son una solución completa…

solución escogida
● Pero las CHIPS no son una solución completa
● Como vimos anteriormente, todas las cookies se pierden
en cuanto abrimos una ventana o una pestaña nueva.
Esto es así porque una cookie particionada solo existe en el
scope de un iframe dentro de un determinado dominio
● Aquí es donde el concepto de One Time Token entra en
juego

one time tokens
● Un One Time Token es un token temporal, de vida corta
que autoriza a un usuario
● Esta autorización puede ser de varias maneras, pero una
ideal podría ser… efectivamente… ¡una cookie!
● Podemos entenderlo como un token temporal que me
permite intercambiarlo por una first-party cookie de
autorización

one time tokens
● Son muy fáciles de implementar y solo necesitas dos
endpoints
● Uno que reciba un usuario autenticado y genere un one
time token asociado a ese usuario
● Y otro endpoint que reciba un one time token y devuelva
una nueva cookie de autorización
○ Éste endpoint debe ser público, es decir, debe de
poder ser invocado por cualquiera

one time tokens

one time tokens
● Puedes guardar los OTT como quieras, pero aquí van
algunas recomendaciones que te harán la vida más fácil
○ Los OTT son de consumo rápido, y se generan justo
antes de ser consumidos
○ Si tienes un REDIS o algo similar puedes utilizar su
API para generar items que caduquen
automáticamente después de pocos segundos (15 por
ejemplo).
○ Si no, puedes guardarlos en tu base de datos, pero
tendrás que programar (y monitorizar) un cronjob que
los revise y elimine los expirados…

one time tokens y el frontend
● Para consumirlo es muy fácil, simplemente checkea si hay
una query string de OTT presente y llama al endpoint de
/use
○ El endpoint manda una cookie de autorización, que el
navegador procesará automáticamente

no caigáis donde caí yo
● Si tenéis la oportunidad, investigad qué navegadores y qué
versiones de navegador utilizan vuestros usuarios
○ CHIPS disponibles en Chrome a partir de version
113
○ En versiones anteriores de Chrome las CHIPS no
funcionan
○ Paradójicamente, las CHIPS son tomadas como
cookies normales en Safari y Firefox, que no
soportan todavía CHIPS…
● En Javascript, la API de las cookies es una basura
○ Eso os va a obligar a hacer algunas pirulas
● Ojo al momento del despliegue…
○ Las cookies las usa todo dios, desde el minuto uno
○ Y o funcionan, o no funcionan…
○ Así que o triunfas, o te la pegas

no caigáis donde caí yo
● Ojo en el testeo. No limpies cookies y dejes un entorno
limpio en desarrollo/testeo. La realidad no va a ser así
● Si vais a desplegar a nivel mundial, haced targeting con
Feature Flags si podéis

● Now: CTO at Kyso Inc.
● Former Head of Engineering and Head of Cybersecurity
Research Group at ITI
● Former Professor at Big Data Analytics Master - UPV
● Former Professor at Specialist ENS Course - Univ. Mondragón
● Teacher (+30 courses)
● Speaker (+40 talks)
● +12 years of professional experience
Gracias!

¡Cookiegeddon! Bye a las cookies de terceros y cómo afectará a tu software

Recomendados

Recomendados

Más contenido relacionado

Similar a ¡Cookiegeddon! Bye a las cookies de terceros y cómo afectará a tu software

Similar a ¡Cookiegeddon! Bye a las cookies de terceros y cómo afectará a tu software (20)

Más de Francisco Javier Barrena

Más de Francisco Javier Barrena (15)

Último

Último (20)

¡Cookiegeddon! Bye a las cookies de terceros y cómo afectará a tu software