Muchas APIs de Privacy Sandbox están aumentando su disponibilidad general (DG) en la versión estable de Chrome para preparar la baja de las cookies de terceros a partir de 2024. Algunas de estas APIs ayudarán a preservar los casos de uso cruciales de cookies entre sitios, como CHIPS y la API que actualmente se conoce como First-Party Sets (FPS). En esta publicación, presentamos los Conjuntos de Sitios Web Relacionados (RWS), nuestro nuevo nombre para FPS que refleja mejor su propósito, y proporcionamos un repaso sobre los casos de uso clave junto con una actualización del límite de dominios de subconjunto asociado.
Preservación de los recorridos críticos del usuario
RWS está diseñado para minimizar las interrupciones en funciones específicas para los usuarios una vez que Chrome comienza a limitar el acceso a cookies de terceros de forma predeterminada. Nuestro objetivo es permitir que los usuarios naveguen en la Web con interrupciones mínimas sin dejar de cumplir los objetivos de privacidad de Privacy Sandbox. Para lograr este equilibrio, RWS se orienta a casos de uso específicos relacionados con la funcionalidad del sitio web:
- El caso de uso de ccTLD aborda fallas como el ejemplo de acceso registrado en nuestra herramienta de seguimiento pública. Esos casos suelen abordarse en el ecosistema a través de excepciones basadas en la heurística (consulta la ref. 1).
- El caso de uso del dominio de servicio aborda una práctica común de los desarrolladores para aislar funciones sensibles (como la compatibilidad con un flujo de autenticación) de los dominios para el usuario. Esos casos pueden abordarse en el ecosistema mediante excepciones específicas (consulta la ref. 2).
- El caso de uso de dominio asociado proporciona más flexibilidad para los tipos de dominios que pueden requerir acceso a cookies de terceros para los recorridos críticos del usuario (consulta la ref 3). Si bien los casos de uso de ccTLD y dominio de servicio emplean verificaciones técnicas estrictas basadas en características del dominio para minimizar el abuso, el dominio asociado usa un límite numérico. Obtén más información sobre este tema en la siguiente sección.
Se aumentó el límite de dominios asociados a cinco dominios
Anteriormente, Chrome proponía un límite numérico de tres dominios para el subconjunto asociado (más un dominio principal), de acuerdo con nuestro objetivo de prevenir el abuso generalizado del seguimiento. Los participantes de estándares de la Web nos comentaron que el límite era demasiado bajo para diferentes tipos de casos de uso.
Decidimos aumentar el límite de dominios asociados a cinco dominios (más un dominio principal), que sea más adecuado para la implementación más comparable de otro navegador importante (consulta la ref. 4). Esto tendrá efecto a partir de Chrome 117.
Dado que RWS no pretende ser una solución de anuncios, no estamos considerando los comentarios sobre cómo mejorar RWS para publicar mejor los casos de uso de anuncios. Para los casos de uso de anuncios, los desarrolladores deben explorar el uso de las APIs de Topics, Protected Audience y Attribution Reporting y proporcionar comentarios sobre ellas según corresponda.
Los usuarios pueden optar por casos de uso extendidos, más allá de cinco dominios asociados
Para las experiencias que tienen un impacto en los usuarios y que no son compatibles con este límite, Chrome está trabajando en un flujo de instrucciones para el usuario que también aprovecha la API de Storage Access (SAA), un estándar que adoptan otros navegadores. Para los casos de uso en los que se necesiten más de cinco dominios asociados, recomendamos que los desarrolladores evalúen la compatibilidad de los SAA en contextos que no sean de RWS. Estamos siguiendo el proceso de lanzamiento de Blink por separado para esta función, que se lanzará en el escritorio de Chrome a partir de Chrome 117.
Próximos pasos
Agradecemos los comentarios sobre el ecosistema que nos ayudaron a diseñar la API hasta ahora. Invertimos en RWS como un método para proporcionar a los desarrolladores previsibilidad, control y agencia a la hora de preservar la experiencia del usuario final de los sitios web que crean. Nos entusiasma ver cómo los desarrolladores adoptan y usan RWS a medida que avanzamos. El proceso de envío se encuentra activo, y la herramienta generadora de JSON de RWS es un excelente punto de partida para ayudarte con las entregas.
Sigue la conversación de Intent to Ship para hacer un seguimiento del progreso y consulta estos materiales para obtener orientación sobre la implementación.
Referencias
- Existe un acuerdo general entre los navegadores en cuanto a que estos casos de uso de cookies entre sitios son necesarios, pero adoptaron diferentes enfoques para habilitarlos. Firefox (código) y Safari (código) implementaron la heurística de ventanas emergentes que soluciona la falla observada, por ejemplo, en el flujo de acceso de Nintendo.
- También hay varios ejemplos en los que los navegadores fijan excepciones de código para minimizar las interrupciones para los usuarios. Firefox otorga acceso de almacenamiento en los flujos de redireccionamiento entre Microsoft Teams y login.microsoftonline.us.
- Firefox proporciona una “corrector de compatibilidad” que llamará a requestStorageAccessForOrigin en nombre de facebook.com cuando el usuario acceda a instagram.com. También se puede ver un ejemplo de agrupación de sitios en las excepciones codificadas de Safari para agrupar mensajes de acceso al almacenamiento de varios dominios.
- Firefox otorga automáticamente las primeras 5 llamadas requestStorageAccess realizadas por un sitio de terceros (código) que el usuario visitó antes. En Chrome, los primeros cinco dominios enumerados en el subconjunto asociado, además del dominio principal del mismo conjunto, tendrán acceso automático a las cookies de terceros mediante RWS.