Solo el dominio decide entre cookies first-party vs third-party

¿Cuál es la diferencia entre cookies first-party vs third-party?

Los navegadores clasifican las cookies first-party vs third-party con una sola prueba, comparando el dominio que puso la cookie con el dominio de la barra de direcciones: la cookie es first-party, es decir del propio dominio de la página, cuando ambos coinciden, y third-party, de un dominio ajeno, cuando no. Nada del interior de la cookie entra en esa prueba, ni el nombre, ni el valor, ni el propietario. La guía de MDN sobre cookies third-party enuncia la regla sin rodeos: "If the cookie domain and scheme match the current page the user is looking at (the URL shown in the browser's address bar), the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." En español: si el dominio y el esquema de la cookie coinciden con la página que el usuario está viendo (la URL que aparece en la barra de direcciones del navegador), la cookie se considera del mismo sitio que la página y se llama cookie first-party. Dominio o esquema distinto, cookie third-party.

Casi todas las páginas de internet describen la división como tu cookie contra la cookie de un anunciante. Ese planteamiento es falso. La cookie de una red publicitaria, leída en el sitio propio de esa red, es first-party; tu propia cookie de sesión, leída dentro de un iframe en el sitio de un socio, es third-party.

¿Por qué la misma cookie es a veces first-party y a veces third-party?

La categoría pertenece a la lectura, no a la cookie. Una cookie guardada lleva un dominio, y el navegador repite la comparación en cada petición, así que mover la lectura a otro sitio de nivel superior invierte la respuesta.

Toma un widget de soporte que pone una cookie en widget.example. Un visitante que está en https://widget.example envía esa cookie como cookie first-party, porque el dominio de la cookie coincide con la barra de direcciones. El mismo visitante abre https://shop.example, donde el mismo widget carga en un iframe. El navegador compara widget.example con shop.example, no encuentra coincidencia, y la cookie idéntica viaja como cookie third-party bajo todas las restricciones que el navegador impone a esa categoría. Una cookie en el almacenamiento, dos categorías, decididas petición a petición.

¿Qué hizo Chrome en realidad con la eliminación de las cookies third-party?

Chrome la canceló. Anthony Chavez, VP of Privacy Sandbox, escribió el 22 de abril de 2025 que Google había "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." En español: tomado la decisión de mantener su enfoque actual de ofrecer a los usuarios la elección sobre las cookies third-party en Chrome, y no lanzará un nuevo aviso independiente para las cookies third-party. Las cookies third-party siguen activadas de forma predeterminada en el modo de navegación normal de Chrome, y el control sigue en los ajustes de Privacidad y seguridad. La documentación de ayuda de Chrome indica que las cookies third-party se bloquean de forma predeterminada en el modo Incógnito, así que el bloqueo se aplica a un modo de navegación en lugar de al navegador.

Cualquier artículo que todavía cite una fecha de retirada está citando un plan que Google retiró. Construye contra lo que se envía: Safari bloquea, Firefox particiona, Chrome permite fuera de Incógnito.

¿Qué hacen Safari y Firefox con las cookies third-party?

Safari borra la categoría y Firefox la divide. John Wilander anunció el bloqueo total en el blog de WebKit el 24 de marzo de 2020 en una sola frase: "Cookies for cross-site resources are now blocked by default across the board." En español: las cookies de recursos entre sitios ahora están bloqueadas de forma predeterminada en todos los casos. La política de prevención de rastreo de WebKit confirma que Intelligent Tracking Prevention "blocks all third-party cookies", es decir bloquea todas las cookies third-party, y deja una sola vía de vuelta, la Storage Access API, que pregunta antes al usuario.

Firefox tomó el otro camino. Mozilla desplegó Total Cookie Protection para todos los usuarios del mundo el 14 de junio de 2022, y mantiene vivas las cookies third-party dentro de un límite: "any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to only that website." En español: cada vez que un sitio web, o contenido third-party incrustado en un sitio web, deposita una cookie en tu navegador, esa cookie queda confinada al tarro de cookies asignado solo a ese sitio web. Un rastreador incrustado sigue recibiendo una cookie en cada sitio donde aparece, y recibe una distinta cada vez, lo que mata la unión entre sitios sin matar el widget.

