Solicita un tiempo de migración adicional con la prueba de baja de cookies de terceros

Para facilitar las pruebas, Chrome restringió las cookies de terceros de forma predeterminada para el 1% de los usuarios de Chrome. Chrome planea aumentar las restricciones de las cookies de terceros al 100% de los usuarios a partir de principios de 2025, sujeto a resolver cualquier inquietud pendiente sobre la competencia de la Autoridad de Competencia y Mercados (CMA) del Reino Unido. Para facilitar la transición a través del proceso de baja, ofrecemos una prueba de baja de terceros que permite que los sitios y servicios incorporados soliciten más tiempo para migrar de dependencias de cookies de terceros en casos de uso no publicitarios.

El registro para esta prueba de baja comenzó la semana del 4 de diciembre de 2023. La prueba de baja comenzará en enero de 2024 y finalizará el 27 de diciembre de 2024. Se espera que los desarrolladores realicen los cambios y los planes necesarios antes de la fecha de finalización de la prueba.

Sabemos que hay un breve período entre el momento en que se abren los registros de prueba y cuando el período de pruebas facilitadas de Chrome comienza a bloquear el 1% de las cookies. Para abordar estas limitaciones de tiempo, Chrome proporciona un período de gracia para los orígenes participantes mientras trabajan en la implementación de los tokens de prueba de baja. Durante el período de gracia, que durará hasta el 30 de junio de 2024, los orígenes registrados para la prueba de baja tendrán acceso a cookies de terceros en Chrome, incluso si aún no implementaron sus tokens. El propósito de este período de gracia es evitar problemas de compatibilidad web durante la fase de transición. Los orígenes participantes deben implementar tokens de prueba de baja antes de que finalice el período de gracia.

Pruebas de baja

Las pruebas de baja son una opción estándar que proporciona Chrome para permitir que los sitios se registren y obtengan tiempo adicional para migrar de la funcionalidad heredada que se quitará. Una prueba de baja es un tipo de prueba de origen que permite volver a habilitar una función de forma temporal.

Esta prueba es para las incorporaciones y los servicios que establecen cookies de terceros y que cumplen con nuestros criterios de elegibilidad que se describen en la siguiente sección. En otras palabras, si tu incorporación o servicio es de terceros, puedes registrarte en la prueba de baja para volver a habilitar temporalmente tus cookies de terceros en todos los contextos en los que se incluya tu incorporación o servicio. La prueba solo se aplica al origen incorporado registrado y no a todo el dominio del sitio de nivel superior que visitan los usuarios.

Un ejemplo de iframe de terceros o entre sitios que muestra una página incorporada de https://embed.example/iframe.html en https://top.example y un ejemplo de secuencia de comandos de terceros/entre sitios que muestra una secuencia de comandos de https://third-party.example/script.js incluida en https://top.example

Los sitios de nivel superior que utilizan terceros que dependen de cookies no necesitan registrarse para esta prueba de baja. Debes auditar las cookies de terceros que se usan en tu sitio y comunicarte con tus proveedores externos a fin de asegurarte de que estén preparados para la baja.

Criterios de elegibilidad y proceso de revisión

Esta prueba de baja difiere de las pruebas anteriores, ya que se introduce un proceso de revisión y aprobación para la participación. Esto permite lograr un equilibrio entre mejorar la privacidad de las personas en la Web y, al mismo tiempo, permitir que los servicios de los que dependen soliciten tiempo adicional para migrar si es necesario.

Los principios que rigen esta prueba de baja son los siguientes:

  • Preservación de la funcionalidad crítica para el usuario: esta prueba de baja está dirigida a proveedores externos que demuestran fallas funcionales en los recorridos de los usuarios.
  • Limitar el seguimiento de usuarios: La prueba de baja no está diseñada para admitir el seguimiento entre sitios con fines publicitarios, por lo que las incorporaciones y los servicios de terceros que se usan para publicidad no son aptos.

La inelegibilidad de los casos de uso de publicidad también ayudará a garantizar que la prueba de baja no interfiera en las pruebas de la industria planificadas para principios de 2024, según lo describe la Autoridad de Competencia y Mercados. Esto incluye los dominios relacionados con la publicidad que también se usan con fines no publicitarios.

