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 cookies de terceros para el 100% de los usuarios a partir del tercer trimestre de 2024, sujeto a que se aborden las inquietudes restantes sobre la competencia de la Competition and Markets Authority (CMA) del Reino Unido. Para facilitar la transición durante el proceso de baja, ofrecemos una prueba de baja de terceros que permite que los sitios y servicios incorporados soliciten tiempo adicional para migrar de las dependencias de cookies de terceros en casos de uso que no son de publicidad.

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 a más tardar en la fecha de finalización de la prueba.

Reconocemos que hay un período breve entre el momento en que se abren los registros de prueba de baja y el momento en que comienza el período de pruebas facilitadas por Chrome, en el que se bloquea 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 para implementar tokens de prueba de baja. Durante el período de gracia, que se extenderá hasta el 30 de junio de 2024, los orígenes registrados para la prueba de baja tendrán acceso a las cookies de terceros en Chrome, incluso si aún no implementaron sus tokens. El objetivo 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 Chrome proporciona 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 temporalmente.

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 incluye tu incorporación o servicio. La prueba solo se aplica al origen incorporado registrado y no a todo el dominio de nivel superior del sitio 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 o 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 usan 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 para asegurarte de que estén preparados para la baja.

Criterios de elegibilidad y proceso de revisión

Esta prueba de baja difiere de las anteriores, ya que se introdujo un proceso de revisión y aprobación para participar. 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 guían esta prueba de baja son los siguientes:

  • Preservar la funcionalidad esencial para el usuario: Esta prueba de baja está destinada a proveedores externos que demuestren una interrupción funcional en los recorridos de los usuarios.
  • Limitación del seguimiento de usuarios: La prueba de baja no está diseñada para admitir el seguimiento entre sitios con fines publicitarios y, por lo tanto, las incorporaciones y los servicios de terceros que se usan para la publicidad no son aptos.

La inelegibilidad de los casos de uso publicitarios también ayudará a garantizar que la prueba de baja no interfiera con las pruebas de la industria planificadas para principios de 2024, como lo describe la Competition and Markets Authority. Esto incluye los dominios relacionados con la publicidad que también se usan con fines no publicitarios.

En un principio, Chrome trabajará con Disconnect.me, un líder de la industria en privacidad en Internet, e implementará las listas de protección contra seguimiento de Disconnect para identificar las secuencias de comandos y los dominios categorizados como publicidad. Otros navegadores ya usan la función Disconnect con fines similares en la Web.

Aplicaremos el siguiente proceso para las solicitudes de registro:

  • Si el origen de terceros coincide con un dominio publicitario conocido, incluso si coincide con una entrada de la lista publicitaria de Disconnect, se rechaza 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 del usuario defectuosa. En particular, esta debe 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 posterior de los datos. Si no podemos validar una experiencia del usuario defectuosa, 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 con anterioridad, proporciona una descripción de la relación entre los orígenes.

Tenemos previsto ofrecer un proceso de apelación si el origen del registro considera que se necesita más información para aclarar una decisión de revisión. El registrante puede solicitar una apelación reenviando la solicitud en la consola de prueba de origen. El objetivo de las apelaciones es para las solicitudes que se rechazaron debido a que falta la información solicitada (errores de falla conocidos o pasos de reproducción de fallas) o si el origen de registro considera que más información podría satisfacer estos requisitos para aclarar una decisión de revisión.

También aprobamos casos de uso contra el abuso y el fraude cuando podemos encontrar pruebas que los corroboren. Aceptamos 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 algo similar, puedes proporcionar un vínculo a una grabación de los pasos para reproducir el problema con el Grabador 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 entrega tu página o secuencia 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 Cómo agregar el token de prueba.
    • Si proporcionas el token en un encabezado HTTP o una metaetiqueta en tus propias páginas incorporadas, no marques "Coincidencia de terceros".
    • Si inyectas el token con JavaScript en un sitio diferente, debes marcar "Coincidencia de terceros".
    • Si necesitas hacer ambas cosas, deberás realizar registros independientes.
  4. Si alojas contenido entre sitios en varios subdominios, marca la opción "Necesito un token que coincida con todos los subdominios del origen".
    • Si seleccionas esta opción, el token proporcionado coincidirá con el dominio registrado y los dominios debajo de él. 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, p.ej., *.<domain>. Solicita un token para example.com y se puede proporcionar en a.example.com, b.example.com. El acceso a las 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 se habilita la coincidencia de subdominios?.
    • Si alojas contenido entre sitios en orígenes separados que no están en el mismo dominio, deberás realizar registros independientes para cada origen.
  5. Marca todas las casillas para confirmar todas las condiciones incluidas en la sección "Divulgación y acuse de recibo".
  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 a tu origen solicitado
    • El ID o el vínculo del error del repositorio de fallas de terceros asociado que informaste anteriormente en goo.gle/report-3pc-broken
    • Cualquier información o contexto adicional sobre la falla o el caso de uso que quieras que tengamos en cuenta (en el caso de una apelación por una solicitud de prueba rechazada, explica por qué o cómo tu origen cumple con los criterios descritos para esta prueba).

Una vez que la envíes, 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 el motivo del resultado. Si se aprueba, puedes continuar y 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 establecer marcas para pruebas

Por el momento, te recomendamos que configures 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
    Esta es la configuración predeterminada. Permitir la participación en la prueba

  • chrome://flags/#tracking-protection-3pcd → enabled
    Habilita la Protección contra seguimiento: Muestra la IU del ícono de ojo en la barra de direcciones para permitir que el usuario habilite 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
    Hace que Chrome se comporte como si el período de gracia no estuviera vigente. Puedes usar esta función 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 este período).

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

