Third-party cookies: qué cambió realmente el giro de Chrome y qué APIs de Privacy Sandbox desaparecen

En 2026 esta descripción ya no es válida.

Chrome no implementó una desactivación general y obligatoria de las third-party cookies según el antiguo calendario. Google decidió mantener el modelo actual, en el que los usuarios pueden gestionar el acceso a esas cookies en la configuración de Chrome. La empresa también renunció al plan de introducir un nuevo prompt específico dedicado a las third-party cookies.

Sin embargo, esto no significa un regreso al estado anterior a Privacy Sandbox.

Las third-party cookies pueden seguir sin estar disponibles debido a:

• una decisión del usuario,
• el modo Incognito,
• las políticas de organización de Chrome Enterprise,
• las limitaciones de un navegador concreto,
• la configuración del sitio,
• un grupo experimental de Chrome,
• mecanismos de particionado y de protección contra el rastreo.

Al mismo tiempo, Google decidió retirar gran parte de las API de Privacy Sandbox, incluidas Topics, Protected Audience, Attribution Reporting, Shared Storage y Related Website Sets. En cambio, permanecen soluciones útiles para casos de uso funcionales, como CHIPS, Storage Access API, FedCM, el particionado de almacenamiento y Private State Tokens.

La conclusión más importante: el giro de Chrome no significa que se pueda volver a diseñar el inicio de sesión, los widgets integrados, la analítica y los pagos asumiendo que las third-party cookies no particionadas siempre estarán disponibles. En 2026 una arquitectura correcta debe soportar ambos estados: cookie disponible y cookie bloqueada.

El estado y la documentación se verificaron el 23 de julio de 2026.

TL;DR

Pregunta	Respuesta para 2026
¿Chrome desactivó las third-party cookies para todos los usuarios?	No
¿Chrome sigue planeando un nuevo prompt específico?	No
¿Puede el usuario bloquearlas?	Sí
¿Se bloquean de forma predeterminada en Incognito?	Sí
¿Debería una aplicación asumir su disponibilidad?	No
¿Desaparece todo Privacy Sandbox?	No
¿Se están retirando las API publicitarias como Topics y Protected Audience?	Sí
¿CHIPS sigue teniendo soporte?	Sí
¿Permanece Storage Access API?	Sí
¿Permanece FedCM?	Sí
¿SameSite=None; Secure garantiza el funcionamiento de la cookie?	No
¿Una única fecha de eliminación se aplica a todas las API?	No

1. ¿Qué es una third-party cookie?

Una cookie es un valor almacenado por el navegador y enviado según las reglas de dominio, ruta, protocolo, tiempo de vida y el atributo SameSite.

Una cookie se considera de tipo third-party cuando se usa en un contexto de sitio distinto del sitio que se encuentra en la parte superior de la pestaña del navegador.

Ejemplo:

Użytkownik otwiera:
https://shop.example

Strona osadza:
https://chat.vendor.example/widget

Si un widget integrado intenta usar una cookie no particionada del dominio chat.vendor.example, lo hace en un contexto de tercero.

Una configuración típica que permite enviar la cookie en un contexto cross-site tiene este aspecto:

Set-Cookie: widget_session=abc123;
  SameSite=None;
  Secure;
  HttpOnly;
  Path=/

SameSite=None permite enviar la cookie en solicitudes cross-site, y Secure es obligatorio para las cookies con SameSite=None en los navegadores modernos.

Sin embargo, esto es solo una condición técnica. No es garantía de que el navegador vaya a admitir la third-party cookie. La configuración del usuario o la política del navegador todavía pueden bloquearla.

2. ¿Cómo fue cambiando el plan de Chrome?

Etapa 1: el anuncio de un mundo sin third-party cookies

Privacy Sandbox surgió como un conjunto de propuestas destinadas a limitar el rastreo entre sitios y, al mismo tiempo, ofrecer soluciones para publicidad, medición, prevención de abusos e identidad.

En enero de 2024 Chrome empezó a restringir las third-party cookies para el 1% de los usuarios dentro de la prueba de Tracking Protection.