Inicialmente, Chrome trabajará con Disconnect.me, un líder de la industria en privacidad en Internet, e implementará las listas de protección de los rastreadores de Desconectar para identificar las secuencias de comandos y los dominios clasificados como publicidad. Otros navegadores ya utilizan esta función con fines similares en la Web.

Aplicaremos el siguiente proceso para las solicitudes de registro:

  • Si el origen de terceros coincide con un dominio de publicidad conocido, incluso si el origen coincide con una entrada de la lista publicitaria Desconectar, se rechazará la solicitud de registro. En general, las entradas de la lista coincidirán con todos los subdominios debajo del origen especificado. Sin embargo, algunas entradas incluyen un elemento de ruta de acceso. Estas entradas más específicas coincidirán con el origen determinado, pero no con los subdominios.
  • Se deben proporcionar los pasos para reproducir una experiencia negativa para el usuario. En particular, esta debería ser una experiencia para el usuario que opera el dispositivo en el que se almacena la cookie y no para un usuario que realice un análisis de datos posterior. Si no podemos validar una experiencia del usuario dañada, se rechazará la solicitud de registro.
  • De lo contrario, se aprobará la solicitud de registro.
  • Si indicas que un origen es "similar" a una aplicación aprobada previamente, proporciona una descripción de la relación entre los orígenes.

Planeamos ofrecer un proceso de apelación si el origen del registro cree que más información podría aclarar una decisión de revisión. El registrante puede solicitar una apelación si se vuelve a enviar la solicitud en la consola de prueba de origen. El objetivo de las apelaciones es sobre solicitudes que se rechazaron debido a la falta de la información solicitada (error conocido de fallas o pasos para reproducir la falla) o si el origen del registro cree que tener más información podría satisfacer estos requisitos para aclarar una decisión de revisión.

También estamos aprobando casos de uso antiabuso y antifraude en los que podemos encontrar pruebas que lo corroboren. Agradecemos los comentarios sobre cómo evaluar mejor estos casos de uso.

Solicita la prueba de baja

Incluye los pasos de reproducción que nuestro equipo puede usar para verificar la falla funcional. Como alternativa, si es más fácil o si tu funcionalidad está restringida por el acceso o algún aspecto similar, puedes proporcionar un vínculo a una grabación de los pasos para reproducir el problema mediante la grabadora de Herramientas para desarrolladores de Chrome.

  1. Navega a Prueba de baja de cookies de terceros y haz clic en “Registrar”.
  2. En "Origen web", proporciona el origen que publica la página o las secuencias de comandos incorporadas.
  3. La opción “Coincidencia de terceros” dependerá de cómo debas proporcionar el token. Las opciones se explican con más detalle en Agrega el token de prueba.
    • Si proporcionas el token en un encabezado HTTP o una metaetiqueta en tus propias páginas incorporadas, no marques la opción "Coincidencias de terceros".
    • Si quieres insertar el token con JavaScript en otro sitio, debes marcar la opción “Coincidencia de terceros”.
    • Si necesitas hacer ambos, tendrás que realizar registros separados.
  4. Si alojas contenido entre sitios en varios subdominios, marca la opción "Necesito un token para que coincida con todos los subdominios del origen".
    • Si seleccionas esta opción, el token proporcionado coincidirá con el dominio registrado y los dominios inferiores. Por ejemplo: registra https://example.com para que coincida con example.com, www.example.com, foo.example.com y bar.foo.example.com. Si registras https://www.example.com, tu token coincidirá con www.example.com y foo.www.example.com, pero no con foo.example.com.
    • Los tokens coincidirán con varios subdominios de manera similar a la coincidencia de comodines, por ejemplo, *.<domain>. Solicita un token para example.com y se podrá proporcionar en a.example.com, b.example.com. El acceso a cookies de terceros solo se volverá a habilitar para los orígenes específicos que proporcionan el token, no para todos los subdominios. Consulta ¿Qué cookies se habilitan cuando la coincidencia de subdominios está habilitada?
    • Si alojas contenido entre sitios de orígenes distintos que no están en el mismo dominio, deberás realizar registros separados para cada origen.
  5. Marca todas las casillas para confirmar todas las condiciones incluidas en "Divulgación y confirmación".
  6. Envía la solicitud.
  7. Necesitamos información adicional para procesar tu solicitud. Recibirás una notificación por correo electrónico con un ticket generado automáticamente en el que se te solicitará lo siguiente:
    • La cantidad de subdominios vinculados al origen solicitado
    • El ID o vínculo de los errores asociados del repositorio de fallas de terceros que informaste a goo.gle/report-3pc-broken.
    • Cualquier información o contexto adicional sobre la falla o el caso de uso que desees que consideremos. (En los casos de una apelación para una solicitud de prueba rechazada, explica por qué y cómo tu origen cumple con los criterios descritos para esta prueba).

