Cómo las cookies particionadas CHIPS dan a cada sitio su propio tarro

¿Qué son las cookies particionadas CHIPS?

Los navegadores guardan las cookies particionadas CHIPS en un tarro aparte para cada sitio de nivel superior, así que la cookie que pone un widget de soporte mientras está incrustado en retail.example resulta ilegible para ese mismo widget incrustado en news.example. CHIPS significa Cookies Having Independent Partitioned State y funciona con un solo atributo opcional: añade Partitioned a la cabecera Set-Cookie y el navegador guarda la cookie bajo dos claves en lugar de una, el host que la puso más el sitio de nivel superior bajo el que se puso. Añádelo a cualquier cookie entre sitios confinada a un único sitio de nivel superior, como una sesión de chat, una pista de balanceo de carga de un CDN o una ubicación de mapa guardada.

El doble clavado es lo que separa CHIPS de la cookie third-party simple, que viaja con el incrustado a todas partes y alimenta el rastreo entre sitios. Una cookie particionada no puede salir del sitio en el que nació, así que un incrustado recibe un identificador nuevo por sitio de nivel superior y nada que unir entre ellos. Si las dos categorías se te mezclan, empieza por cookies first-party y third-party.

¿Qué exige el atributo Partitioned?

El atributo Partitioned exige Secure, y los navegadores tiran cualquier cookie particionada que llegue sin él. El explainer de CHIPS del W3C Privacy Community Group instruye a quien lo implemente: "User agent must reject any cookie set with Partitioned that does not also include the Secure." En español: el agente de usuario debe rechazar cualquier cookie puesta con Partitioned que no incluya también Secure. La documentación de Privacy Sandbox de Google lo repite para desarrolladores: "Partitioned cookies must be set with Secure.", es decir, las cookies particionadas deben ponerse con Secure. El borrador del IETF draft-cutler-httpbis-partitioned-cookies-01 del 10 de noviembre de 2022 da la razón en sus consideraciones de seguridad: "This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols." En español: esta propuesta aprovecha que define la semántica de un atributo de cookie nuevo para exigir el atributo Secure y restringir esta función a protocolos seguros.

El Path=/ de todos los ejemplos oficiales viene de una segunda regla, que trae el prefijo de nombre __Host- y no Partitioned en sí. RFC 6265bis, borrador 22 de diciembre de 2025, sección 4.1.3.2, la define: "If a cookie's name begins with a case-sensitive match for the string __Host-, then the cookie will have been set with a Secure attribute, a Path attribute with a value of /, and no Domain attribute." En español: si el nombre de una cookie empieza por una coincidencia exacta en mayúsculas y minúsculas con la cadena __Host-, entonces la cookie se habrá puesto con un atributo Secure, un atributo Path con valor / y sin atributo Domain. Llama a la cookie __Host-something y el navegador impone Path=/ por ti, rechazando cualquier otra cosa. El explainer de CHIPS recomienda el prefijo sin exigirlo: "Although it is not required, it is still recommended to still include the __Host- prefix." Los navegadores que ignoran Partitioned siguen imponiendo __Host-, así que el prefijo compra vinculación al host en clientes que jamás han oído hablar de CHIPS.

SameSite es la tercera pieza. El explainer dice que los agentes de usuario pueden aceptar Partitioned solo cuando SameSite vale None, y una cookie hecha para funcionar dentro de un marco entre sitios necesita SameSite=None de todos modos. Mira la guía para principiantes sobre cookies del navegador para ver cómo interactúan los atributos.

¿Qué es exactamente la clave de partición?

La clave de partición es el sitio de la página de la barra de direcciones, no el sitio del incrustado. El explainer de CHIPS lo define con precisión: "A cookie's partition key is the site (i.e. scheme and registrable domain) of the top-level URL the browser was visiting at the start of the request to the endpoint that set the cookie." En español: la clave de partición de una cookie es el sitio, es decir el esquema y el dominio registrable, de la URL de nivel superior que el navegador estaba visitando al inicio de la petición al endpoint que puso la cookie. Dos palabras ahí hacen trabajo real. "Site" significa el dominio registrable, así que support.shoppy.example y checkout.shoppy.example comparten partición. "Scheme" mete el protocolo en la clave, así que http://shoppy.example y https://shoppy.example no la comparten.