Etapa 2: el abandono del phase-out general

En julio de 2024 Google anunció un cambio de rumbo: en lugar de una desactivación general de las cookies, se propuso un enfoque basado en la elección del usuario.

El 22 de abril de 2025 Google concretó la decisión:

• Chrome mantiene su enfoque actual de elección del usuario,
• no se implementará un nuevo prompt específico,
• los usuarios siguen gestionando las cookies en la configuración de Privacy and Security,
• Incognito sigue bloqueando las third-party cookies de forma predeterminada.

Este es precisamente el «giro de Chrome» más importante.

Etapa 3: la reducción de Privacy Sandbox

El 17 de octubre de 2025 Google anunció que, tras analizar la adopción y las opiniones del ecosistema, retiraría una parte importante de las tecnologías de Privacy Sandbox.

En enero de 2026 las release notes de Chrome 144 mencionaron la deprecación y la eliminación prevista de Private Aggregation, Shared Storage y Protected Audience.

Sin embargo, no se debe reducir todo el cambio a Chrome 144. El estado oficial abarca más tecnologías, y el proceso de su retirada está escalonado y se lleva a cabo conforme a los procedimientos de Chrome y de Android.

3. ¿Qué significa «Chrome mantiene su enfoque actual»?

No significa:

• la garantía de disponibilidad de las cookies en cada instalación,
• un regreso al rastreo cross-site sin restricciones,
• la anulación del particionado de almacenamiento,
• un comportamiento idéntico de Chrome, Safari y Firefox,
• la garantía de que una integración existente de SSO o de iframe vaya a funcionar.

Significa que Chrome no sustituyó el modelo actual por una única desactivación global y un nuevo prompt que abarcara a toda la base de usuarios.

La documentación oficial de Chrome sigue describiendo varias causas de bloqueo de cookies:

• la configuración del usuario,
• las limitaciones del navegador,
• los flags de prueba,
• las políticas de Chrome Enterprise.

Esa misma documentación, actualizada el 18 de diciembre de 2025, sigue informando sobre el grupo del 1% de usuarios para el que las third-party cookies están restringidas de forma predeterminada con fines de prueba.

Para el desarrollador, la conclusión práctica es sencilla:

third-party cookie availability = stan runtime,
a nie właściwość gwarantowana przez nazwę przeglądarki

4. ¿Qué tecnologías de Privacy Sandbox se están retirando?

El estado oficial utiliza varias categorías diferentes:

• Deprecate and remove - la API está destinada a deprecación y eliminación.
• Discontinue - el proyecto se ha finalizado o se está retirando.
• Do not launch - la tecnología no se lanzará.
• Scheduled for phaseout - se planea una retirada gradual.

No se deben presentar como una única «desactivación de Privacy Sandbox» simultánea.

Principales tecnologías web destinadas a deprecación y eliminación

Tecnología	Uso original	Estado
Attribution Reporting API	medición de atribución sin identificador cross-site	deprecate and remove
Aggregation Service	agregación de informes para Attribution Reporting	scheduled for phaseout
Topics API	intereses del usuario para la publicidad	deprecate and remove
Protected Audience API	remarketing y subastas de interest-group en el navegador	deprecate and remove
Private Aggregation API	mediciones agregadas cross-site	deprecate and remove
Shared Storage API	almacenamiento cross-site con operaciones controladas	deprecate and remove
SelectURL	selección de una variante de URL en función de Shared Storage	se retira junto con Shared Storage
Related Website Sets	declaración de dominios relacionados	deprecate and remove
requestStorageAccessFor()	solicitud de acceso en nombre de un recurso de un sitio relacionado	deprecate and remove
Related Website Partition	partición compartida para sitios relacionados	discontinue

Tecnologías finalizadas o que no se introducen

Tecnología	Estado
IP Protection	discontinue / scheduled for phaseout
Partitioned Popins	discontinue
Fenced Storage Read	do not launch
Private Proofs	do not launch
Probabilistic Reveal Tokens	do not launch
Script Blocking	do not launch

Android Privacy Sandbox

Google también retira:

• Attribution Reporting,
• On-Device Personalization,
• Protected App Signals,
• Protected Audience,
• SDK Runtime,
• Topics.

5. ¿Qué desaparecía exactamente en Chrome 144?

Chrome 144, publicado como estable en enero de 2026, incluía entradas formales de deprecación para:

• Private Aggregation API,
• Shared Storage API,
• Protected Audience API.

Las release notes hablan de un plan de deprecación y eliminación, no de una garantía de que todos los elementos dejaran de funcionar de inmediato en cada instalación.

Esto es importante durante la migración. Las señales pueden aparecer por etapas:

1. el aviso Intent to Deprecate,
2. advertencias en la consola o en la documentación,
3. el cambio del estado predeterminado,
4. la eliminación del código,
5. un posible deprecation trial o periodo de transición.

El equipo debería seguir Chrome Platform Status y las release notes, en lugar de basarse en una única fecha de un artículo.

6. ¿Qué sigue teniendo soporte?

Privacy Sandbox no desaparece como un único paquete. El estado oficial señala las tecnologías que permanecen con soporte.

CHIPS

CHIPS permite marcar una cookie con el atributo Partitioned. El navegador crea un «tarro» de cookies independiente para cada sitio de nivel superior.

Set-Cookie: __Host-widget_session=abc123;
  Secure;
  HttpOnly;
  Path=/;
  SameSite=None;
  Partitioned

Si chat.vendor.example está integrado en:

shop-a.example
shop-b.example

entonces obtiene dos particiones separadas. Una cookie establecida en el contexto de shop-a.example no está disponible en la integración en shop-b.example.

CHIPS es adecuado, entre otras cosas, para:

• widgets de chat,
• mapas,
• pagos integrados,
• el estado de un componente por sitio,
• recursos que requieren una sesión limitada a un único embedder.

CHIPS no es un reemplazo cuando el mismo identificador debe compartirse entre sitios independientes. Precisamente la ausencia de esa posibilidad constituye el mecanismo de protección de la privacidad.

Storage Access API

Storage Access API permite a un documento integrado comprobar si tiene acceso a cookies no particionadas y solicitar al navegador ese acceso.

async function ensureStorageAccess() {
  if (await document.hasStorageAccess()) {
    return true;
  }

  try {
    await document.requestStorageAccess();
    return true;
  } catch {
    return false;
  }
}

El acceso:

• puede requerir actividad del usuario,
• puede provocar un prompt,
• está sujeto a las políticas del navegador,
• puede ser denegado,
• requiere un contexto seguro,
• puede estar bloqueado por Permissions Policy.

No se debe tratar requestStorageAccess() como una forma automática de eludir la privacidad.

FedCM

Federated Credential Management API está destinada a los flujos de identidad federada sin depender de las third-party cookies ni de las redirecciones de navegación clásicas.

FedCM tiene sentido para:

• «Inicia sesión con un proveedor de identidad»,
• One Tap,
• la creación federada de cuentas,
• flujos en los que el navegador media entre el RP y el IdP.

No es un reemplazo universal de todas las cookies. No resuelve el estado de un widget, la analítica ni todas las funciones de OpenID Connect.

Particionado de Storage y Network State

Chrome sigue admitiendo el particionado del almacenamiento y del estado de red. El objetivo es limitar la posibilidad de vincular la actividad del usuario entre distintos sitios de nivel superior.

Private State Tokens

Private State Tokens se mantienen como un mecanismo que ayuda a transmitir señales de confianza limitadas sin el rastreo clásico del usuario entre sitios.

Otros elementos con soporte

El estado también menciona:

• bounce tracking mitigations,
• Fenced Frames,
• frame-ancestors,
• User-Agent Client Hints y la reducción de User-Agent.

No todos ellos son reemplazos de las third-party cookies. Son mecanismos independientes de la plataforma de privacidad y seguridad.

7. ¿Basta con SameSite=None; Secure?

No.

Es uno de los mitos más importantes.

Set-Cookie: session=abc;
  SameSite=None;
  Secure