Una vez que se envíe, revisaremos tu solicitud y te notificaremos cuando se complete la revisión o si se necesita información adicional, y si se aprobó o rechazó. También recibirás el estado y la justificación del resultado. Si se aprueba, puedes proceder a proporcionar el token de prueba según sea necesario. Si se rechaza, puedes seguir las instrucciones que se indican en el ticket de solicitud.

Cómo configurar marcas para realizar pruebas

En este momento, te recomendamos configurar las siguientes marcas, disponibles en Chrome 123, para permitir pruebas eficaces. Esta combinación de parámetros de configuración de marcas ayudará a replicar la experiencia del usuario del modo B.

  • chrome://flags/#third-party-cookie-deprecation-trial → enabled
    Este es el valor predeterminado. Permitir la participación en la prueba

  • chrome://flags/#tracking-protection-3pcd → enabled
    Activa la Protección contra seguimiento: muestra la IU del ícono del ojo en la barra de direcciones para permitir al usuario habilitar temporalmente las cookies de terceros para un sitio y proporciona chrome://settings/trackingProtection en lugar de chrome://settings/cookies.

  • chrome://flags/#tpcd-metadata-grants → disabled
    Permite que Chrome se comporte como si el período de gracia no estuviera vigente. Se puede usar para verificar que tu sitio haya implementado correctamente los tokens de prueba de baja antes de que finalice el período de gracia (para un sitio que está sujeto a ese período).

  • chrome://flags/#tpcd-heuristics-grants → disabled
    No permitas las mitigaciones basadas en heurística. Esto puede ser útil para probar que otras correcciones a largo plazo (sin cookies de terceros) funcionen como se espera sin mitigaciones heurísticas y que la participación en las pruebas de baja funcione según lo esperado.

Si necesitas probar de forma manual que el período de gracia funcione como se espera, antes de probar la implementación, deberás enable chrome://flags/#tpcd-metadata-grants en lugar de inhabilitarlo.

Agrega el token de prueba

Consulta Cómo comenzar con las pruebas de origen, Pruebas de origen de terceros y Cómo solucionar problemas con las pruebas de origen de Chrome para obtener más detalles.

Debes incluir el token de prueba en todas las respuestas de la página en las que desees establecer o enviar cookies en un contexto de varios sitios.

Proporciona el token en un encabezado HTTP

Si necesitas volver a habilitar las cookies de terceros para una página incorporada en un iframe entre sitios, puedes incluir el encabezado HTTP Origin-Trial en la respuesta de la página:

Origin-Trial: TOKEN_GOES_HERE

Esto corresponde a no habilitar la “Coincidencia de terceros” en tu registro de prueba de baja, ya que proporcionas el token en tus propias respuestas.

Esa respuesta de la página puede establecer una cookie. Las solicitudes posteriores a ese mismo origen, como los subrecursos de esa página o las navegaciones desde esa página, incluirán las cookies entre sitios del sitio y también pueden establecer cookies.

Diagrama en el que se reitera el token que se proporciona en la respuesta de la página.

Si necesitas que las cookies entre sitios estén en la primera solicitud a tu origen en la sesión, también puedes usar el encabezado Critical-Origin-Trial que pasa el nombre de prueba:

Critical-Origin-Trial: Tpcd

Esto provocará que el navegador vuelva a intentar la solicitud con las cookies de terceros habilitadas.

La prueba de baja se proporciona como una prueba persistente, lo que significa que, una vez que el navegador reciba el token, el comportamiento de la prueba se aplicará hasta que se cargue un iframe sin un token de prueba presente. Se recomienda enviar el token de prueba en cada carga de iframe de forma coherente.

Proporciona el token en una metaetiqueta

