Informe trimestral del segundo trimestre de 2022 que resume los comentarios sobre el 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 cuando se agregan los comentarios que recibe Chrome de distintas 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 agradece los comentarios recibidos del ecosistema y explora activamente formas de integrar el aprendizaje en las decisiones de diseño.
Los temas de comentarios se clasifican por prevalencia en cada API. Para ello, se agrega la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Los temas de comentarios comunes se identificaron mediante la revisión de temas de debate de las reuniones públicas (W3C, PatCG, IETF), comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos y los formularios públicos de Google.
Más específicamente, se revisaron las actas de reuniones para las reuniones de organismos estándar de la 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 los ingenieros individuales, la lista de distribución de la API y el formulario de comentarios públicos. Luego, Google coordinó los equipos involucrados en estas diversas actividades de comunicación para determinar la prevalencia relativa de los temas emergentes en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de preguntas frecuentes publicadas, respuestas reales a problemas planteados por las partes interesadas y la determinación de una posición específicamente a los fines de este ejercicio de informes públicos. Para reflejar el 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 del informe actual no tengan una respuesta de Chrome considerada.
Glosario de acrónimos
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- MPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IdP
- Proveedor de identidad
- IETF
- Grupo de trabajo de ingeniería de Internet
- JI
- Dirección de Protocolo de Internet
- openRTB
- Ofertas en tiempo real
- TE
- Prueba de origen
- PatCG
- Grupo comunitario de tecnología publicitaria privada
- RP
- De confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- String de usuario-agente
- UA-CH
- Client Hints de usuario-agente
- W3C
- Consorcio World Wide Web
- WIPB
- ceguera intencional de IP
Comentarios generales, sin API o tecnología específicas
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Cronogramas más claros | Programas de lanzamientos más claros y detallados para las tecnologías de Privacy Sandbox | Establecemos nuestros planes actuales para el programa de implementación en privacysandbox.com y lo actualizamos todos los meses. Se tienen en cuenta el tiempo de desarrollo de Chrome y los desarrolladores web, 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 (lanzamiento), y el tiempo de cada paso se basa en lo que aprendemos y descubrimos en el paso anterior. Si bien por el momento no tenemos publicaciones comprometidas, nos aseguraremos de actualizar nuestro cronograma público en privacysandbox.com. |
| Utilidad para diferentes tipos de interesados | Inquietudes respecto de que las tecnologías de Privacy Sandbox favorecen a los desarrolladores más grandes y de que los sitios especializados (más pequeños) contribuyen más que los genéricos (más grandes). | Entendemos que algunos desarrolladores tienen inquietudes sobre el impacto de las tecnologías de Privacy Sandbox. Google se comprometió a no diseñar ni implementar las propuestas de Privacy Sandbox de una manera que distorsione la competencia a través de la autopreferencia de 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 en los resultados sobre 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 los diseños técnicos. |
| Cronogramas de baja de las cookies de terceros | Solicitudes para evitar un mayor retraso en la baja de las cookies de terceros | Recibimos noticias de algunas partes interesadas que desean que Chrome continúe con la baja de las cookies de terceros sin retrasos, y también otros que creen que se necesita más tiempo para probar y adoptar las tecnologías de Privacy Sandbox. Tenemos el compromiso de seguir adelante con responsabilidad, dada la complejidad de las tecnologías y la importancia de que todo funcione correctamente en el ecosistema. 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 | Recibimos noticias de algunas partes interesadas que desean que Chrome continúe con la baja de las cookies de terceros sin retrasos, y también otros que creen que se necesita más tiempo para probar y adoptar las tecnologías de Privacy Sandbox. Tenemos el compromiso de seguir adelante con responsabilidad, dada la complejidad de las tecnologías y la importancia de que todo funcione correctamente en el ecosistema. Los comentarios de la industria y de los reguladores fueron fundamentales para este proceso. |
| Solicitudes de documentación | Solicitudes de más recursos en los que se detalla cómo administrar las pruebas, el análisis y la implementación | Valoramos que los desarrolladores hayan considerado útil nuestro material actual y nos comprometemos a proporcionar más material, como horarios de atención para desarrolladores y documentación técnica, durante las próximas semanas y meses para que los desarrolladores puedan seguir entendiendo cómo les pueden servir las nuevas tecnologías.
También realizamos sesiones públicas externas en el horario de atención de los desarrolladores para compartir prácticas recomendadas y demostraciones, además de sesiones de preguntas y respuestas con líderes de Ingeniería y Productos para permitir debates y preguntas en vivo. |
| Experiencia en el sector | El equipo de Chrome que trabaja con los organismos de estándares carece de experiencia en el ecosistema de anuncios necesario para equilibrar adecuadamente la privacidad y la utilidad. | Reconocemos que tenemos una gran responsabilidad y dependemos de comentarios específicos para hacerlo bien. También consideramos que la privacidad y la eficacia son criterios de diseño fundamentales y necesarios. En todo el equipo que trabaja en Privacy Sandbox para la Web, la cantidad total de años de trabajo en el ecosistema publicitario está bien, es decir, cientos de años. |
Mostrar anuncios y contenido relevantes
Temas
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Utilidad para diferentes tipos de interesados | Se ha planteado preocupación respecto del valor creado y la distribución de ese valor para los sitios según el nivel de tráfico o la especialización del contenido. | Se explorará la utilidad de la API 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 de 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 la baja de las cookies de terceros. |
| Taxonomía | Las partes interesadas de la industria desean poder opinar sobre la taxonomía. | Chrome sigue abierto para ingresar información en la taxonomía. Chrome está muy interesado en recibir comentarios sobre el modelo de gobernanza para modificar la taxonomía, y en discusiones 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. |
| El historial de navegación no es suficiente | Propuesta para mostrar temas que el emisor vio en semanas anteriores si el usuario no tiene suficiente historial de navegación para crear 5 temas para la semana más reciente | Para nuestro diseño actual, se eligen de forma aleatoria. Investigaremos la correlación con temas anteriores y consideraremos si existe la posibilidad de incorporarlo. Sin embargo, las correlaciones pueden tener consideraciones de privacidad adversas que deben tenerse en cuenta. |
| Cómo llamar a Topics en nombre de un editor | ¿Un proveedor de servicios externo puede compartir Topics con un publicador? | Sí, esa es una forma en la que esperamos que se use Topics. |
| Vectores de ataque potenciales | Identificar los temas más ruidosos | 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 aquellas personas que, de otro modo, no podrían haberlo tenido y para introducir una negación plausible para los usuarios, respectivamente. Reconocemos que esas decisiones tienen desventajas, como el vector de ataque que se describe aquí. Sin embargo, nuestra evaluación es que los beneficios de la privacidad superan los riesgos potenciales. Aceptaremos el debate público sobre esta decisión. |
| Elegibilidad de la prueba de origen | ¿Hay alguna forma de detectar si un usuario es apto para una prueba de origen? | Es posible que una función de prueba de origen no esté disponible para un usuario debido a la configuración del navegador u otros factores, incluso si visita una página web que proporciona un token de prueba válido y su navegador está incluido en el grupo para el que está habilitada la prueba.
Por ese motivo, siempre se debe usar la detección de funciones para comprobar si una función de prueba de origen está disponible antes de intentar usarla. |
| Impactos en el rendimiento | Problemas de sobrecarga y latencia con Topics | Solicitamos comentarios sobre enfoques que permitan evitar iframes de origen X costosos y lentos, y que la propuesta separe la API de Topics de modo que la obtención de temas no cambie el estado de navegación. |
| Funcionalidad de la API de Split Topics | Más control sobre los tres aspectos diferentes de la API | Comprendemos el caso de uso y propusimos una posible forma de resolver esto en GitHub. Actualmente, estamos esperando más comentarios del ecosistema sobre si se compilará la funcionalidad. 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 pública sobre el clasificador aquí.
y aquí Y aquí. |
| Controles del usuario y seguridad | Algunos temas pueden ser representativos de grupos sensibles, por lo que los usuarios necesitan más controles para evitar resultados negativos. | Los temas representan un avance importante en cuanto a la transparencia y el control para los usuarios. Los usuarios podrán inhabilitar temas, revisar los temas que se les asignaron, quitarlos y comprender qué empresas interactúan con sus temas en una página determinada. Además, los usuarios pueden borrar su historial de navegación para afectar sus temas. Aceptamos el debate continuo sobre controles de usuario más avanzados, como los que sugieren los desarrolladores; sin embargo, debemos asegurarnos de que, para las inquietudes planteadas en este error, realmente elimine los riesgos (por ejemplo, eliminar solo el Tema "estudio de lenguaje extranjero", pero no los sitios web que generaron el tema del historial de navegación no protege por completo 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 corta es sí. Aquí se publicó más información. |
| Uso de la API de Topics en un widget de recomendaciones | ¿Podemos usar la API de Topics en el widget de Recommended (p.ej., Outbrain)? | No limitamos el caso de uso de los Topics recuperados después de que se llama a la API (esto dependerá de la política de datos de cada desarrollador). |
| Privacidad / Política | Preguntas relacionadas con el propósito de filtrar las respuestas por emisor en caso de que terceros compartan 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 aquellas personas que, de otro modo, no podrían acceder a ella. Por supuesto, los publicadores y terceros que reciben Topics podrían decidir por sí mismos qué información compartirán con los terceros en su sitio. Si realizan este tipo de uso compartido, Chrome les recomienda que sean transparentes con los usuarios sobre este tipo de uso compartido y les ofrezcan controles. |
| Indicadores ruidosos | Publicar un tema aleatorio el 5% de las veces podría crear demasiado ruido o señales falsas. | El ruido es un método importante para proteger la privacidad del usuario, y a través de pruebas se explorarán los niveles de ruido frente a la utilidad de los temas. |
FLEDGE
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Coordinación de pruebas | Pruebas de impacto en los ingresos y en el rendimiento | En las reuniones públicas de WICG, se debatirá de forma activa el rendimiento de FLEDGE y la forma en que podemos respaldar mejor las pruebas del ecosistema durante las pruebas de origen, así como la disponibilidad general. |
| Servidor de confianza para FLEDGE | ¿Cuándo estará disponible el servidor de confianza para realizar pruebas? | Agradecemos estos comentarios y estamos trabajando activamente en un plan más detallado que podemos compartir para usar los servidores de confianza en FLEDGE. |
| Estandarización de protocolos | ¿Habrá un protocolo común para pasar datos entre las SSP y las DSP, como etiquetas comunes para los grupos de interés? | Agradecemos los comentarios de las DSP, las SSP y el ecosistema de anuncios más amplios sobre la posible estandarización de la especificación. Para realizar las pruebas iniciales en este momento, te recomendamos trabajar directamente con tus socios de prueba, ya que están experimentando con diferentes enfoques. También alentamos y planeamos seguir trabajando con las organizaciones de comercio publicitario a fin de colaborar para crear estandarización en caso de que sea útil para sus empresas miembro. |
| Limitación de frecuencia | Controles de frecuencia por usuario dentro de una campaña y un grupo de anuncios | FLEDGE 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 las limitaciones específicas del sitio también se pueden usar para controlar la limitación de frecuencia adicionales. |
| Impacto de FLEDGE en el rendimiento | Ofertantes con uso intensivo de computación en la subasta de FLEDGE | Chrome está en conversaciones activas con los desarrolladores sobre el impacto potencial en el rendimiento de los sitios. Chrome agradece la oportunidad de aprender más durante las pruebas. |
| Cómo probar 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í.
Un resumen de la reunión es que el diseño actual de la Informes de anuncios de marcos vallados permite asociar un ID generado dentro del marco cercado con información contextual. Por lo tanto, los informes de nivel de evento generados dentro del marco vallado se podrán unir a la misma información contextual en el servidor (mediante 2 uniones del lado del servidor en lugar de 1). |
| Recuento de impresiones | Qué metodología de recuento de impresiones debería o podría usar entre compradores y vendedores | La API de FLEDGE ya admite la alineación en 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 funciona para el ecosistema. |
| Cómo mostrar varios anuncios | Si se pueden mostrar varios anuncios en una subasta dentro de un determinado marco vallado | Actualmente, esto es posible mediante anuncios de componentes (no debe confundirse con las subastas de componentes). Para ello, todos los anuncios deben pertenecer al mismo grupo de interés. |
| Especificación de "Públicos definidos por el vendedor (SDA)" y FLEDGE | ¿FLEDGE podría convertirse en un mecanismo para evitar que los compradores creen perfiles de SDA en solicitudes de anuncios? | FLEDGE está diseñado para evitar la filtración de información que no sea relevante cuando el publicador ya sabe en qué SDA 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 las etiquetas de SDA a la subasta integrada en el dispositivo y una tecnología publicitaria orientada a la compra cree su propio grupo de interés cuya lógica de ofertas diga "Quiero comprar público X". |
| Compatibilidad con monedas distintas de USD | Compatibilidad para probar FLEDGE con monedas superiores al USD | Agradecemos este texto destacado y agregamos recomendaciones para otras monedas en nuestro trabajo pendiente de solicitudes de funciones. Esperamos que esté disponible muy 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. | Debate continuo, incluidas algunas opciones propuestas para admitir, 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 garantizar un campo de juego justo y equitativo. Google prometió, en virtud de los Compromisos, no diseñar, desarrollar ni implementar las propuestas de Privacy Sandbox de maneras que distorsionen la competencia por medio de la autopreferencia de sus productos y servicios publicitarios. Google se toma esto muy en serio y está muy abierto a discutir cualquier inquietud que puedan tener las partes interesadas sobre aspectos específicos de la tecnología. Para obtener más 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 comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | 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 de múltiples puntos de contacto requieren vincular deterministamente 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 estimar la asignación de créditos (p.ej., mediante el uso de prioridades ponderadas y aleatorias) sin hacer un seguimiento de los usuarios individuales. |
| Generación de ruido | Preguntas sobre los niveles de ruido en los informes | Nuestro experimento inicial permite a los desarrolladores establecer su propio valor de épsilon para experimentar cómo cambian los informes en función del nivel de ruido. A partir de ahora, los desarrolladores pueden elegir un valor de épsilon hasta 64. Lo hicimos específicamente para que a los desarrolladores les resultara más fácil probar las APIs y proporcionarnos comentarios sobre los valores de épsilon adecuados.
También hicimos una solicitud pública para esos comentarios. |
| Coordinación de pruebas | ¿Se puede usar la herramienta de pruebas local para la PO? | Sí, la herramienta de prueba local se puede usar durante la PO. La herramienta de prueba local se puede usar con los informes de depuración siempre que haya cookies de terceros disponibles. |
| Ergonomía de las consultas | Habilita la consulta de la agregación de claves | Estamos de acuerdo en que esto parece mejorar la ergonomía de las APIs sin un costo aparente de privacidad. Presentaremos una propuesta y veremos si existe un amplio consenso de que vale la pena respaldarla. |
| Datos menos precisos para sitios pequeños | Los sitios o las campañas más pequeños pueden recibir datos menos precisos. | Chrome reconoce que las protecciones de privacidad basadas en el ruido tienen un mayor impacto en porciones de datos más pequeñas. Sin embargo, es posible que métodos como la agregación durante períodos más largos solucionen este problema. Tampoco resulta 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 recomienda que los verificadores aprovechen la posibilidad de experimentar con una amplia variedad de parámetros de privacidad y ruido para proporcionar comentarios más específicos sobre este problema. |
Limita el seguimiento encubierto
Reducción de usuario-agente
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Protección contra bots | Impacto de la UA-R en la protección de bots | Agradecemos estos comentarios y estamos en proceso de recopilar información sobre los enfoques de protección de bots para fundamentar nuestros futuros diseños. |
| Dependencias de implementación | Cómo abordar dependencias de implementación de usuario-agente (SUA) estructuradas | Lanzamos la "Fase 4", también conocida como reducción de versiones secundarias, al 100% de los usuarios de Chrome en las versiones 101 y superiores. Consulta actualizar aquí. |
Client Hints de usuario-agente
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Cómo enumerar todas las sugerencias compatibles | Me interesa tener una manera programática de conocer todas las sugerencias compatibles para un navegador. | Agradecemos tus comentarios y estamos en el proceso de evaluar la solicitud de función. Nos interesa saber si este es un caso de uso común. |
| Flexibilidad de los encabezados de UA-CH en comparación con los encabezados de usuario-agente | UA-CH es demasiado prescriptivo en comparación con la flexibilidad que ofrece el encabezado de usuario-agente, según se define en rfc7231. | Chrome considera que la naturaleza prescriptiva de los encabezados UA-CH es una mejora importante en relación con la flexibilidad de la cadena de UA, tanto desde el punto de vista de la eventual interoperabilidad entre navegadores como de la protección de la privacidad del usuario (ya que evita las adiciones arbitrarias de identificadores de alta entropía).
El problema permanecerá abierto en caso de que otras personas también compartan esta preocupación y quieran enviar comentarios. |
| UA-CH: Inquietudes contra el fraude y el abuso contra el abuso | Algunas funciones que pueden perderse con UA-CH: la herramienta de seguimiento de redireccionamiento de clics y los clics fraudulentos. | El equipo está investigando estos posibles problemas con las partes interesadas en la lucha contra el fraude y las mediciones. |
| Rendimiento | Existe preocupación respecto de la latencia que se genera para obtener sugerencias a través del canal Critical-CH (en la primera carga de la página). | Chrome está investigando formas de mejorar el rendimiento. |
Gnatcatcher (en construcción)
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | 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 y la latencia del usuario. Estamos dispuestos a recibir comentarios y nos encantaría que se profundice en los foros de W3C. |
| Protección contra fraudes y bots | Impactos en la protección contra fraudes y bots, incluso en países menos desarrollados | La seguridad es un requisito fundamental, ya que buscamos maneras de mejorar la privacidad del usuario de maneras significativas, como el uso de direcciones IP por proxy. Un proxy de dos saltos que se asocia con empresas reconocidas proporciona privacidad del usuario comprobable. También estamos desarrollando ideas para generar 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 nacional dificultan el cumplimiento de regímenes locales más detallados | Publicamos nuestros principios propuestos de forma pública, que incluyen enfoques posibles que permitirían que los sitios web cumplan con los requisitos locales. |
Fortalecer los límites de privacidad entre sitios
Conjuntos propios
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Utilidad para diferentes tipos de interesados | Impacto de FPS para publicadores pequeños en comparación con grandes editores | El objetivo principal de Privacy Sandbox es mejorar la privacidad del usuario reemplazando las prácticas actuales por soluciones que no se basen en mecanismos de seguimiento entre sitios. Queremos que estas soluciones sean lo más útiles posible para los distintos tipos y tamaños de interesados. Aceptamos aportes específicos y prácticos sobre cómo podemos mejorar estas soluciones, y esperamos que continúen desarrollándose con las discusiones y pruebas de la comunidad. |
| Mejoras en la privacidad | Demasiados sitios en el mismo conjunto podrían tener resultados similares a los de las cookies de terceros. | Apreciamos estos comentarios. Estamos evaluando cuáles podrían ser los límites correctos y, al mismo tiempo, tratamos de brindarles a los usuarios y desarrolladores un tratamiento o indicadores que les permita comprender cuándo se alcanza dicho límite. Aún no tenemos una propuesta específica para compartir, pero esperamos hacerlo muy pronto. |
| Compatibilidad del ecosistema con FPS | Recopilación de asistencia y preocupaciones para seguir desarrollando FPS fuera de los CG sobre privacidad | Si bien hubiéramos preferido que la propuesta de conjuntos propios permanezca en PrivacyCG, esperamos continuar con la propuesta en WICG. También nos animaron las numerosas declaraciones de apoyo para un debate continuo sobre los conjuntos propios y los casos de uso que están destinados a abordar. Google sigue comprometido a encontrar soluciones que permitan que la Web continúe creciendo y prosperando de forma que proteja y respete la privacidad del usuario. |
| Interoperabilidad del navegador | Implementación en otros navegadores | Reconocemos la importancia de la interoperabilidad de los navegadores para los desarrolladores y continuaremos colaborando con otros navegadores a fin de lograr la estandarización de los FPS. |
| Requisito común de la política de privacidad | Es inviable mantener una política de privacidad común para todos los productos y todas las jurisdicciones que deben formar parte del mismo conjunto. | Chrome aún está definiendo los requisitos de nuestra política y tendrá en cuenta estos comentarios. |
API de Fenced Frames
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Solicitud de documentación | Diferencias con los iframes de zona de pruebas | Agradecemos los comentarios y las sugerencias. Actualmente, hay una conversación sobre este tema en GitHub, donde esperamos tener claridad sobre la solicitud para poder evaluarla por completo. El debate público está disponible aquí. |
| Capacidades entre APIs | Compatibilidad predeterminada con los Informes de atribución en marcos cercados | Solicitamos comentarios sobre una propuesta para permitir que la API de Attribution Reporting use el "modo de anuncios opacos" de marcos cercados de forma predeterminada. Alentamos a los desarrolladores a quienes este les interesaría analizar la conversación. |
API de Shared Storage
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | 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 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, tanto las claves como los valores estarán limitados a 1024 caracteres char16_t cada uno y un límite de 10,000 entradas por origen con un mecanismo que evite que se confirmen entradas adicionales cuando la capacidad de un origen esté completa. Solicitamos activamente comentarios sobre los límites específicos propuestos aquí. |
| Transparencia para el usuario | Transparencia del usuario respecto de las fuentes de datos en comparación con el uso de datos | Agradecemos tus comentarios y creemos que 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 comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Impedimentos para la adopción | ¿CHIPS se debe vincular al nombre de host? (el requisito sin dominio) | Quitaremos este requisito del equipo de OT en función de los comentarios de los participantes del equipo de OT que indican que este requisito agregaba complejidad adicional y constituye 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 Google Ads para CHIPS | ¿Se puede usar CHIPS para los casos de uso de Google Ads en un solo sitio? | El seguimiento de usuarios en un sitio es un caso de uso permitido. Actualizamos nuestro artículo para desarrolladores a fin de destacar este caso de uso. |
| Incorporaciones autenticadas | ¿Se preserva el estado de acceso con CHIPS? | Actualmente, el estado de acceso no se conserva, pero no es el caso de uso previsto para CHIPS. Conocemos el caso de uso de las 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 PO sea válido y esté presente en los encabezados de las páginas visitadas, la función debe estar disponible para los usuarios, sin que se requiera ninguna acción adicional. |
| Compatibilidad del navegador | Interés en comprender cómo otros navegadores han manejado los atributos de cookies particionados | Chrome sigue funcionando dentro de grupos de estándares públicos como W3C para identificar diseños e implementaciones que pueden funcionar en todos los navegadores. |
FedCM
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Vectores de ataque potenciales | Posibles vectores de ataque mediante la decoración de vínculos y los ataques de tiempo | Recopilamos activamente comentarios del público y estamos investigando posibles formas de abordar este problema. |
| UX para permitir múltiples IdP | Solo se puede presentar un IdP a la vez | Creemos en la asistencia a varios IdP y estamos trabajando activamente en enfoques para respaldar |
| Expresividad | Preocupación de que, debido a que el navegador representa parte del flujo de identidad federada, resulta difícil captar todos los matices que los IdP quisieran mostrar a sus usuarios. | Chrome está explorando la posibilidad de incluir personalizaciones de marca (por ejemplo, logotipos y colores) y de cadenas (por ejemplo, "acceder a este artículo" en lugar de "acceder con").
Chrome reconoce el inconveniente y continuará trabajando con el ecosistema para abarcar tantos temas como sea posible y hacerlo lo más expresivo posible. |
| Interoperabilidad y aplicabilidad | Te preocupa que otros navegadores no adopten ni implementen FedCM. | Chrome también ha estado trabajando con otros proveedores de navegadores a fin de encontrar soluciones comunes para la federación en el FedID Community Group. |
| 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 su correo electrónico, foto y nombre se compartirán
(2) El registro de casos de uso es escaso en su experiencia del usuario y selección de reclamaciones del IdP. |
Estamos de acuerdo y estamos explorando cómo implementar los comentarios de una manera más amigable con el usuario y con mayor privacidad. |
| Interacción del usuario con el IdP | Necesidad de interacción directa entre el usuario y el IdP si se supera un umbral de riesgo | Estamos investigando activamente estos comentarios. |
Particionamiento del estado de la red
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Rendimiento | La partición del estado de la red podría aumentar las conexiones a las CDN que hacen un uso intensivo de los recursos. | Aún estamos investigando las características de rendimiento del particionamiento del estado de la red, lo que incluye medir diferentes esquemas de claves posibles. Aún no hemos tomado una decisión entre las compensaciones de rendimiento, seguridad y privacidad, y necesitamos recopilar más datos. |
Combate el spam y el fraude
API de Trust Tokens
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Comentarios regulatorios | Inquietudes sobre la inversión de tiempo y recursos en tokens de confianza sin indicadores claros de los reguladores sobre la viabilidad a largo plazo | Nuestro objetivo es crear tecnología que funcione para el ecosistema, haciendo que los comentarios de la industria y los reguladores sean fundamentales para el proceso. Seguiremos consultando con 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 basadas en su propia evaluación de los requisitos reglamentarios. |
| Tiempo de lanzamiento | ¿Cuándo se lanzarán los tokens de confianza en DG? | Brindamos las estimaciones actuales para la entrega en nuestro cronograma público en privacysandbox.com. En cuanto tomemos una decisión definitiva sobre su fecha de entrega en DG, la publicaremos a través de los procesos de lanzamiento de Chrome y actualizaremos el cronograma en el sitio web. |
| Tokens de confianza en comparación con otros | Qué función desempeñan los tokens de confianza según los otros tokens que están en proceso de estandarización, como los tokens de acceso privado | Participamos en debates sobre la estandarización, y nuestro objetivo es alinearnos con otras iniciativas tanto como sea posible y, al mismo tiempo, habilitar los diferentes casos de uso que permite cada tecnología. Por ejemplo, los tokens de confianza y los tokens de acceso privado se basan en el protocolo de Privacy Pass. |
| Límites de datos | Máx. 2 emisores para el canje de tokens por página potencialmente limitando | Estamos buscando opciones a largo plazo donde podamos permitir que las empresas canjeen tokens de forma segura sin arriesgarse a aumentar la entropía del usuario, tal vez mediante la partición del acceso al canje de tokens. |
| Restricciones de acceso | Solo los orígenes aprobados (y verificados/no falsificados) deben poder verificar la presencia de un token y canjear | Estamos explorando enfoques para determinar quién puede ver y canjear tokens. |
| Asistencia para dispositivos | Las dependencias del tiempo de ejecución de JavaScript limitan el uso en ciertos dispositivos. ¿Se puede extender la compatibilidad de TT para que funcione en otros tipos de dispositivos? | Esto es algo que podríamos tener en cuenta para el desarrollo futuro y un tema que nos encantaría recibir más comentarios de los desarrolladores en los foros del W3C. También tenemos un problema abierto para analizar el canje de tokens activado por un encabezado HTTP sobre el que solicitamos comentarios. |
| Casos de uso | No están claros cuáles son los casos de uso adecuados de los tokens de confianza. Falta de claridad sobre los usos previstos. | Nuestro objetivo es facilitar la innovación dentro de la lucha contra el fraude y comprender que cada empresa puede emplear técnicas propias con tokens de confianza, por lo que no hemos sido prescriptivos con respecto 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 | Quitar la política de funciones “trust-token-redemption” debería aumentar significativamente la cobertura del token de confianza. | Esto se tiene en cuenta a la hora de recopilar comentarios de OT y tomar decisiones sobre los próximos pasos. |
| Fideicomiso de la entidad emisora | ¿Por qué deberíamos confiar en los sitios web que emiten tokens de confianza? | No existen lineamientos para convertirse en una entidad emisora, y cualquiera puede hacerlo. Se espera que los publicadores solo trabajen con entidades emisoras de confianza. Además, en el futuro, otras entidades legítimas del ecosistema de anuncios descontarían (o dejarían de comprar) el tráfico asociado con entidades emisoras desconocidas o sospechosas. |
| Servicios incorporados de terceros | ¿Pueden los servicios incorporados de terceros 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 se pueden compartir los indicadores de confianza con otras empresas. | Los tokens de confianza están diseñados para ser una primitiva de bajo nivel, y los emisores o redireccionamientos que cooperan pueden utilizarlos para compartir indicadores de confianza y reputación. |
| Sobrecarga de mantenimiento | La implementación criptográfica subyacente de las operaciones de tokens de confianza se encuentra en BoringSSL, que es el único encargado de Google. ¿Cómo se gestionará el mantenimiento de la biblioteca? | Los tokens de confianza se basan en operaciones criptográficas estandarizadas (consulta el protocolo de Pase de privacidad) que también se pueden implementar en otras bibliotecas. Recomendamos que los desarrolladores soliciten, desarrollen o mantengan asistencia para estas operaciones en las bibliotecas que elijan. |
| Sobrecarga de mantenimiento | No está claro cuánto tiempo se admitirán las versiones de protocolo | Estamos trabajando para desarrollar y documentar más detalles específicos sobre los plazos previstos de asistencia para las versiones de protocolo. |
| Límites de la entidad emisora | Si avanzas en la cadena, es posible que no surja la oportunidad de ejecutar tokens de confianza. | A medida que más organizaciones comienzan a usar tokens de confianza, podíamos ver cada vez más estos tipos de dinámicas de tiempo en juego y estamos investigando posibles soluciones. Como se describió anteriormente, estamos buscando opciones a largo plazo con 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 pedido de carga. |
Nuevas soluciones contra el fraude en la incubación
| Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Indicadores de certificación de integridad de dispositivos | Por lo general, es un gran respaldo para la búsqueda de indicadores de integridad de dispositivos certificados por plataformas y disponibles en la Web. | Seguiremos recopilando comentarios y aplicando la propuesta a través del diseño y la iteración públicos. |
| Indicadores de certificación de integridad de dispositivos | Preguntas sobre la entropía de los usuarios que se podría transmitir a través de indicadores nuevos y si ciertos casos de uso (como cuando un usuario accede a su banco) podrían justificar señales de entropía más alta. | Para preservar la privacidad de los usuarios, nos inclinamos a proporcionar indicadores de alto valor con la menor entropía del usuario posible. |
| Indicadores de certificación de integridad de dispositivos | ¿Este indicador limitaría el acceso para dispositivos más antiguos o 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 se deben abordar de antemano a medida que continuamos con la incubación. |
| Indicadores de certificación de integridad de dispositivos | Nos preocupaba la posibilidad de que las nuevas señales hicieran que las empresas de seguridad y antifraude dependan demasiado del navegador y las plataformas
|
Todos los indicadores nuevos deben considerarse datos complementarios y no una indicación de "confianza" por parte del navegador. Esperamos que las empresas de seguridad sigan utilizando sus propios datos, modelos y motores de decisión de su propiedad con la certificación de dispositivos como entrada adicional. Esperamos que cualquier indicador nuevo mejore los esfuerzos de detección en todo el ecosistema y dificulte la ejecución de fraudes. |
| Indicador de 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, Chrome puede seguir ideando este concepto y crearlo en una explicación para futuros comentarios sobre el ecosistema. |
| Servidores confiables y antifraude | 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, Chrome puede seguir ideando este concepto y crearlo en una explicación para futuros comentarios sobre el ecosistema. |