significa que la cookie puede enviarse en un contexto cross-site, si el navegador permite las cookies de terceros no particionadas.

No significa que:

• el usuario no las haya bloqueado,
• Incognito vaya a admitirlas,
• Safari o Firefox se comporten igual que Chrome,
• Chrome Enterprise no vaya a aplicar una política,
• el iframe tenga Storage Access,
• un mecanismo de protección contra el tracking no vaya a limitar el acceso.

El código debería detectar la disponibilidad real.

8. ¿Cómo detectar la disponibilidad de cookies en un embed?

Chrome describe dos métodos básicos.

document.hasStorageAccess()

const hasAccess = await document.hasStorageAccess();

El método permite a un documento integrado comprobar si tiene acceso a cookies no particionadas.

Sec-Fetch-Storage-Access

Desde Chrome 133, las credentialed requests pueden incluir la cabecera:

Sec-Fetch-Storage-Access: active

Valores posibles:

• none,
• inactive,
• active.

Ejemplo del lado del servidor:

const storageAccess =
  request.headers.get("sec-fetch-storage-access");

if (storageAccess !== "active") {
  // Nie zakładaj dostępu do unpartitioned third-party cookies.
}

¿Qué no usar como única prueba?

navigator.cookieEnabled

Esta propiedad no indica de forma fiable si un iframe concreto tiene acceso a una third-party cookie concreta. Solo puede señalar el soporte general de cookies.

9. ¿Qué pasa con requestStorageAccessFor()?

No es lo mismo que:

document.requestStorageAccess()

requestStorageAccessFor() era una extensión relacionada con Related Website Sets que permitía a un sitio de nivel superior solicitar acceso en nombre de un recurso de un sitio relacionado.

Dado que Related Website Sets se está retirando, requestStorageAccessFor() también tiene el estado deprecate and remove.

MDN marca este método como deprecated y non-standard.

El requestStorageAccess() normal sigue siendo la vía compatible y multinavegador para los documentos integrados que requieren un estado no particionado.

10. Consecuencias para el inicio de sesión

Los más expuestos son los flujos que asumen que un IdP integrado en un iframe siempre leerá su propia cookie.

Posibles direcciones:

Caso	Mejor solución
inicio de sesión federado	FedCM o un flujo OAuth/OIDC top-level bien diseñado
sesión de la propia aplicación	first-party cookie en el dominio de la aplicación
embed que requiere acceso a una cuenta existente	Storage Access API con una UX clara
estado independiente de un widget	CHIPS
comunicación parent ↔ iframe	postMessage() con validación de origin
backend entre servicios propios	tokens y sesiones del lado del servidor, no cookies de rastreo cross-site

No se deben trasladar los tokens automáticamente a localStorage. Ese cambio no resuelve todos los problemas y puede agravar las consecuencias de un XSS.

11. Consecuencias para la analítica

El giro de Chrome significa que las third-party cookies no se han eliminado globalmente, pero siguen siendo una base de medición inestable.

Los datos pueden variar entre:

• usuarios que bloquean cookies,
• el modo normal y el privado,
• Chrome, Safari y Firefox,
• dispositivos gestionados por una organización,
• usuarios con extensiones de bloqueo,
• implementaciones con consentimiento y sin él.

Attribution Reporting API, que debía ser uno de los mecanismos de medición de Privacy Sandbox, se está retirando. Sin embargo, Google declara que sigue trabajando en un estándar de atribución interoperable dentro del proceso de estándares web.

Esto no es una garantía de un reemplazo listo para usar.

Un enfoque práctico incluye:

• first-party measurement,
• consentimiento explícito allí donde sea obligatorio,
• el modelado de los datos que faltan,
• la agregación,
• server-side collection con control de privacidad,
• la medición de las limitaciones y de la cobertura de los datos,
• evitar promesas de un rastreo completo del usuario entre sitios.

12. Consecuencias para la publicidad

Se están retirando los tres pilares centrales de la parte publicitaria de Privacy Sandbox:

• Topics,
• Protected Audience,
• Attribution Reporting.

A esto se suman Shared Storage, SelectURL, Private Aggregation y Aggregation Service.