Cookies first-party vs third-party comparadas

La última fila explica por qué el bloqueo cayó de un solo lado. Bloquear las cookies third-party rompe la fontanería entre sitios de otras personas; bloquear las cookies first-party rompería la web.

¿Qué se rompe cuando se bloquean las cookies third-party?

Se rompe el estado entre sitios, y solo el estado entre sitios. El single sign-on a través de un proveedor de identidad dentro de un iframe deja de reconocer al usuario, un checkout o un widget de chat incrustado pierde al cliente que vuelve, y una plataforma publicitaria pierde la atribución de conversiones y la limitación de frecuencia, porque cada uno necesita un identificador leído en dos sitios de nivel superior distintos.

Dos sustitutos cubren las partes que vale la pena conservar. La Storage Access API permite que un marco incrustado pida al usuario sus cookies sin particionar. Las cookies particionadas se ocupan del resto.

¿Cómo cambian el panorama las cookies particionadas?

Las cookies particionadas conservan la cookie third-party y eliminan la unión entre sitios añadiendo el sitio de nivel superior a la clave de almacenamiento. MDN documenta el mecanismo como CHIPS, Cookies Having Independent Partitioned State, y lo registra como Baseline newly available desde diciembre de 2025. El cambio es una sola línea de estructura de clave:

storage key = (top-level site, cookie domain) en lugar de storage key = (cookie domain)

Trabaja un ejemplo con los propios valores de MDN. Un widget en 3rd-party.example envía Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned; mientras está incrustado en site-a.example, y el navegador la guarda bajo {("https://site-a.example"), ("3rd-party.example")}. En site-b.example el widget pide la cookie, el navegador busca {("https://site-b.example"), ("3rd-party.example")} y no encuentra nada. El widget funciona en los dos sitios y no enlaza ninguno con el otro.

¿Sobreviven las cookies first-party a todo?

No, y la excepción golpea primero a la analítica. La política de prevención de rastreo de WebKit compromete a la ITP a "deleting all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction", en español: borrar todas las cookies creadas en JavaScript y todo el demás almacenamiento escribible por script después de 7 días sin interacción del usuario, lo que incluye una cookie first-party escrita por un script de analítica en tu propio dominio. La regla se fija en cómo se escribió la cookie, no en el dominio donde reside, así que el límite de 7 días de las cookies en Safari acorta cualquier identificador del lado del cliente.

El efecto visible es un recuento inflado de visitantes nuevos, porque un visitante que vuelve pasado el límite llega sin identificador y empieza una sesión nueva. Pon los identificadores desde el servidor en una cabecera de respuesta Set-Cookie si necesitas que sobrevivan al límite.

¿Qué significa esto para medir tu propio sitio?

La analítica que se apoya en una cookie third-party mide el modo de navegación normal de Chrome y poco más. Mover el identificador a una cookie first-party amplía la cobertura y choca con el límite de la ITP, y por eso la medición sigue derivando hacia el servidor: lee los argumentos a favor del tracking del lado del servidor antes de reconstruir un identificador de cliente por tercera vez.

Ninguna de las dos categorías escapa a la ley de consentimiento. El artículo 5(3) de la Directiva ePrivacy pregunta si se almacena información en el dispositivo o se lee de él, así que una cookie first-party de analítica lo activa igual que una third-party, que es lo que un banner de consentimiento existe para satisfacer. No guardar ningún identificador elimina el disparador, y la analítica sin cookies cubre lo que eso te cuesta.

Flowsery está construido así. Su analítica que prioriza la privacidad no usa cookies, se aloja en la UE y es GDPR by design, se entrega como un solo script de menos de 10 KB y no aplica muestreo de datos, así que nunca cae en ninguno de los dos lados de la división entre first-party y third-party.

Preguntas frecuentes

¿Una cookie first-party está siempre a salvo del bloqueo del navegador?