Si necesitas probar manualmente que el período de gracia funciona según lo esperado, antes de probar la implementación, deberás habilitar chrome://flags/#tpcd-metadata-grants en lugar de inhabilitarlo.

Agrega el token de prueba

Para obtener más información, consulta Cómo comenzar a usar las pruebas de origen, Pruebas de origen de terceros y Cómo solucionar problemas de las pruebas de origen de Chrome.

Debes incluir el token de prueba en todas las respuestas de página en las que deseas configurar 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 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 para pasar el nombre de la prueba:

Critical-Origin-Trial: Tpcd

Esto hará 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 haya recibido el token, se aplicará el comportamiento de la prueba 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 las cookies existentes en la solicitud inicial.

Cómo insertar el token con JavaScript

Si necesitas habilitar cookies de terceros para tu origen antes de publicar tu propia solicitud de página o sin hacerlo, 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 con JavaScript:

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

Para permitir esto, debes habilitar la "Coincidencia de terceros" en el registro de prueba de baja, ya que estás insertando el token de tu origen (el tercero) en un sitio diferente.

Se puede insertar un token con la coincidencia de terceros habilitada en cualquier origen, incluso en 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 se inhabilitará si se carga un iframe sin el token de prueba. Debes proporcionar el token de prueba de forma coherente en todos los iframes cargados, incluso si la prueba se habilitó con una carga de secuencia de comandos de terceros originalmente.

Valida tu token

Abre DevTools y navega a la pestaña Application. Expande el árbol Frames en la navegación de la izquierda. Si seleccionas cualquier fotograma, se mostrará una sección de Origin Trials si se proporcionaron tokens. Si insertas el token en el sitio de nivel superior, lo verás en la entrada "top". De lo contrario, debes seleccionar el marco que corresponde a tu página incorporada.

En la sección Origin Trials, si proporcionaste un token, deberías ver una entrada para "Tpcd". Si la función se habilitó correctamente, verás el estado "Habilitado" en verde. De lo contrario, verás un estado de error en 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 se puede incorporar de diferentes maneras, no necesitas elegir un token de forma dinámica, solo puedes proporcionar ambos, y la prueba se habilitará en cualquier contexto.

¿Qué cookies están habilitadas?

La prueba de baja solo habilita las 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 a ese origen. Las cookies de terceros también estarán disponibles con document.cookie en iframes con ese origen.

Aquí no se consideran los atributos Domain de la cookie. Solo se considera el origen de la URL de la solicitud. Una vez que se determine que una solicitud tiene cookies de terceros, todas estas cookies se adjuntarán como de costumbre, 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:

  • https://one.test.example/image.jpg recibirá las cookies configuradas desde https://one.test.example.
  • https://one.test.example/image.jpg recibirá cookies configuradas desde 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 se habilita la coincidencia de subdominios?

La opción "hacer coincidir todos los subdominios" permite usar un solo token en el origen de registro o en cualquier origen con un subdominio más específico. Se puede usar un token para https://test.example con coincidencia de subdominios para 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 se habilita la coincidencia de subdominios, las cookies de terceros también estarán disponibles en las solicitudes y en los iframes asociados con los subdominios correspondientes. Por ejemplo, si https://test.example usa la coincidencia 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 de https://test.example sin un token. Es posible que esto cambie en el futuro, por lo que te recomendamos que proporciones un token en todos los iframes de submarcos cuando quieras habilitar la prueba y que quites los tokens de todos los iframes cuando quieras desactivar la prueba.

Solución de problemas relacionados con los tokens de prueba

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

Estos son algunos problemas frecuentes que puedes encontrar con esta prueba:

  • Si seleccionas la opción "Necesito un token que coincida con todos los subdominios del origen", el token proporcionado coincidirá con el dominio registrado y los dominios debajo de él. 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 solicitar un dominio que no controles o que no te pertenezca.
  • Si te equivocas 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 de Disconnect.me?
  2. ¿Puedo registrarme en la prueba de baja si mi dominio se usa con fines publicitarios y no publicitarios?
    • Los servicios y las incorporaciones de terceros que se usan para la publicidad 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 Proceso de revisión y criterios de elegibilidad.
  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 las Herramientas para desarrolladores de Chrome. Para obtener más información, consulta Cómo solucionar problemas de 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 en su página. 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 User-Agent?
    • La principal diferencia de esta prueba de baja es el nuevo proceso de registro que implica cumplir con los criterios de participación y la nueva IU o las páginas de la consola de pruebas de origen.
    • La segunda diferencia es que es exclusivo para sitios incorporados de terceros para resolver la mayor cantidad posible de problemas de compatibilidad web en varios sitios o clientes de servicios.
  5. ¿Habrá una prueba de baja de cookies propias para la baja de cookies de terceros en la que los sitios de nivel superior puedan inscribirse para habilitar las cookies de terceros en todo su sitio?
  6. ¿Cuánto tiempo tardará la revisión de mi solicitud de prueba de baja? ¿Dónde puedo verificar el estado de mi postulación?
    • Los tiempos de respuesta pueden variar. Te recomendamos que comiences el proceso de registro lo antes posible para asegurarte de estar listo antes de que se elimine el 1% de las cookies de terceros a principios del primer trimestre. Si no recibes ninguna respuesta en un plazo de 1 a 2 semanas después de enviar el registro, comunícate con [email protected].
    • Subproceso de errores para la conversación abierta, el estado de la decisión y la justificación.
  7. Se aprobó nuestro registro de prueba de baja y, como se recomendó, implementamos un token de prueba. Sin embargo, la prueba de baja no funciona como se esperaba. ¿Qué deberíamos hacer?