Informe trimestral del segundo trimestre de 2022 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.
Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se realiza una agregación de la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas de comentarios comunes, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos de Google y los formularios públicos.
Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios público. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de las preguntas frecuentes publicadas, las respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. Debido al enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Fledge y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período de informes actual aún no tengan una respuesta de Chrome.
Glosario de acrónimos
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- FPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IDP
- Proveedor de identidad
- IETF
- Internet Engineering Task Force
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Usuario de confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- Cadena de usuario-agente
- UA-CH
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera IP intencional
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Cronogramas más claros | Cronogramas de lanzamiento más claros y detallados para las tecnologías de Privacy Sandbox | Presentamos nuestros planes actuales para el programa de implementación en privacysandbox.com y lo actualizamos mensualmente. Estos tienen en cuenta el tiempo de desarrollo de los desarrolladores web y de Chrome, así como los comentarios que recibimos del ecosistema más amplio sobre el tiempo necesario para probar y adoptar las nuevas tecnologías. Cada tecnología pasa por varios pasos, desde la prueba hasta el lanzamiento, y los tiempos de cada paso se basan en lo que aprendemos y descubrimos en el paso anterior. Si bien no tenemos lanzamientos confirmados en este momento, cuando los tengamos, nos aseguraremos de actualizar nuestro cronograma público en privacysandbox.com. |
| Utilidad para diferentes tipos de partes interesadas | Preocupaciones sobre el hecho de que las tecnologías de Privacy Sandbox favorezcan a los desarrolladores más grandes y que los sitios de nicho (más pequeños) contribuyan más que los sitios genéricos (más grandes). | Comprendemos que algunos desarrolladores tienen inquietudes sobre el impacto de las tecnologías de Privacy Sandbox. Google se comprometió con la CMA a no diseñar ni implementar las propuestas de Privacy Sandbox de una manera que distorsione la competencia dando preferencia a su propio negocio, y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes, así como los impactos en los resultados de la privacidad y la experiencia del usuario. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos.
A medida que avanzan las pruebas de Privacy Sandbox, una de las preguntas clave que evaluaremos es el rendimiento de las nuevas tecnologías para los diferentes tipos de partes interesadas. Los comentarios son fundamentales en este sentido, en especial los comentarios específicos y prácticos que pueden ayudarnos a mejorar aún más los diseños técnicos. |
| Cronogramas de baja de las cookies de terceros | Solicitudes para evitar más demoras en la baja de las cookies de terceros | Escuchamos a algunas partes interesadas que quieren que Chrome proceda con la baja de las cookies de terceros sin demoras, y a otras que creen que se necesita más tiempo para probar y adoptar las tecnologías de Privacy Sandbox. Nos comprometemos a actuar con responsabilidad, dada la complejidad de las tecnologías y la importancia que tiene para el ecosistema hacerlo bien. Los comentarios de la industria y de los reguladores fueron fundamentales para este proceso. |
| Cronogramas de baja de las cookies de terceros | Solicitudes para retrasar la baja de las cookies de terceros y proporcionar más tiempo para probar las APIs. | Escuchamos a algunas partes interesadas que quieren que Chrome elimine las cookies de terceros sin demoras, y a otras que creen que se necesita más tiempo para probar y adoptar las tecnologías de Privacy Sandbox. Nos comprometemos a actuar con responsabilidad, dada la complejidad de las tecnologías y la importancia que tiene para el ecosistema hacer las cosas bien. Los comentarios de la industria y de los reguladores fueron fundamentales para este proceso. |
| Solicitudes de documentación | Solicitudes de más recursos que detallen cómo administrar las pruebas, el análisis y la implementación | Agradecemos que los desarrolladores hayan encontrado útil nuestro material actual y nos comprometemos a proporcionar más material, como documentación técnica y horas de oficina para desarrolladores, en las próximas semanas y meses para que los desarrolladores puedan seguir entendiendo cómo pueden beneficiarse de las nuevas tecnologías.
También realizamos sesiones públicas de horas de atención para desarrolladores externos para compartir prácticas recomendadas y demostraciones, junto con sesiones de preguntas y respuestas con líderes de Producto y de Ingeniería para permitir debates y preguntas en vivo. |
| Experiencia en la industria | El equipo de Chrome que interactúa con los organismos de estándares carece de la experiencia en el ecosistema de anuncios necesaria para equilibrar adecuadamente la privacidad y la utilidad. | Reconocemos que tenemos una gran responsabilidad y dependemos de los comentarios específicos para hacerlo bien. También consideramos que la privacidad y la eficacia son criterios de diseño fundamentales y necesarios. En el equipo que trabaja en Privacy Sandbox para la Web, la suma total de años trabajados en el ecosistema de anuncios supera los cientos. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Utilidad para diferentes tipos de partes interesadas | Se plantearon inquietudes sobre el valor creado y la distribución de ese valor para los sitios según su nivel de tráfico o qué tan especializado es su contenido. | La utilidad de la API se explorará a través de pruebas. Chrome espera que la taxonomía y otros parámetros evolucionen en función de los resultados de las pruebas. Es posible que la evolución de la taxonomía o los parámetros no requiera cambios incompatibles con versiones anteriores. Además, Chrome espera que los comentarios sigan influyendo en la evolución de la API de Topics después de que se den de baja las cookies de terceros. |
| Taxonomía | Las partes interesadas de la industria desean tener voz para influir en la taxonomía. | Chrome sigue aceptando comentarios sobre la taxonomía. A Chrome le interesan mucho los comentarios sobre el modelo de gobernanza para modificar la taxonomía y el debate sobre cómo otros organismos de la industria pueden desempeñar un papel más activo en el desarrollo y el mantenimiento de la taxonomía a largo plazo. |
| No hay suficiente historial de navegación | Propuesta para mostrar los temas que el llamador vio en semanas anteriores si el usuario no tiene suficiente historial de navegación para crear 5 temas para la semana más reciente | En nuestro diseño actual, se eligen al azar. Investigaremos la correlación con temas anteriores y consideraremos si hay alguna posibilidad de incorporarlo. Sin embargo, las correlaciones pueden tener consideraciones adversas de privacidad que se deben tener en cuenta. |
| Cómo llamar a Topics en nombre de un publicador | ¿Puede un proveedor de servicios externo compartir temas con un publicador? | Sí, esa es una forma en la que esperamos que se usen los temas. |
| Posibles vectores de ataque | Cómo identificar los temas con ruido | En función de los comentarios de muchos miembros del ecosistema, Chrome decidió filtrar temas y agregar ruido. Estas decisiones se tomaron teniendo en cuenta la privacidad, para limitar el acceso a la información a quienes, de otro modo, no tendrían acceso a ella y para ofrecer a los usuarios una negación plausible, respectivamente. Reconocemos que esas decisiones tienen inconvenientes, como el vector de ataque que se describe aquí. Sin embargo, nuestra evaluación es que los beneficios de privacidad superan los posibles riesgos. Aceptamos el debate público sobre esta decisión. |
| Elegibilidad para la prueba de origen | ¿Hay alguna manera de detectar si un usuario es apto para una prueba de Origin? | Es posible que una función de prueba de origen no esté disponible para un usuario debido a la configuración del navegador o a otros factores, incluso si visita una página web que proporciona un token de prueba válido y su navegador se incluye en el grupo para el que está habilitada la prueba.
Por esa razón, siempre se debe usar la detección de funciones para verificar si hay una función de prueba de origen disponible antes de intentar usarla. |
| Impactos en el rendimiento | Problemas de sobrecarga y latencia con Topics | Solicitamos comentarios sobre enfoques para evitar iframes de origen cruzado costosos y lentos, y para que la propuesta desvincule la API de Topics de modo que obtener temas no cambie el estado de navegación. |
| Funcionalidad de la API de Split Topics | Proporcionar más control sobre los tres aspectos diferentes de la API | Comprendemos el caso de uso y propusimos una posible forma de resolverlo en GitHub. Actualmente, estamos esperando más comentarios del ecosistema para decidir si compilamos la función. Consulta el debate en curso aquí. |
| Cronograma y documentación del clasificador | Los desarrolladores solicitaron más información sobre el clasificador. | Proporcionamos más información sobre el clasificador aquí.
Además, aquí Y aquí. |
| Controles de usuario y seguridad | Ciertos temas pueden ser proxies para grupos sensibles, y los usuarios necesitan más controles para evitar resultados negativos. | Los temas representan un paso importante hacia adelante en términos de transparencia y control del usuario. Los usuarios podrán inhabilitar los temas, revisar los que se les asignaron, quitarlos y comprender qué empresas interactúan con sus temas en una página determinada. Además, los usuarios también pueden influir en sus temas borrando su historial de navegación. Nos complace continuar con el debate sobre controles de usuario más avanzados, como los que sugirieron los desarrolladores. Sin embargo, debemos asegurarnos de que, en relación con las inquietudes planteadas en este error, realmente se quiten los riesgos (por ejemplo, quitar solo el tema "Estudio de idiomas extranjeros", pero no los sitios web que generaron el tema del historial de navegación, no protege completamente al usuario). |
| Uso de temas en sitios con prebid.js | ¿Se puede usar la API de Topics en sitios web con prebid.js? | La respuesta breve es que sí. Aquí puedes encontrar más información. |
| Uso de la API de Topics en un widget de recomendación | ¿Podemos usar la API de Topics en el widget de contenido recomendado (p.ej., Outbrain)? | No limitamos el caso de uso de los temas recuperados después de que se llama a la API (eso dependerá de la política de datos de cada desarrollador). |
| Privacidad / Política | Preguntas sobre el propósito de filtrar las respuestas por llamador si algunos terceros compartirán sus temas con cualquier persona que llame. | En función de los comentarios de muchos miembros del ecosistema, Chrome eligió este diseño para limitar el acceso a la información a quienes, de otro modo, no tendrían acceso a ella. Por supuesto, los publicadores y terceros que reciben temas pueden decidir por sí mismos qué información compartirán con las partes en su sitio. Si realizan este tipo de uso compartido, Chrome les recomienda que sean transparentes con sus usuarios y les ofrezcan controles. |
| Señales con ruido | Publicar un tema aleatorio el 5% del tiempo podría generar demasiado ruido o indicadores falsos. | El ruido es un método importante para proteger la privacidad del usuario, y los niveles de ruido en comparación con la utilidad de los temas se explorarán a través de pruebas. |
FLEDGE
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Coordinación de pruebas | Pruebas para medir el impacto en el rendimiento y los ingresos | El rendimiento de FLEDGE y cómo podemos respaldar mejor las pruebas del ecosistema durante las pruebas de origen y la disponibilidad general se analizan de forma activa en las reuniones públicas de WICG. |
| Servidor de confianza para FLEDGE | ¿Cuándo estará disponible el servidor de confianza para pruebas? | Agradecemos tus comentarios y estamos trabajando activamente en un plan más detallado que podamos compartir para el uso de servidores de confianza en FLEDGE. |
| Estandarización de protocolos | ¿Habrá un protocolo común para pasar datos entre SSP y DSP, como etiquetas comunes para los grupos de intereses? | Aceptamos los comentarios de las DSP, las SSP y el ecosistema de anuncios más amplio sobre la posible estandarización de las especificaciones. En este momento, para las pruebas iniciales, te recomendamos que trabajes directamente con tus socios de pruebas, ya que están experimentando con diferentes enfoques. También animamos a las organizaciones comerciales de anuncios a que participen en la creación de estándares en caso de que sea útil para sus empresas miembros y planeamos seguir trabajando con ellas. |
| Limitación de frecuencia | Controles de frecuencia por usuario dentro de una campaña y un grupo de anuncios | FLEDGE también admitirá la limitación de frecuencia para las subastas integradas en el dispositivo y las campañas contextuales o de desarrollo de la marca. El almacenamiento compartido y los límites específicos del sitio también se pueden usar para controles adicionales de limitación de frecuencia. |
| Impacto de FLEDGE en el rendimiento | Ofertantes con un alto procesamiento en la subasta de FLEDGE | Chrome está en conversaciones activas con los desarrolladores sobre el posible impacto en el rendimiento de los sitios. Chrome aprovecha la oportunidad de obtener más información durante las pruebas. |
| Prueba FLEDGE con otras funciones | ¿Cómo se combinarán los informes a nivel del evento de la API de Attribution Reporting y FLEDGE? | Esto se analizó en una llamada reciente de WICG/conversion-measurement-api, con un vínculo a los minutos detallados aquí.
El resumen de la reunión es que el diseño actual de los informes de anuncios de marcos delimitados permite asociar un ID generado dentro del marco delimitado con información contextual. Por lo tanto, los informes a nivel del evento generados dentro del marco delimitado se podrán unir a la misma información contextual en el servidor (con 2 uniones del servidor en lugar de 1). |
| Recuento de impresiones | Qué metodología de recuento de impresiones se debe o se puede utilizar entre compradores y vendedores | La API de FLEDGE ya admite la alineación de la metodología entre el vendedor y el comprador durante la subasta. Recibimos sugerencias sobre implementaciones alternativas sin comentarios sobre por qué nuestro diseño actual no puede funcionar para el ecosistema. |
| Cómo mostrar varios anuncios | Si se pueden mostrar varios anuncios en una subasta en un marco de contenido protegido determinado | Actualmente, esto es posible a través de los anuncios de componentes (no confundir con las subastas de componentes). Para ello, todos los anuncios deben estar en el mismo grupo de intereses. |
| Especificación de "Públicos definidos por el vendedor (SDA)" y FLEDGE | ¿Podría FLEDGE convertirse en un mecanismo para evitar que los compradores creen perfiles a partir de la SDA en las solicitudes de anuncios? | FLEDGE está diseñado para evitar la filtración de información que no es relevante cuando el publicador ya sabe en qué SDAs se encuentran sus visitantes y la segmentación es del mismo sitio. Si es importante admitir la compra en SDA dentro de todas las protecciones integradas en FLEDGE, una solución podría ser que un vendedor pase etiquetas de SDA a la subasta integrada en el dispositivo y que una tecnología publicitaria orientada a la compra cree su propio grupo de intereses cuya lógica de ofertas diga "Quiero comprar el público X". |
| Compatibilidad con monedas distintas del dólar estadounidense | Compatibilidad para probar FLEDGE con monedas distintas del USD | Agradecemos tu comentario y agregamos la compatibilidad con otras monedas en nuestro lista de tareas pendientes de solicitudes de funciones. Esperamos que esta función esté disponible pronto. |
| Compatibilidad con la segmentación negativa por grupos de interés | Una API para admitir la segmentación negativa de IG: muestra anuncios solo si un usuario no pertenece a un IG. | Se está realizando un debate continuo, incluidas algunas opciones propuestas para brindar asistencia, en el problema de GitHub. |
| Varias SSP en FLEDGE | Riesgo de favorecer a Google cuando se implementan subastas de varios niveles en FLEDGE | Se agregó compatibilidad con varias SSP en FLEDGE para brindar un campo de juego justo y equitativo. En virtud de los Compromisos, Google prometió no diseñar, desarrollar ni implementar las propuestas de Privacy Sandbox de manera que distorsionen la competencia dando preferencia a sus productos y servicios publicitarios. Google se toma esto muy en serio y está dispuesto a analizar cualquier inquietud que las partes interesadas puedan tener sobre aspectos específicos de la tecnología. Para obtener información, Chrome documentó públicamente el mecanismo de subasta de componentes aquí. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Atribución de múltiples puntos de contacto | Publicadores que solicitan asistencia para la atribución de múltiples puntos de contacto | Los métodos actuales de atribución multitáctil requieren vincular de forma determinista las impresiones (y, por lo tanto, la identidad) de un usuario en diferentes sitios web. Como resultado, esta funcionalidad en su forma actual no se alinea con los objetivos de Privacy Sandbox, que tiene como objetivo admitir casos de uso de anuncios clave sin seguimiento entre sitios. En algunos casos, es posible aproximar la asignación de crédito (p.ej., mediante el uso de prioridades ponderadas y aleatorias) sin hacer un seguimiento de usuarios individuales. |
| Generación de ruido | Preguntas sobre los niveles de ruido en los informes | Nuestro experimento inicial permite que los desarrolladores establezcan su propio valor de epsilon para que puedan experimentar cómo cambian los informes en función del nivel de ruido. A partir de ahora, los desarrolladores pueden elegir un valor de epsilon hasta epsilon=64. Hicimos esto específicamente para que los desarrolladores puedan probar las APIs con mayor facilidad y enviarnos comentarios sobre los valores de epsilon adecuados.
También realizamos una solicitud pública para obtener esos comentarios. |
| Coordinación de pruebas | ¿Se puede usar la herramienta de pruebas locales para la OT? | Sí, la herramienta de prueba local se puede usar durante la OT. La herramienta de pruebas locales se puede usar con informes de depuración, siempre y cuando haya cookies de terceros disponibles. |
| Ergonomía de las consultas | Habilita la consulta de un agregado de claves | Creemos que esto parece mejorar la ergonomía de la API con poco o ningún costo aparente de privacidad. Haremos una propuesta y veremos si hay un consenso general de que vale la pena apoyarla. |
| Datos menos precisos para sitios pequeños | Es posible que los sitios o las campañas más pequeños reciban datos menos precisos. | Chrome reconoce que las protecciones de la privacidad basadas en el ruido tienen un mayor impacto en los segmentos de datos más pequeños. Sin embargo, es posible que métodos como la agregación durante períodos más largos resuelvan este problema. Tampoco está claro si las conclusiones basadas en segmentos de datos muy pequeños (como una o dos compras) son significativas para los anunciantes. Durante la prueba de origen, Chrome alienta a los verificadores a aprovechar la capacidad de experimentar con una amplia variedad de parámetros de privacidad y ruido para que puedan proporcionar comentarios más específicos sobre este problema. |
Limita el seguimiento encubierto
Reducción de usuario-agente
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Protección contra bots | Impacto de UA-R en la protección contra bots | Agradecemos estos comentarios y estamos en proceso de recopilar información sobre los enfoques de protección contra bots para informar nuestros diseños futuros. |
| Dependencias de implementación | Cómo abordar las dependencias de implementación del usuario-agente estructurado (SUA) | Lanzamos la "Fase 4", también conocida como reducción de la versión secundaria, para el 100% de los usuarios de Chrome en las versiones 101 y posteriores. Consulta la actualización aquí. |
Sugerencias de clientes de usuario-agente
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Enumera todas las sugerencias compatibles | Interés en tener una forma programática de conocer todas las sugerencias compatibles para un navegador. | Agradecemos tus comentarios y estamos evaluando la solicitud de función. Nos interesa saber si este es un caso de uso común. |
| Flexibilidad de UA-CH en comparación con el encabezado de usuario-agente | UA-CH es demasiado prescriptivo en comparación con la flexibilidad que ofrece el encabezado User-Agent, como se define en rfc7231. | Chrome considera que la naturaleza prescriptiva de los encabezados UA-CH es una mejora importante en comparación con la flexibilidad de la cadena UA, tanto desde el punto de vista de la interoperabilidad entre navegadores como de la protección de la privacidad del usuario (ya que evita la adición arbitraria de identificadores de alta entropía).
El problema permanecerá abierto en caso de que otras personas también compartan esta inquietud y quieran enviar comentarios. |
| UA-CH: Preocupaciones sobre medidas contra el fraude o el abuso | Algunas funciones que se podrían perder con UA-CH: el servicio de seguimiento de redireccionamientos de clics y los clics fraudulentos. | El equipo está investigando estos posibles problemas con las partes interesadas en la prevención del fraude y las mediciones. |
| Rendimiento | Existen inquietudes sobre la latencia de obtener sugerencias a través de Critical-CH (en la primera carga de la página). | Chrome está investigando formas de mejorar el rendimiento. |
Gnatcatcher (en proceso)
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Problemas de latencia | Agregar saltos adicionales podría afectar la latencia. | Estamos considerando un proxy de dos saltos y explorando formas de encontrar el equilibrio adecuado entre la privacidad del usuario y la latencia. Estamos abiertos a los comentarios y nos encantaría seguir hablando sobre el tema en los foros del W3C. |
| Protección contra fraudes y bots | Impactos en la protección contra el fraude y los bots, incluso en países menos desarrollados | La seguridad es un requisito fundamental a la hora de buscar formas de mejorar la privacidad del usuario de manera significativa, como el uso de proxies de direcciones IP. Un proxy de dos saltos que se asocie con empresas de renombre proporciona una privacidad del usuario verificable. También estamos incubando ideas para nuevos indicadores que ayuden a transmitir la confianza de los usuarios. |
| Cumplimiento de las leyes de privacidad locales | Los informes de datos geográficos a nivel del país dificultan el cumplimiento de los regímenes locales más detallados. | Publicamos nuestros principios propuestos, que incluyen posibles enfoques que permitirían que los sitios web sigan cumpliendo con los requisitos locales. |
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos propios
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Utilidad para diferentes tipos de partes interesadas | Impacto de los FPS en editores pequeños y grandes | El objetivo principal de Privacy Sandbox es mejorar la privacidad del usuario reemplazando las prácticas actuales por soluciones que no dependan de mecanismos de seguimiento entre sitios. Queremos que estas soluciones sean lo más útiles posible para diferentes tipos y tamaños de partes interesadas. Aceptamos comentarios específicos y prácticos sobre cómo se pueden mejorar estas soluciones y esperamos que sigan evolucionando con el debate y las pruebas de la comunidad. |
| Mejora de la privacidad | Si hay demasiados sitios en el mismo conjunto, es posible que se generen resultados similares a los de las cookies de terceros. | Agradecemos estos comentarios y estamos evaluando si los límites correctos son los que se establecieron o si hay otros. Al mismo tiempo, intentamos proporcionar a los usuarios y desarrolladores indicadores o tratamientos para que puedan comprender cuándo se alcanza un límite. Aún no tenemos una propuesta específica para compartir, pero esperamos hacerlo muy pronto. |
| Compatibilidad con ecosistemas de FPS | Recopilación de asistencia y preocupaciones para seguir desarrollando FPS fuera de la CG de privacidad | Si bien hubiéramos preferido que la propuesta de conjuntos propios permaneciera en el PrivacyCG, esperamos seguir impulsando la propuesta en el WICG. También nos sentimos alentados por las numerosas declaraciones de apoyo para continuar con el debate sobre los conjuntos propios y los casos de uso que se pretenden abordar. Google mantiene su compromiso de encontrar soluciones que permitan que la Web siga creciendo y prosperando de una manera que proteja y respete la privacidad de los usuarios. |
| Interoperabilidad del navegador | Implementación por parte de otros navegadores | Reconocemos la importancia de la interoperabilidad de los navegadores para los desarrolladores y seguiremos colaborando con otros navegadores para lograr la estandarización de los FPS. |
| Requisitos comunes de la política de privacidad | No es posible mantener una política de privacidad común en todos los productos y jurisdicciones que deben formar parte del mismo conjunto. | Chrome aún está definiendo los requisitos de nuestras políticas y tendrá en cuenta estos comentarios. |
API de Fenced Frames
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Solicitud de documentación | Diferencias con los iframes en zona de pruebas | Agradecemos tus comentarios y sugerencias. Actualmente, se está discutiendo este tema en GitHub, donde esperamos obtener una aclaración final sobre la solicitud para poder evaluarla por completo. El debate público está disponible aquí. |
| Funciones multiAPI | Compatibilidad predeterminada con los informes de atribución en marcos delimitados | Solicitamos comentarios sobre una propuesta para permitir que la API de Attribution Reporting esté en el "modo de anuncios opacos" de los marcos de contenido protegido de forma predeterminada. Recomendamos a los desarrolladores que consideren que esta función es valiosa que participen en el debate. |
API de Shared Storage
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Límites de datos | ¿Habrá una restricción sobre la cantidad de datos que se pueden almacenar por partición? | Sí, habrá límites. Consulta el problema de GitHub para obtener más detalles. Necesitaremos cuotas de almacenamiento. Nuestra propuesta actual es tener un límite de tamaño por entrada de 4 KB, ambas claves y valores se limitarán a 1,024 caracteres char16_t cada uno, y un límite de entrada por origen de 10,000 entradas con un mecanismo que evite que se confirmen entradas adicionales cuando la capacidad de un origen esté completa. Estamos buscando activamente comentarios sobre los límites específicos que se proponen aquí. |
| Transparencia para el usuario | Transparencia del usuario para las fuentes de datos en comparación con el uso de datos | Agradecemos tus comentarios y creemos que este es un enfoque prometedor que vale la pena explorar. En particular, estamos evaluando si sería posible hacerlo de una manera que ofrezca suficiente transparencia a los usuarios. |
CHIPS
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Impedimentos para la adopción | ¿Debería CHIPS estar vinculado al nombre de host? (el requisito de no tener dominio) | Quitaremos este requisito de la OT en función de los comentarios de los participantes de la OT, que indicaron que este requisito agregaba complejidad adicional y funcionaba como un impedimento para la adopción de CHIPS.
Analizaremos este requisito en el grupo de la comunidad de Privacidad como parte de la incubación de estándares aquí. |
| Casos de uso de anuncios para CHIPS | ¿Se pueden usar CHIPS para casos de uso de Google Ads en un solo sitio? | El seguimiento de usuarios dentro de un sitio es un caso de uso permitido. Actualizamos nuestro artículo para desarrolladores para destacar este caso de uso. |
| Incorporaciones autenticadas | ¿Se conserva el estado de acceso con CHIPS? | Actualmente, no se conserva el estado de acceso, pero no es el caso de uso previsto para CHIPS. Estamos al tanto del caso de uso de incorporaciones autenticadas y estamos trabajando para explorar soluciones. |
| Coordinación de pruebas | ¿Se necesitan acciones adicionales del usuario para probar la partición? | Siempre que el token de OT sea válido y esté presente en los encabezados de las páginas visitadas, la función debería estar disponible para los usuarios, sin que se requiera ninguna acción adicional por parte de ellos. |
| Compatibilidad del navegador | Interés en comprender cómo otros navegadores controlaron los atributos de cookies particionados. | Chrome sigue trabajando en grupos de estándares públicos, como el W3C, para identificar diseños e implementaciones que puedan funcionar en todos los navegadores. |
FedCM
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Posibles vectores de ataque | Posibles vectores de ataque a través de la decoración de vínculos y los ataques de tiempo | Estamos recopilando activamente las opiniones del público y analizando posibles formas de abordar este problema. |
| UX para permitir varios IDP | Solo se puede presentar una IDP a la vez | Creemos en la compatibilidad con varios proveedores de identidades y estamos trabajando activamente en enfoques para admitir |
| Expresividad | Se preocupa porque, como el navegador renderiza parte del flujo de identidad federada, es difícil capturar todos los matices que los IDPs les gustaría presentar a sus usuarios. | Chrome está explorando la inclusión de personalizaciones de desarrollo de la marca (p.ej., logotipos y colores) y de cadenas (p.ej., "acceder a este artículo" en lugar de "acceder con").
Chrome reconoce la compensación y seguirá trabajando con el ecosistema para abarcar la mayor cantidad de contenido posible y hacerlo lo más expresivo posible. |
| Aplicabilidad e interoperabilidad | Preocupación por el hecho de que otros navegadores no adopten ni implementen FedCM. | Chrome también ha estado trabajando con otros proveedores de navegadores para encontrar soluciones comunes de integración en el grupo comunitario de FedID. |
| Sugerencia para quitar los requisitos de datos personales en el flujo de registro | (1) Una UX que le indique al usuario qué IdP está eligiendo, sin indicar que se compartirán su correo electrónico, foto y nombre, sería más amigable con la privacidad.
(2) Los casos de uso de registro son escasos en su experiencia del usuario y en la selección de reclamos de la AC |
Estamos de acuerdo y estamos explorando cómo implementar los comentarios de una manera más amigable para los usuarios y la privacidad. |
| Interacción del usuario con el IdP | Necesidad de interacción directa entre el usuario y la IdP si se supera un umbral de riesgo | Estamos investigando activamente estos comentarios. |
Particionamiento del estado de la red
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Rendimiento | El particionamiento del estado de la red podría aumentar las conexiones con recursos intensivos a las CDN. | Aún estamos investigando las características de rendimiento de Network State Partitioning, incluida la medición de diferentes esquemas de claves posibles. Aún no tomamos una decisión entre las compensaciones de rendimiento, seguridad y privacidad, y necesitamos recopilar más datos. |
Cómo combatir el spam y el fraude
API de Trust Tokens
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Comentarios regulatorios | Preocupaciones sobre invertir tiempo y recursos en tokens de confianza sin una señal clara de los reguladores sobre la viabilidad a largo plazo | Nuestro objetivo es crear una tecnología que funcione para el ecosistema, por lo que los comentarios de la industria y los reguladores son fundamentales para el proceso. Seguiremos consultando a los reguladores de todo el mundo a medida que desarrollemos Privacy Sandbox y pongamos las propuestas a disposición de los desarrolladores, incluidos los tokens de confianza. Al igual que con todas las tecnologías nuevas, las empresas deben tomar decisiones en función de su propia evaluación de los requisitos reglamentarios. |
| Fecha de lanzamiento | ¿Cuándo se lanzarán los tokens de confianza a la versión general? | Proporcionamos nuestras estimaciones actuales para la publicación en nuestro cronograma público en privacysandbox.com. En cuanto tomemos una decisión final sobre la fecha de lanzamiento a la versión GA, la publicaremos a través de los procesos de lanzamiento de Chrome y actualizaremos el cronograma en el sitio web. |
| Comparación entre los tokens de confianza y otros | Qué rol desempeñan los tokens de confianza en función de los otros tokens que se estandarizan, como los tokens de acceso privado | Estamos participando en debates sobre la estandarización, y nuestro objetivo es alinearnos con otros esfuerzos tanto como sea posible, a la vez que habilitamos los diferentes casos de uso que ofrece cada tecnología. Por ejemplo, los tokens de confianza y los tokens de acceso privado dependen del protocolo de Privacy Pass. |
| Límites de datos | Máximo de 2 emisores para el canje de tokens por página, lo que podría ser limitante | Estamos buscando opciones a largo plazo en las que podamos permitir que las empresas canjeen tokens de forma segura sin arriesgar más entropía del usuario, tal vez mediante la partición del acceso a los canjes de tokens. |
| Restricciones de acceso | Solo los orígenes aprobados (y verificados o sin falsificación de referer) deberían poder verificar la presencia de un token y canjearlo. | Estamos explorando enfoques para determinar quién puede ver y canjear tokens. |
| Dispositivos compatibles | Las dependencias del entorno de ejecución de JavaScript limitan el uso en ciertos dispositivos. ¿Se puede extender la compatibilidad con TT para que funcione en otros tipos de dispositivos? | Esto es algo que podríamos considerar para el desarrollo futuro y un tema sobre el que nos encantaría recibir más comentarios de los desarrolladores en los foros del W3C. También tenemos un problema abierto para analizar un canje de token activado por un encabezado HTTP sobre el que te invitamos a enviar comentarios. |
| Casos de uso | No está claro cuáles son los casos de uso correctos para los tokens de confianza. Falta de claridad sobre los usos previstos. | Nuestro objetivo es facilitar la innovación en el espacio de prevención de fraudes y comprender que cada empresa puede emplear técnicas propias con tokens de confianza, por lo que no hemos sido prescriptivos en cuanto a los usos previstos. Sin embargo, es probable que expandamos nuestra documentación para incluir más ejemplos como puntos de partida para los socios que estén considerando la experimentación o la adopción. |
| Cobertura de tokens de confianza | Si quitas esta política de atributos "canje de token de confianza", debería aumentar significativamente la cobertura de los tokens de confianza. | Esto se tiene en cuenta cuando recopilamos comentarios de la OT y tomamos decisiones sobre los próximos pasos. |
| Confianza de la entidad emisora | ¿Por qué deberíamos confiar en los sitios web que emitieron tokens de confianza? | No hay lineamientos para convertirse en emisor, cualquiera puede hacerlo. Se espera que los publicadores solo trabajen con emisores de confianza. Además, otros actores legítimos del ecosistema de anuncios eventualmente descontarían (o dejarían de comprar) el tráfico asociado con emisores sospechosos o desconocidos. |
| Servicios incorporados de terceros | ¿Los servicios incorporados de terceros pueden canjear o solicitar tokens de confianza? | Sí, un servicio incorporado de terceros puede emitir y canjear tokens de confianza. |
| Ecosistema de entidades emisoras | Se puede lograr una mayor utilidad si los indicadores de confianza se pueden compartir con otras empresas. | Los tokens de confianza están diseñados para ser una primitiva de bajo nivel y pueden ser utilizados por emisores o canjeadores que cooperan para compartir indicadores de confianza o reputación. |
| Sobrecarga de mantenimiento | La implementación criptográfica subyacente a las operaciones de tokens de confianza se encuentra en BoringSSL, cuyo único encargado de mantenimiento es Google. ¿Cómo se administrará el mantenimiento de la biblioteca? | Los tokens de confianza se basan en operaciones de criptografía estandarizadas (consulta el protocolo de Privacy Pass) que también se pueden implementar en otras bibliotecas. Recomendamos que los desarrolladores soliciten, desarrollen o mantengan la compatibilidad con estas operaciones en las bibliotecas que elijan. |
| Sobrecarga de mantenimiento | No está claro durante cuánto tiempo se admitirán las versiones del protocolo. | Estamos trabajando para desarrollar y documentar más detalles sobre los plazos de asistencia esperados para las versiones de protocolo. |
| Límites de la entidad emisora | Si estás más abajo en la cadena, es posible que no tengas la oportunidad de ejecutar tokens de confianza. | A medida que más organizaciones comiencen a usar tokens de confianza, es posible que veamos cada vez más este tipo de dinámicas de tiempo en juego, por lo que estamos investigando posibles soluciones. Como se describió anteriormente, buscamos opciones a largo plazo en las que podamos permitir que las empresas canjeen tokens de forma segura sin arriesgarse a aumentar la entropía del usuario, lo que minimizaría la importancia de la ubicación en la página o el orden de carga. |
Nuevas soluciones contra el fraude en incubación
| Tema de los comentarios
(Clasificación por prevalencia) |
Resumen de preguntas y preocupaciones | Respuesta de Chrome |
| Indicadores de certificación de integridad del dispositivo | Generalmente, ofrece una gran compatibilidad para buscar indicadores de integridad del dispositivo certificados por las plataformas y disponibles para la Web | Seguiremos recopilando comentarios y desarrollando la propuesta a través del diseño y la iteración públicos. |
| Indicadores de certificación de integridad del dispositivo | Preguntas sobre cuánta entropía del usuario se podría transmitir a través de indicadores nuevos y si ciertos casos de uso (como un usuario que accede a su banco) podrían justificar indicadores de entropía más altos. | Nos inclinamos por proporcionar indicadores de alto valor con la menor entropía del usuario posible para preservar su privacidad. |
| Indicadores de certificación de integridad del dispositivo | ¿Este indicador limitaría el acceso a dispositivos más antiguos o a plataformas de código abierto o modificadas? | Cualquier indicador nuevo debe considerar el acceso universal como un principio clave en el desarrollo, y estas son preguntas importantes que debemos abordar de antemano a medida que continuamos con la incubación. |
| Indicadores de certificación de integridad del dispositivo | Había cierta preocupación por si los indicadores nuevos causaban que las empresas de seguridad y prevención de fraudes dependieran demasiado del navegador y las plataformas.
|
Cualquier indicador nuevo debe considerarse como datos complementarios y no como un indicador de "confianza" del navegador. Esperamos que las empresas de seguridad sigan confiando en sus propios datos, modelos y motores de decisión de propiedad con la certificación de dispositivos como una entrada adicional. Con suerte, cualquier indicador nuevo mejorará los esfuerzos de detección en todo el ecosistema y dificultará la ejecución del fraude. |
| Indicador de antigüedad de la cookie | Es un concepto interesante, pero es probable que requiera más investigación sobre los casos de uso aplicables. | Según los niveles de interés, es posible que Chrome desarrolle más la idea de este concepto y la convierta en una explicación para los comentarios futuros del ecosistema. |
| Servidores de confianza para la prevención del fraude | Es un concepto interesante, pero es probable que requiera más investigación sobre los casos de uso aplicables. | Según los niveles de interés, es posible que Chrome desarrolle más la idea de este concepto y la convierta en una explicación para los comentarios futuros del ecosistema. |