Los conjuntos propios (FPS) están diseñados para admitir la experiencia de navegación web de los usuarios después de la baja de las cookies de terceros en Chrome. La propuesta evolucionó significativamente en los foros web abiertos durante la incubación de FPS, primero en el Grupo de la Comunidad de privacidad de W3C y, ahora, en el Grupo de la comunidad de Web Incubator.
En esta entrada de blog, recapitularemos el proceso de evolución, destacaremos los cambios clave y analizaremos por qué creemos que esos cambios mejoran la privacidad en la Web y, al mismo tiempo, continúan apoyando el ecosistema.
Información general
A menudo, los sitios dependen del acceso a sus cookies en un contexto de terceros para ofrecer a los usuarios experiencias fluidas y personalizadas. Además de las APIs de anuncios que preservan la privacidad (Topics, API de Protected Audience y Attribution), el equipo de Chrome quería comprender el alcance de las situaciones en las que se usaban cookies de terceros, más allá de la personalización de anuncios o la medición, para proporcionar experiencias de navegación mejoradas a los usuarios.
Descubrimos que las organizaciones pueden depender de cookies de terceros porque su arquitectura web está diseñada para usar varios dominios. Por ejemplo, una organización puede tener un dominio para su blog de senderismo y otro para su tienda de campamento, y desea admitir los recorridos de los usuarios en esos sitios. Una organización también puede mantener varios dominios de códigos de país con una infraestructura compartida para su servicio web. Para casos como estos, nos propusimos crear una solución que se alineara con las necesidades de esas organizaciones y, al mismo tiempo, preservar las expectativas de los usuarios respecto de su privacidad en la Web.
Donde comenzamos
Dado que el navegador actualmente usa el límite a nivel del sitio para interpretar "propio" en comparación con "terceros", para dar cuenta del rango de dominios que podría administrar una organización, parecía apropiado reemplazar este límite técnico por una definición más matizada.
En 2021, Chrome propuso inicialmente el atributo de cookie SameParty para
conjuntos propios a fin de que los sitios pudieran definir cookies procedentes de sitios
dentro de la "misma parte". Usamos una Política de usuario-agente para definir qué constituiría una “misma parte”. Esta definición de política intentó basarse en los frameworks existentes de "parte" (por ejemplo, la especificación de DNT de W3C) y también incorporó recomendaciones de discursos de privacidad relevantes (como el informe de la Comisión Federal de Comercio de 2012 titulado "Protección de la privacidad del consumidor en una era de cambios rápidos").
En ese momento, sentimos que este enfoque proporcionaba suficiente flexibilidad para diferentes tipos de organizaciones en varios sectores, a la vez que cumplía con nuestro objetivo fundamental de minimizar el seguimiento generalizado a través de cookies de terceros.
Comentarios sobre la propuesta inicial
A través de muchas conversaciones con las partes interesadas del ecosistema web, descubrimos que este diseño inicial tenía limitaciones.
Desafíos de privacidad con acceso pasivo a cookies mediante el atributo SameParty
Otros proveedores de navegadores preferían un enfoque activo para el acceso a cookies de terceros que requiriera una invocación explícita a la API, en lugar de establecer un límite dentro del cual se podía mantener el acceso a cookies pasivas. Las solicitudes activas de acceso a cookies proporcionan visibilidad y control del navegador para mitigar el riesgo de seguimiento encubierto a través de cookies de terceros. Además, esta visibilidad permitiría que los navegadores brinden a los usuarios la opción de permitir o bloquear el acceso de las cookies.
Con el fin de buscar la interoperabilidad web en todos los navegadores y mejorar los beneficios de privacidad, decidimos avanzar en esta dirección.
Desafíos de implementación con respecto a la política propuesta
La política original propuso tres requisitos para que los dominios estuvieran en un solo conjunto: “propiedad común”, “identidad común de grupo” y “política de privacidad común”.
En el ecosistema más amplio, descubrimos que los comentarios que recibimos sobre la política se basan en cuatro temas principales.
La propiedad común es demasiado restrictiva
Con respecto al requisito de "propiedad común", recibimos comentarios de que una definición de FPS que se centre solo en la propiedad corporativa brindaría a las empresas más grandes una mayor capacidad para agrupar datos en una amplia gama de dominios y servicios para los usuarios, en comparación con las empresas más pequeñas. Dado que nuestro objetivo es crear Privacy Sandbox para todo el ecosistema, tomamos en serio estos comentarios y priorizamos una solución que fuera más inclusiva.
Una sola política limita la extensibilidad a los casos de uso
Si bien la idea de una política holística para gobernar un límite tenía como objetivo proporcionar flexibilidad para los diferentes tipos de dominios que necesitarían estar en el FPS de una organización, descubrimos que algunos casos de uso críticos no podían cumplir con este diseño de política. Por ejemplo, los dominios de servicio (como aquellos que alojan contenido generado por usuarios) pueden requerir acceso a sus cookies en un contexto de terceros para autenticar o identificar a los usuarios. Esos dominios rara vez tienen una página principal accesible para el usuario, por lo que no se pudieron cumplir los requisitos de "identidad de grupo común" o "política de privacidad común" con otros dominios en el mismo FPS.
La percepción y comprensión de los usuarios sobre la identidad de grupo puede variar
En un principio, propusimos barreras de seguridad para definir una "identidad de grupo común" como un intento de determinar el alcance de los dominios dentro de un solo conjunto con aquellos que podrían asociarse fácilmente con una identidad de grupo común. Sin embargo, no pudimos definir un medio técnico para medir y evaluar si la identidad de grupo común podría ser "fácilmente visible para los usuarios". Esto generó posibles abusos y da lugar a dudas sobre la aplicación de la política.
También recibimos comentarios que indican que la comprensión del significado de los límites de la "propiedad común" puede variar de un usuario a otro, lo que dificulta la creación de lineamientos que se puedan aplicar a todos los sitios.
Una política subjetiva es difícil de aplicar a escala
Recibimos muchas solicitudes de lineamientos más detallados, dada la naturaleza subjetiva de ciertos requisitos (como "identidad de grupo común") y la necesidad de cubrir excepciones o casos extremos para otros (acerca de la "política de privacidad común").
Para garantizar que la política se aplicara de manera equitativa y coherente, Chrome habría tenido que proporcionar a los autores de sitios lineamientos mucho más específicos. Determinamos que intentar crear lineamientos más estrictos podría ser exclusivo en detrimento del ecosistema.
Si bien en un principio propusimos que una entidad de aplicación independiente asuma la función de investigar y aplicar las políticas, en el ecosistema actual, encontrar una entidad de aplicación independiente con la experiencia adecuada para cumplir estas responsabilidades de forma imparcial era un desafío. En cambio, nos esforzamos por cambiar a una política que pueda aplicarse técnicamente para garantizar que la implementación se pueda aplicar de manera coherente y objetiva.
La evolución
En respuesta a los comentarios, rediseñamos los FPS. Regresamos a los problemas específicos que estábamos tratando de abordar y decidimos enmarcar la propuesta de forma más directa en torno a los casos de uso específicos que estábamos resolviendo.
Soluciones para casos de uso clave
Chrome desarrolló tres "subconjuntos" diferentes con propósitos específicos para cumplir con los casos de uso clave en la Web. El enfoque de subconjuntos mejoró el enfoque anterior, ya que era más privado, más específico y más fácil de aplicar de manera coherente.
- “ccTLD” (dominios de nivel superior con código de país): Las organizaciones pueden mantener sitios con diferentes ccTLD para experiencias localizadas, y es posible que estos sitios aun así requieran acceso a infraestructura y servicios compartidos.
- Dominios de "servicio": Es posible que los sitios usen dominios discretos por motivos de seguridad o de rendimiento, y que requieran acceso a la identidad del usuario para realizar sus funciones.
- Dominios "asociados": Las organizaciones pueden mantener varios sitios para diferentes marcas o productos relacionados. Es posible que quieran tener acceso a las cookies entre sitios para casos de uso, como las estadísticas de los recorridos de los usuarios en sitios relacionados, para comprender mejor cómo interactúa la base de usuarios de una organización con sus sitios o recordar el estado de acceso de un usuario en un sitio relacionado que depende de la misma infraestructura de acceso.
Para cada uno de estos casos de uso, existen requisitos de políticas discretos, verificaciones de validación técnica correspondientes y comportamiento específico de manejo del navegador (obtén más información en los Lineamientos de envío). Estos cambios abordan las limitaciones de la propuesta original, ya que abandonan un diseño de "tamaño único" y se favorece un framework compartimentado y basado en los casos de uso.
Oportunidad de interoperabilidad a través de solicitudes activas para acceder a cookies de terceros
En Chrome, quieren promover la interoperabilidad con otros navegadores para mantener el buen estado de la plataforma web. Dado que otros navegadores, como Safari, Firefox y Edge, usan la API de Storage Access (SAA) para facilitar las solicitudes activas de cookies, decidimos aprovechar SAA en Chrome no solo para abordar los comentarios clave que recibimos, sino también para admitir la interoperabilidad web.
Para proporcionar más flexibilidad a los desarrolladores y abordar limitaciones conocidas de SAA, también propusimos la API de requestStorageAccessForOrigin.
Oportunidad de usar la API de Storage Access y FPS en conjunto
Cuando se implementa la API de Storage Access (SAA), los navegadores pueden optar por pedirles permiso a los usuarios directamente, y otros pueden optar por permitir una cantidad limitada de solicitudes sin solicitar un permiso.
Chrome cree que los FPS pueden proporcionar una capa transparente sobre SAA, ya que limita la fricción del usuario y evita la fatiga de mensajes para casos de uso clave y limitados. FPS también proporciona a los navegadores la flexibilidad para proporcionar a los usuarios contexto adicional sobre la membresía establecida, en caso de que decidan solicitar permiso a los usuarios.
Con los FPS, los desarrolladores tienen la oportunidad de identificar sus propios sitios afectados que entregan casos de uso clave. Esto les permite a los desarrolladores anticipar cómo funcionarán sus sitios para los usuarios y tomar medidas para limitar el impacto en la experiencia del usuario mediante el uso de los FPS o una alternativa de cookies de terceros. Además, FPS proporciona previsibilidad a la plataforma de los desarrolladores, en comparación con las heurísticas que pueden cambiar con el tiempo o generar comportamientos variables para diferentes usuarios.
Por último, los desarrolladores que implementan SAA para trabajar con FPS en Chrome también podrán aprovechar SAA para el rendimiento de sus sitios en otros navegadores, incluso aquellos que no envían FPS.
Debate continuo
Creemos que nuestra propuesta más reciente logra el equilibrio adecuado en un espacio de intercambio desafiante que considera las necesidades de los usuarios y los desarrolladores. Agradecemos los comentarios de las partes interesadas del ecosistema web que nos ayudaron a mejorar la propuesta de FPS.
Reconocemos que las partes interesadas del ecosistema web aún se están familiarizando con la propuesta actualizada. Interactúa con nosotros para que podamos seguir mejorando el diseño de manera que sea más útil para los desarrolladores y siga mejorando la privacidad en la Web. Google también seguirá trabajando con la Autoridad de Competencia y Mercados (CMA) del Reino Unido para garantizar el cumplimiento de los Compromisos.
Para participar, consulta los siguientes recursos:
- Incubación en WICG
- Instrucciones de prueba de FPS
- Conjuntos propios: Guía de integración
- Lineamientos para el envío de FPS
Trabajar con el ecosistema
Es fantástico ver a empresas como Salesforce y CafeMedia participar en los comentarios clave y el desarrollo de First-Party Sets. Fueron fundamentales para el avance de la tecnología. Varios usuarios también compartieron sus opiniones sobre los Conjuntos propios y los esfuerzos de Chrome para trabajar con el ecosistema web:
"Chrome está desarrollando conjuntos propios para alinearlos con muchos de nuestros casos de uso, como preservar los recorridos de los usuarios. Esto nos demuestra que el equipo de Google trabaja para comprender los diferentes tipos de necesidades de los propietarios de sitios en la Web". - Mercado Libre
"En VWO, valoramos los esfuerzos de Google por elevar los estándares de privacidad y, al mismo tiempo, garantizar que se manejen los casos de uso genuinos. Es estupendo que el equipo colabore con el ecosistema de desarrolladores y mejore constantemente la implementación de la propuesta de conjuntos propios en función de los comentarios de las partes interesadas de la Web. Nos entusiasma formar parte del recorrido de prueba de la propuesta y ansiamos que se incorpore al navegador". Nitish Mittal, director de Ingeniería, VWO