Dentro de una página, puedes usar una metaetiqueta en el documento <head>:

<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">

La metaetiqueta habilitará las cookies entre sitios para solicitudes posteriores o JavaScript en la página, pero deberás usar el encabezado HTTP si necesitas que se envíen cookies existentes en la solicitud inicial.

Cómo insertar el token con JavaScript

Si necesitas habilitar cookies de terceros para tu origen antes o sin publicar tu propia solicitud de página, por ejemplo, si se requieren cookies en una solicitud de imagen entre sitios o si deseas crear un iframe con JavaScript, puedes insertar el token en el sitio de nivel superior mediante JavaScript:

const otMeta = document.createElement('meta');
otMeta.httpEquiv = 'origin-trial';
otMeta.content = 'TOKEN_GOES_HERE';
document.head.append(otMeta);

Para permitirlo, debes habilitar la opción "Coincidencia de terceros" en tu registro de prueba de baja, ya que insertas el token para tu origen (el de terceros) en un sitio diferente.

Un token con la coincidencia de terceros habilitada puede insertarse en cualquier origen, incluido el tuyo, y funcionará.

Diagrama en el que se reitera que la secuencia de comandos de terceros inserta el token en la página superior.

Una prueba persistente seguirá inhabilitada si se carga un iframe sin el token de prueba. Debes proporcionar de forma coherente el token de prueba en todos los iframes cargados, incluso si la prueba se habilitó originalmente con una carga de secuencia de comandos de terceros.

Valida tu token

Abre las Herramientas para desarrolladores de Chrome, selecciona el panel Aplicación y expande la pestaña Frames. Si seleccionas cualquier fotograma, se mostrará la sección Pruebas de origen si se proporcionaron tokens. Si insertas el token en el sitio de nivel superior, lo verás en la entrada "superior". De lo contrario, debes seleccionar el marco que corresponda a tu página incorporada.

Si proporcionaste un token en la sección Pruebas de origen, deberías ver una entrada para "Tpcd". Si se habilitó correctamente la función, verás el estado verde “Habilitada”. De lo contrario, verás un estado de error rojo y podrás expandir la entrada para ver el problema.

Solo se necesita un token válido para activar la prueba de baja. Si te registraste para la coincidencia propia y de terceros, no es un problema si proporcionas ambos tokens en la página. Por ejemplo, si tienes una sola página que puede incorporarse de diferentes maneras, no necesitas elegir un token de forma dinámica: puedes proporcionar ambos y la prueba se habilitará en cualquiera de los contextos.

¿Qué cookies están habilitadas?

La prueba de baja solo habilita cookies de terceros para el origen registrado para la prueba. Después de la activación, las cookies de terceros estarán presentes en las solicitudes de iframe y subrecursos para ese origen. Las cookies de terceros también estarán disponibles con document.cookie en iframes con ese origen.

Los atributos de la cookie Domain no se consideran aquí. Solo se considera el origen de la URL de solicitud. Una vez que se determina que una solicitud tiene cookies de terceros, todas estas se adjuntan con normalidad, incluso si el dominio de una cookie es más permisivo.

Por ejemplo, si https://one.test.example está registrado y su token se proporciona en un iframe https://one.test.example, haz lo siguiente:

  • https://one.test.example/image.jpg recibirá las cookies establecidas de https://one.test.example
  • https://one.test.example/image.jpg recibirá cookies establecidas de otros orígenes con Domain=.test.example
  • Las solicitudes https://test.example/image.jpg o https://two.test.example/image.jpg no recibirán cookies de terceros porque no son del mismo origen.

¿Qué cookies se habilitan cuando está habilitada la coincidencia de subdominios?

La opción "hacer coincidir todos los subdominios" permite usar un solo token en el origen del registro o en cualquier origen que tenga un subdominio más específico. Se puede usar un token para https://test.example con coincidencia de subdominio a fin de activar la prueba con iframes https://test.example, https://one.test.example o https//two.test.example y cargas de secuencias de comandos de terceros.

Además, cuando la coincidencia de subdominios esté habilitada, las cookies de terceros también estarán disponibles en solicitudes y en iframes asociados con los subdominios correspondientes. Por ejemplo, si https://test.example usa coincidencias de subdominios, las solicitudes de subrecursos como https://cdn.one.test.example/image.jpg recibirán cookies de terceros.