Esto significa que no se debe iniciar una nueva implementación estratégica basada exclusivamente en estas API sin comprobar el estado actual y el plan de migración.

Esto no significa automáticamente que el sector vuelva a un único modelo estable de third-party-cookie-based advertising. La disponibilidad de las cookies sigue siendo fragmentaria, y el resto de navegadores aplican sus propios mecanismos de protección.

13. Consecuencias para los widgets y los servicios integrados

Un widget típico:

<iframe src="https://support.vendor.example/widget"></iframe>

puede requerir:

• reconocer la sesión,
• recordar la configuración,
• acceder a la cuenta del usuario,
• comunicarse con la página principal.

La elección de la solución debería depender del objetivo:

Estado solo para un único embedder

Usa CHIPS.

Acceso a una sesión existente, no particionada

Usa Storage Access API, con un fallback y un mensaje claro.

Inicio de sesión federado

Considera FedCM.

Estado que se puede transmitir de forma explícita

Transmite los datos mínimos desde el parent al iframe mediante postMessage() tras una validación estricta del origin.

14. Auditoría de las third-party cookies

Chrome recomienda una auditoría con DevTools y con Privacy Sandbox Analysis Tool.

Paso 1: inventaría las cookies

Para cada cookie, anota:

Campo	Ejemplo
nombre	widget_session
setter	chat.vendor.example
contexto	iframe
objetivo	estado de la conversación
¿requerido cross-site?	sí
¿requiere compartir entre sitios?	no
alternativa	CHIPS

Paso 2: encuentra SameSite=None

grep -R "SameSite=None" .

Esto no detectará las cookies creadas por scripts externos, por lo que también hay que usar DevTools y los registros de red.

Paso 3: prueba con el bloqueo

Chrome documenta el flag:

chrome://flags/#test-third-party-cookie-phaseout

y el arranque:

google-chrome --test-third-party-cookie-phaseout

La documentación sigue recomendando este modo para probar fallos con las cookies restringidas.

Paso 4: prueba rutas reales

• inicio de sesión,
• cierre de sesión,
• renovación del token,
• pago,
• chat,
• mapa,
• embedded media,
• consentimiento,
• analítica,
• cross-domain checkout,
• recuperación de cuenta.

Paso 5: prueba distintos navegadores

No limites la prueba a Chrome. El giro de Chrome no cambió las políticas de Safari y Firefox.

15. Ejemplo de estrategia progresiva de un widget

async function initializeWidget() {
  if ("hasStorageAccess" in document) {
    const hasAccess = await document.hasStorageAccess();

    if (hasAccess) {
      return startWithUnpartitionedSession();
    }
  }

  const partitionedSession = await tryPartitionedSession();

  if (partitionedSession) {
    return startWithPartitionedSession();
  }

  return startAnonymousMode();
}

Tras una acción consciente del usuario, se puede ofrecer el acceso:

button.addEventListener("click", async () => {
  try {
    await document.requestStorageAccess();
    location.reload();
  } catch {
    showManualLoginFallback();
  }
});

La lógica debe contemplar la denegación. El prompt no es una obligación del usuario.

16. ¿Qué no hacer?

No asumas que el giro de Chrome resolvió el problema

Las third-party cookies siguen sin ser una dependency predecible.

No migres todo al fingerprinting

Sustituir las cookies por una recopilación agresiva de señales del dispositivo no es una solución privacy-first.

No traslades automáticamente la sesión a localStorage

Esto puede aumentar el riesgo ante un XSS y no ofrece automáticamente la posibilidad de compartir datos cross-site.

No uses CHIPS para cross-site identity

CHIPS aísla deliberadamente la cookie según el top-level site.

No uses Storage Access API sin un fallback

El acceso puede ser rechazado.

No inicies un nuevo proyecto sobre una API en retirada

Comprueba el estado de Topics, Protected Audience, Attribution Reporting, Shared Storage y RWS antes de invertir.

No identifiques «deprecated» con «ya no funciona»

La deprecación y la eliminación son un proceso. Comprueba la versión de Chrome y Chrome Platform Status.

