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 de la Web abierta durante la incubación de FPS, primero en el grupo comunitario de privacidad del W3C y ahora en el grupo comunitario de incubadora web.
En esta entrada de blog, resumiremos el proceso de evolución, destacaremos los cambios clave y analizaremos por qué creemos que estos cambios mejoran la privacidad en la Web y, al mismo tiempo, siguen apoyando al ecosistema.
Información general
Los sitios suelen depender del acceso a sus cookies en un contexto de terceros para ofrecer experiencias fluidas y personalizadas a los usuarios. Además de las APIs de anuncios que preservan la privacidad (Topics, la API de Protected Audience y Attribution), el equipo de Chrome buscó comprender el alcance de las situaciones en las que se usaban cookies de terceros, más allá de los fines de personalización de anuncios o medición, para proporcionar experiencias de navegación mejoradas a los usuarios.
Descubrimos que las organizaciones pueden depender de las 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 campamentos, y desea admitir los recorridos de los usuarios en esos sitios. Una organización también puede mantener varios dominios de código de país con infraestructura compartida para su servicio web. En casos como estos, nos propusimos crear una solución que se alineara con las necesidades de esas organizaciones y, al mismo tiempo, preservara las expectativas de los usuarios en cuanto a su privacidad en la Web.
Dónde comenzamos
Dado que, actualmente, el navegador usa el límite a nivel del sitio para interpretar "propio" en comparación con "de 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 los conjuntos propios, de modo que los sitios pudieran definir cookies que provengan de sitios dentro del "mismo grupo". Usamos una política de usuario-agente para definir lo que constituiría una "misma parte". Esta definición de política intentó basarse en los marcos de trabajo existentes de “fiesta” (por ejemplo, de la especificación de DNT del W3C) y, además, incorporó recomendaciones de discursos de privacidad relevantes (como el informe de 2012 de la Comisión Federal de Comercio titulado “Protecting Consumer Privacy in an Era of Rapid Change”).
En ese momento, consideramos que este enfoque proporcionaba suficiente flexibilidad para diferentes tipos de organizaciones en todos los sectores y, al mismo tiempo, se adhería a 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 en el ecosistema web, descubrimos que había limitaciones con este diseño inicial.
Desafíos de privacidad con el acceso pasivo a cookies a través del atributo SameParty
Otros proveedores de navegadores prefieren un enfoque activo para el acceso a cookies de terceros que requiere una invocación a la API explícita, en lugar de establecer un límite dentro del cual se pueda mantener el acceso pasivo a las cookies. Las solicitudes activas de acceso a cookies proporcionan visibilidad y control al navegador para que se pueda mitigar el riesgo de seguimiento encubierto a través de cookies de terceros. Además, esta visibilidad permitiría a los navegadores brindar a los usuarios la opción de permitir o bloquear ese acceso a las cookies.
Decidimos avanzar en esta dirección para lograr la interoperabilidad web en todos los navegadores y mejorar los beneficios de privacidad.
Desafíos de implementación con la política propuesta
La política original proponía tres requisitos para que los dominios estuvieran en un solo conjunto: "propiedad común", "política de privacidad común" e "identidad de grupo 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
En relación con el requisito de "propiedad común", recibimos comentarios que indicaban que una definición de FPS que se enfocara únicamente en la propiedad corporativa les daría a las empresas más grandes una mayor capacidad para agrupar datos en una amplia variedad de dominios y servicios para usuarios, en comparación con las empresas más pequeñas. Dado que nuestro objetivo es compilar Privacy Sandbox para todo el ecosistema, nos tomamos estos comentarios en serio y priorizamos una solución más inclusiva.
Una sola política limita la extensibilidad a los casos de uso.
Si bien la idea de una política integral para administrar un límite tenía como objetivo proporcionar flexibilidad para los diferentes tipos de dominios que deberí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 los que alojan contenido generado por el usuario) pueden requerir acceso a sus cookies en un contexto de terceros para autenticar o identificar a los usuarios. Estos dominios rara vez tienen una página principal a la que los usuarios puedan acceder, por lo que no se pueden 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 del grupo pueden diferir
Originalmente, propusimos límites para definir una "identidad de grupo común" como un intento de abarcar los dominios dentro de un solo conjunto para aquellos que se podrían asociar fácilmente con una identidad de grupo común. Sin embargo, no pudimos definir un medio técnico para medir y evaluar si los usuarios podrían “descubrir fácilmente” la identidad del grupo común. Esto generaba un potencial abuso y preguntas sobre la aplicación.
También recibimos comentarios que indican que la comprensión del significado de los límites de "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 gran escala.
Recibimos muchas solicitudes de lineamientos más detallados, debido a la naturaleza subjetiva de ciertos requisitos (como "identidad de grupo común") y la necesidad de abarcar excepciones o casos extremos para otros (en relación con la "política de privacidad común").
Para garantizar que la política se aplicara de manera equitativa y coherente, Chrome debería haber proporcionado a los autores de sitios lineamientos mucho más específicos. Determinamos que intentar crear lineamientos más estrictos podría ser exclusivo para perjudicar al ecosistema.
Si bien, en un principio, propusimos que una entidad independiente de aplicación de políticas asumiera el rol de investigar y aplicar el cumplimiento de la política, en el ecosistema actual, encontrar una entidad independiente de aplicación de políticas con la experiencia adecuada para llevar a cabo estas responsabilidades de manera imparcial fue un desafío. En cambio, nos esforzamos por cambiar a una política que se pudiera aplicar técnicamente para garantizar que la implementación se pudiera aplicar de manera coherente y objetiva.
La evolución
En respuesta a los comentarios, rediseñamos los FPS. Volvimos a los problemas específicos que intentábamos abordar y decidimos enmarcar la propuesta de manera más directa en los casos de uso específicos para los que estábamos resolviendo.
Cómo resolver casos de uso clave
Chrome desarrolló tres "subconjuntos" diferentes diseñados a medida para satisfacer los casos de uso clave en la Web. El enfoque de subconjuntos mejoró el enfoque anterior, ya que es más privado, más específico y más fácil de aplicar de forma 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 aún requieran acceso a servicios e infraestructura compartidos.
- Dominios "de servicio": Los sitios pueden usar dominios discretos por motivos de seguridad o rendimiento, y estos sitios pueden requerir acceso a la identidad de un usuario para realizar sus funciones.
- Dominios "asociados": Las organizaciones pueden mantener varios sitios para marcas o productos diferentes y relacionados. Es posible que deseen acceder 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 para recordar el estado de acceso de un usuario en un sitio relacionado que se basa en la misma infraestructura de acceso.
Para cada uno de estos casos de uso, existen requisitos de políticas discretos, verificaciones de validación técnicas correspondientes y un comportamiento específico de manejo de navegadores (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 “único para todos” y favorecen un marco de trabajo compartimentado y basado en casos de uso.
Oportunidad de interoperabilidad a través de solicitudes activas de acceso a cookies de terceros
Chrome desea promover la interoperabilidad con otros navegadores para mantener el buen funcionamiento de la plataforma web. Dado que otros navegadores, como Safari, Firefox y Edge, actualmente usan la API de Storage Access (SAA) para facilitar las solicitudes de cookies activas, decidimos aprovechar la SAA en Chrome no solo para abordar los comentarios clave que recibimos, sino también para admitir la interoperabilidad web.
Para brindar más flexibilidad a los desarrolladores y abordar las limitaciones conocidas de la 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 acceso al almacenamiento (SAA), los navegadores pueden optar por solicitar permiso directamente a los usuarios, mientras que otros pueden permitir una cantidad limitada de solicitudes sin un mensaje de permiso.
Chrome cree que los FPS pueden proporcionar una capa transparente sobre la SAA, ya que limitan la fricción del usuario y evitan la fatiga inmediata en casos de uso clave y limitados. Los FPS también brindan a los navegadores la flexibilidad de proporcionarles a los usuarios contexto adicional sobre la membresía establecida, si deciden solicitarles permiso.
Con FPS, los desarrolladores tienen la oportunidad de identificar sus propios sitios afectados que publican casos de uso clave. Esto permite a los desarrolladores de la agencia anticipar cómo funcionarán sus sitios para los usuarios y tomar medidas para limitar el impacto en la experiencia del usuario aprovechando los FPS o una alternativa de cookies de terceros. Además, los FPS proporcionan a los desarrolladores previsibilidad de la plataforma, a diferencia de las heurísticas, que pueden cambiar con el tiempo o generar comportamientos diferentes para los distintos usuarios.
Por último, los desarrolladores que implementen la SAA para trabajar con FPS en Chrome también podrán aprovecharla para el rendimiento de sus sitios en otros navegadores, incluso aquellos que no envían FPS.
Continuación del debate
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 que nos enviaron las partes interesadas del ecosistema web, que nos ayudaron a desarrollar la propuesta de FPS.
Reconocemos que las partes interesadas del ecosistema web aún se están familiarizando con la propuesta actualizada. Comunícate con nosotros para que podamos seguir mejorando el diseño de una manera que sea más útil para los desarrolladores y que siga mejorando la privacidad en la Web. Google también seguirá trabajando con la Competition and Markets Authority (CMA) del Reino Unido para garantizar el cumplimiento de los compromisos.
Para participar, consulta los siguientes recursos:
- Incubación en WICG
- Instrucciones para las pruebas de FPS
- Conjuntos propios: guía de integración
- Lineamientos para el envío de FPS
Cómo trabajar con el ecosistema
Es genial ver que empresas como Salesforce y CafeMedia participan en los comentarios clave y el desarrollo de conjuntos propios. Han sido fundamentales para el avance de la tecnología. Otras personas 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 alinearse con muchos de nuestros casos de uso, como preservar los recorridos de los usuarios. Esto demuestra que el equipo de Google está trabajando para comprender los diferentes tipos de necesidades de los propietarios de sitios en la Web". - Mercado Libre
"En VWO, apreciamos los esfuerzos de Google por elevar los estándares de privacidad y, al mismo tiempo, garantizar que se manejen casos de uso genuinos. Es excelente 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 web. Nos entusiasma ser parte del proceso de prueba de la propuesta y esperamos su incorporación al navegador". - Nitish Mittal, director de Ingeniería, VWO