No. La ITP de Safari borra las cookies creadas en JavaScript, junto con el resto del almacenamiento escribible por script, después de 7 días sin interacción del usuario, y eso se aplica en tu propio dominio. Una cookie first-party puesta por el servidor en una cabecera de respuesta Set-Cookie queda fuera de esa regla. Lo que cuenta es cómo se escribió la cookie, no quién es dueño del dominio.

¿El navegador mira quién es dueño del dominio?

No. El navegador compara el dominio y el esquema de la cookie con la página de nivel superior de la barra de direcciones y nada más. La propiedad, la empresa y el propósito nunca entran en la comparación, y por eso la cookie de un anunciante es first-party en el sitio propio del anunciante.

¿Puede una cookie ser first-party y third-party a la vez?

Sí, y la misma cookie guardada cambia entre las dos en cada petición. Leída en el dominio que la puso, la cookie es first-party. Leída desde un iframe en otro sitio de nivel superior, la cookie idéntica es third-party y hereda todas las restricciones third-party.

¿Por qué una cookie third-party necesita SameSite=None y Secure?

Las peticiones entre sitios llevan una cookie solo cuando está marcada como SameSite=None, ya que el valor por defecto del navegador es SameSite=Lax. MDN indica que "if SameSite=None is set then the Secure attribute must also be set", en español: si se establece SameSite=None, también debe establecerse el atributo Secure, lo que la restringe a HTTPS. Sin los dos atributos, un navegador moderno nunca envía la cookie entre sitios.

¿Google llegó a eliminar las cookies third-party de Chrome?

No. Anthony Chavez escribió el 22 de abril de 2025 que Google iba a "maintain our current approach to offering users third-party cookie choice in Chrome", es decir mantener su enfoque actual de ofrecer a los usuarios la elección sobre las cookies third-party en Chrome, y que no lanzaría un aviso independiente. Chrome permite las cookies third-party de forma predeterminada en la navegación normal y las bloquea de forma predeterminada en el modo Incógnito, según la documentación de ayuda de Chrome.

¿Firefox borra las cookies third-party como hace Safari?

No, Firefox las aísla. Total Cookie Protection, predeterminada en todo el mundo desde el 14 de junio de 2022, confina cada cookie a "the cookie jar assigned to only that website", el tarro de cookies asignado solo a ese sitio web, así que un rastreador incrustado recibe una cookie distinta en cada sitio donde aparece. El elemento incrustado sigue funcionando, y el perfil entre sitios nunca se arma.

¿Qué significa CHIPS?

CHIPS significa Cookies Having Independent Partitioned State, el mecanismo que MDN documenta detrás de las cookies particionadas. Añade el sitio de nivel superior a la clave de almacenamiento de la cookie, de modo que el mismo dominio de cookie recibe un valor distinto en cada sitio que la incrusta. MDN registra CHIPS como Baseline newly available desde diciembre de 2025.

¿Qué es la Storage Access API?

La Storage Access API permite que un iframe incrustado pida al navegador acceso a sus cookies no particionadas, con una solicitud previa al usuario. La política de prevención de rastreo de WebKit de Safari la nombra como la única vía de vuelta tras bloquear todas las cookies third-party. Las cookies particionadas cubren el resto de lo que el estado entre sitios necesita para seguir funcionando.

¿Las cookies first-party también necesitan consentimiento?

El artículo 5(3) de la Directiva ePrivacy pregunta si se almacena o se lee información en el dispositivo, no de quién es el dominio, así que una cookie first-party de analítica activa el mismo requisito de consentimiento que una third-party. Un banner de consentimiento existe precisamente para cumplir ese requisito, sin importar la categoría de la cookie. No almacenar ningún identificador elimina el disparador por completo.

¿Por qué a veces un visitante recurrente cuenta como nuevo en las analíticas?

Un visitante que regresa después del límite de 7 días de ITP en Safari llega sin identificador, así que la analítica inicia una sesión nueva y lo cuenta como nuevo. La regla se aplica a cualquier cookie escrita en el cliente vía JavaScript, incluidos los scripts de analítica first-party en tu propio dominio. Establecer los identificadores desde el servidor en una cabecera de respuesta Set-Cookie evita el límite por completo.