La desactivación de la prueba no tiene en cuenta la coincidencia de subdominios. Para desactivar la prueba, se debe cargar un iframe que coincida exactamente con el origen en el registro sin un token. Por lo tanto, un registro de https://test.example con coincidencia de subdominio solo se puede inhabilitar con un iframe https://test.example sin un token. Esto puede cambiar en el futuro. Por eso, te recomendamos que proporciones un token en todos los iframes de submarcos cuando quieras habilitar la prueba y quites tokens de todos los iframes cuando quieras desactivar la prueba.

Solución de problemas relacionados con los tokens de prueba

Soluciona problemas de las pruebas de origen de Chrome proporciona una lista de tareas completa para ayudarte a depurar el registro y la implementación de tokens de prueba.

Esta prueba te ofrece algunos problemas frecuentes:

  • Si se selecciona la opción "Necesito un token para que coincida con todos los subdominios del origen", el token proporcionado coincidirá con el dominio registrado y los dominios inferiores. Por ejemplo: registra https://example.com para que coincida con example.com, www.example.com, foo.example.com y bar.foo.example.com. Si registras https://www.example.com, tu token coincidirá con www.example.com y foo.www.example.com, pero no con foo.example.com.
  • Los sitios o servicios de terceros incorporados en tu sitio web deben registrarse para la prueba. No debes realizar una solicitud para un dominio que no controlas o te pertenece.
  • Si cometes un error en el registro de la prueba de origen, debes realizar un registro nuevo para corregir los errores y obtener un token nuevo.

Preguntas frecuentes

  1. ¿Qué sucede si tengo preguntas sobre la lista Disconnect.me?
  2. ¿Puedo registrarme en la prueba de baja si mi dominio se usa con fines publicitarios y no publicitarios?
    • Las incorporaciones y los servicios de terceros que se usan con fines publicitarios no son aptos para la prueba de baja, por los motivos que se explicaron anteriormente en este blog. Esto incluye los dominios relacionados con la publicidad que también se usan con fines no publicitarios. Para obtener más información, consulta la sección Criterios de elegibilidad y proceso de revisión.
  3. ¿Los sitios podrán ver cuáles de sus socios se inscribieron en la prueba de baja? ¿Podrán limitar el registro entre sus socios?
    • Sí, los sitios pueden ver qué incorporaciones y servicios dependen de un token de prueba de baja. Para ello, deben ver la información del token en el panel de la aplicación de Herramientas para desarrolladores de Chrome. Para obtener más información, consulta Cómo solucionar problemas relacionados con pruebas de origen de Chrome.
    • Los sitios de nivel superior no podrán limitar el registro entre sus socios ni las incorporaciones y los servicios de sus páginas. Comunícate con el socio si lo deseas.
  4. ¿En qué se diferencia esta prueba de otras, como la prueba de origen de reducción de usuario-agente?
    • La diferencia principal en la que se diferencia esta prueba de baja es el nuevo proceso de registro que implica cumplir con los criterios de participación, así como con la IU y las páginas nuevas en la consola de prueba de origen.
    • La segunda diferencia es que los sitios incorporados de terceros son los únicos que tienen que resolver la cantidad máxima de problemas de compatibilidad web entre varios clientes de sitios o servicios.
  5. ¿Habrá una prueba de baja de cookies de terceros en la que los sitios de nivel superior puedan inscribirse para habilitar las 3PC en todo su sitio?
  6. ¿Cuánto tiempo tardará la revisión de mi solicitud de prueba de baja? ¿Dónde puedo consultar el estado de mi solicitud?
    • Los tiempos de respuesta pueden variar, pero te recomendamos que comiences el proceso de registro lo antes posible para asegurarte de tener todo listo antes de que las cookies de terceros dejen de estar disponibles del 1% a principios del primer trimestre. Si no recibes ninguna respuesta en un plazo de 1 o 2 semanas después de enviar el registro, comunícate con 3pcd-deprecationtrial@google.com.
    • Conversación sobre la conversación abierta, el estado de la decisión y los motivos.
  7. Se aprobó nuestro registro de prueba de baja y, además, implementamos un token de prueba como se recomienda. Sin embargo, la prueba de baja no funciona como se espera. ¿Qué deberíamos hacer?