17. Arquitectura recomendada en 2026

Para una aplicación normal

• first-party session cookie,
• Secure,
• HttpOnly,
• un SameSite razonable,
• CSRF protection,
• sin dependencia de un iframe cross-site.

Para un widget

• CHIPS para el estado aislado por sitio,
• anonymous fallback,
• Storage Access solo para una función que requiera una sesión existente,
• postMessage() con validación de origin.

Para el inicio de sesión federado

• FedCM, si encaja con un flujo compatible,
• el redirect OAuth/OIDC estándar como fallback compatible,
• una first-party session al volver a la aplicación.

Para la analítica

• first-party collection,
• consentimiento y minimización de datos,
• informe explícito de la cobertura que falta,
• agregación en lugar de la promesa de una identificación completa cross-site.

18. Lista de comprobación para la migración

Inventario

• Lista de todas las cookies.
• Setter y domain definidos.
• Contexto first-party o third-party definido.
• Objetivo de negocio conocido.
• Propietario de la integración conocido.
• Consecuencias del bloqueo conocidas.
• Cookies sin usar eliminadas.

Seguridad de las cookies

• Secure en las cookies de sesión.
• HttpOnly allí donde JavaScript no necesita acceso.
• Domain mínimo.
• Path mínimo.
• SameSite adecuado.
• Tiempo de vida corto.
• Prefijo __Host- allí donde encaje.

Cross-site

• Sin asumir que SameSite=None garantiza el acceso.
• Detección de hasStorageAccess().
• Gestión de la denegación de requestStorageAccess().
• CHIPS para el estado aislado.
• FedCM para el inicio de sesión federado compatible.
• Fallback sin cookies de terceros.
• Prueba en Incognito.
• Prueba con el bloqueo de third-party cookies.

Privacy Sandbox

• Sin nueva dependencia de Topics.
• Sin nueva dependencia de Protected Audience.
• Plan de abandono de Attribution Reporting API.
• Plan de abandono de Shared Storage y SelectURL.
• Plan de abandono de Private Aggregation.
• Plan de abandono de Related Website Sets.
• Uso de requestStorageAccessFor() eliminado.
• Chrome release notes monitorizadas.

Pruebas

• Chrome normal.
• Chrome Incognito.
• Chrome con bloqueo manual.
• Safari.
• Firefox.
• Cuenta con sesión iniciada y sin ella.
• Usuario nuevo y existente.
• Embed en al menos dos top-level sites.
• Modo offline y errores de la API.
• Políticas de Chrome Enterprise, si afectan al producto.

19. Herramientas de POLPROG

Durante la auditoría conviene combinar el análisis de cookies con otras capas:

• Estado del sitio ayuda a encontrar problemas técnicos y de rendimiento.
• Inspector de cabeceras de seguridad permite comprobar CSP, HSTS y otras protecciones.
• Inspector de DNS y SSL verifica la capa de dominio y TLS.
• FlowTrace ayuda a seguir el flujo de la solicitud, la sesión y los datos entre el navegador, la CDN y el backend.
• En la base de conocimiento de POLPROG hay materiales sobre privacidad, seguridad y arquitectura web.

Veredicto

Chrome no ejecutó el antiguo plan de desactivación global de las third-party cookies. Los usuarios siguen teniendo elección, y el nuevo prompt específico no se implementó.

Sin embargo, esto no significa que las third-party cookies hayan recuperado el estatus de estándar estable sobre el que se pueda basar un producto con seguridad.

En 2026:

• una parte de los usuarios tiene las cookies bloqueadas,
• Incognito las bloquea de forma predeterminada,
• las políticas de organización pueden restringirlas,
• otros navegadores aplican sus propias reglas,
• el almacenamiento está cada vez más particionado,
• muchas de las API publicitarias de Privacy Sandbox se están retirando,
• las soluciones funcionales como CHIPS, Storage Access API y FedCM permanecen.

La mejor arquitectura no intenta adivinar la futura decisión de Chrome. Funciona correctamente con independencia de si las third-party cookies no particionadas están disponibles.