Chrome añade un campo más. Chrome Platform Status deja constancia del cambio: "Chrome 128 adds a cross-site ancestor bit to the keying of the partitioned cookie's CookiePartitionKey." En español: Chrome 128 añade un bit de ancestro entre sitios al claveado del CookiePartitionKey de la cookie particionada. Ese bit registra si hay un marco entre sitios entre el documento de nivel superior y el marco que hace la petición, lo que impide que un incrustado alcance las propias cookies particionadas del sitio de nivel superior a través de un iframe anidado. Desde Chrome 128 la clave es un triple: esquema, dominio registrable, bit de ancestro.

¿Cómo es una cabecera Set-Cookie real?

Una cookie particionada es una cabecera Set-Cookie corriente con cuatro atributos. Este es el ejemplo que publican la documentación de Privacy Sandbox de Google y MDN, carácter por carácter:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Esa respuesta tiene que llegar por HTTPS, ya que Secure y __Host- exigen ambos un origen seguro. En una petición posterior al mismo incrustado bajo el mismo sitio de nivel superior, el navegador devuelve la cookie pelada:

Cookie: __Host-example=34d8g

Navega a otro sitio de nivel superior y esa segunda cabecera desaparece. El incrustado no ve ninguna cookie y acuña un valor nuevo, que es justo el objetivo.

¿Qué navegadores aceptan el atributo Partitioned?

Tres motores lo aceptan. Estas versiones salen de los datos de compatibilidad de navegadores de MDN para Partitioned.

MDN marca las cookies particionadas como Baseline newly available desde diciembre de 2025. Los clientes que no reconocen el atributo lo ignoran y tratan la cookie como una cookie SameSite=None corriente, así que tu plan B es lo que sea que ese navegador haga con las cookies third-party. En Safari el plan B es nada, porque Intelligent Tracking Prevention las bloquea de plano y recorta las cookies puestas por script con el límite de 7 días de cookies en Safari.

¿Cuánto puede guardar un incrustado en una sola partición?

Chrome limita una partición a 180 cookies y 10 KB por sitio incrustado. Su documentación de CHIPS lo dice directamente: "Chrome has a limit of maximum 180 cookies per partition that cannot exceed 10 KB per-embedded-site." En español: Chrome tiene un límite máximo de 180 cookies por partición que no pueden superar los 10 KB por sitio incrustado. El tope de bytes ata antes en la mayoría de incrustados, así que el número que hay que mirar es:

bytes de partición usados = número de cookies x bytes medios por cookie

Un incrustado que guarda 20 cookies de 500 bytes de media cada una usa 20 x 500 = 10.000 bytes y toca el techo de 10 KB con 160 de las 180 plazas libres. Pasado el presupuesto de bytes el navegador desaloja, así que presupuesta por tamaño, no por número.

¿Chrome sigue eliminando las cookies third-party?

No. El anuncio más reciente de Privacy Sandbox de Google, "Update on Plans for Privacy Sandbox Technologies" de Anthony Chavez, VP of Privacy Sandbox, con fecha 17 de octubre de 2025, remite a la decisión anterior "that Chrome will maintain our current approach to offering users third-party cookie choice in Chrome.", o sea que Chrome mantendrá su enfoque actual de ofrecer a los usuarios la elección sobre cookies third-party. No hay ninguna eliminación programada para todo el navegador ni viene ningún aviso nuevo. Chrome permite las cookies third-party en la navegación normal y las bloquea en Incógnito.

Ese mismo anuncio es la razón por la que merece la pena construir sobre CHIPS. Retiró la Attribution Reporting API, Protected Audience, Topics, Private Aggregation y Related Website Sets, y luego señaló a CHIPS para el trato opuesto: "CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements." En español: CHIPS y FedCM, que mejoran la privacidad y la seguridad de las cookies y agilizan los flujos de identidad respectivamente, han visto una adopción amplia, incluido el apoyo de otros navegadores. Seguiremos dando soporte a esas API y evaluando oportunidades de mejoras futuras. Related Website Sets está en la lista de retirados. CHIPS no.

¿Qué significa esto para tu analítica?

La analítica que no pone cookies se salta la pregunta. El particionado resuelve un problema que solo tienes cuando un script recuerda a un visitante mediante almacenamiento del navegador, así que el rastreo sin cookies elimina el modo de fallo en vez de aislarlo. La analítica sin cookies y alojada en la UE de Flowsery registra sesiones y repeticiones sin cookies, así que no hay ninguna clave de partición que puedas equivocar.

El cálculo cambia si tu producto entrega un widget que otras empresas incrustan. Ese widget necesita estado, el sitio de nivel superior no es tuyo, y CHIPS lo mantiene funcionando. Añade Partitioned, usa el prefijo __Host-, conserva SameSite=None; Secure y prueba la primera petición en una partición limpia, porque ese camino ahora corre en cada nuevo sitio de cliente.

Preguntas frecuentes

¿El atributo Partitioned necesita Path=/?

No por Partitioned en sí. El explainer de CHIPS, el borrador del IETF y la documentación de CHIPS de Google omiten todos Path=/ de los requisitos del atributo. Aparece en todos los ejemplos oficiales porque esos ejemplos usan el prefijo __Host-, y RFC 6265bis exige que las cookies __Host- lleven un Path de / y ningún atributo Domain.

¿Es obligatorio el prefijo __Host- en las cookies particionadas?

No. El explainer de CHIPS dice que el prefijo "is not required" pero es "still recommended", es decir, no es obligatorio pero se sigue recomendando, así que una cookie particionada sin él se acepta. Úsalo igualmente: los navegadores que ignoran Partitioned siguen imponiendo el prefijo y atan tu cookie al host exacto.

¿Las cookies particionadas siguen necesitando consentimiento bajo el GDPR?

Sí. El particionado cambia quién puede leer una cookie, no si una aterriza en el dispositivo. El requisito de consentimiento de la Directiva ePrivacy se activa al almacenar información en el equipo terminal de un usuario o acceder a ella, y una cookie particionada hace ambas cosas. Las cookies estrictamente necesarias siguen exentas en cualquier caso.

¿Puede un sitio de nivel superior borrar las cookies particionadas de un incrustado?

No. El explainer de CHIPS afirma que los sitios de nivel superior no deben poder borrar las cookies de terceros en su partición, ya que eso dejaría a un sitio anfitrión interferir con el código dentro de marcos incrustados. Un incrustado borra su propia partición enviando Clear-Site-Data, que toca solo la partición del sitio de nivel superior actual.

¿En qué se diferencia CHIPS del particionado de estado de Firefox?

Firefox particiona el almacenamiento de cookies third-party por defecto, sin que el sitio opte por ello. CHIPS es un atributo que un servicio añade a propósito, y se aplica igual en contextos first-party y third-party. MDN recomienda optar por CHIPS antes que por el particionado de estado, porque el atributo explícito es el más compatible entre navegadores.

¿Qué sustituye a CHIPS si un incrustado necesita una cookie en varios sitios?

La Storage Access API. Related Website Sets cubría antes ese caso declarando un grupo de dominios relacionados, y el anuncio de Google del 17 de octubre de 2025 lo listó entre las tecnologías retiradas. La Storage Access API pide permiso al usuario para usar almacenamiento no particionado en un marco entre sitios, y es la vía soportada que queda para el estado compartido.

¿Funciona Partitioned con SameSite=Lax o SameSite=Strict?

El explainer de CHIPS permite a los navegadores aceptar Partitioned solo cuando SameSite es None, así que una cookie con Lax o Strict puede quedar sin particionar aunque lleve el atributo. La combinación encaja con el caso de uso, porque una cookie particionada importa dentro de un embed cross-site, y un embed necesita SameSite=None para recibir una cookie. Define SameSite=None; Secure junto con Partitioned y la duda desaparece.

¿Qué pasa cuando una partición supera el límite de 10 KB de Chrome?

Chrome impone un límite de 180 cookies y 10 KB por partición para cada sitio incrustado, y en cuanto el almacenamiento cruza cualquiera de los dos límites, el navegador expulsa cookies de esa partición. El límite de bytes suele activarse primero: un puñado de cookies de unos cientos de bytes cada una puede llenar los 10 KB mientras decenas de los 180 espacios siguen libres. Calcula el presupuesto por bytes totales guardados por sitio de nivel superior, no por el número de cookies que planeas fijar.

¿Se puede fijar una cookie particionada por HTTP simple?

Secure lo impide. El atributo Partitioned exige Secure, y el borrador del IETF señala precisamente esa combinación como el motivo para definir el nuevo atributo, restringiendo la función a protocolos seguros. Una cabecera Set-Cookie enviada por HTTP simple pierde tanto Partitioned como la cookie que lo lleva.

¿Qué es el bit de ancestro cross-site en la clave de partición de Chrome?

Desde Chrome 128, la clave de partición suma un tercer campo, junto al esquema y el dominio registrable, que registra si hay un frame cross-site entre el documento de nivel superior y el frame que hizo la solicitud. Ese bit de ancestro impide que un incrustado llegue a las propias cookies particionadas del sitio de nivel superior a través de un iframe anidado. Las versiones anteriores de Chrome y otros navegadores solo usan el esquema y el dominio registrable para la clave.