Informe trimestral del tercer 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
- Tiempo Sup.
- 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 | Resumen | Respuesta de Chrome |
| (También se informa en el segundo trimestre)
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). | Actualización del P3:
Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de manera que no distorsione la competencia prefiriendo el propio negocio de Google y a tener en cuenta el impacto en la competencia de publicidad digital y en los publicadores y anunciantes, independientemente de su tamaño. 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. Trabajamos con la CMA para desarrollar nuestro enfoque sobre las pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño del experimento para proporcionar más información a los participantes del mercado y la oportunidad de comentar los enfoques propuestos. |
| (También se informa en el segundo trimestre)
Solicitudes de documentación |
Solicitudes de más recursos que detallan cómo administrar las pruebas, el análisis y la implementación | Actualización del P3:
Valoramos que los desarrolladores hayan encontrado útil nuestro material actual y nos comprometemos a proporcionar más material durante las próximas semanas y meses para que puedan seguir entendiendo cómo les pueden servir las nuevas tecnologías. También realizamos sesiones de consulta públicas para desarrolladores a fin de compartir prácticas recomendadas y demostraciones, junto con sesiones de preguntas y respuestas con líderes de ingeniería y productos para permitir debates y preguntas en vivo. |
| Compatibilidad con varios navegadores | Otros proveedores de navegadores que ya adoptaron las APIs de Privacy Sandbox | Otros proveedores de navegadores, como Apple, Mozilla y Microsoft, participan de forma activa en foros públicos donde se discuten los principios de privacidad y los enfoques basados en el navegador. Nos alientan los debates colaborativos en foros como la reciente reunión anual de TPAC del W3C y los foros en curso de PATCG del W3C, en los que vemos señales de convergencia. |
| Diferencias entre plataformas | Solicita alinear conjuntos de funciones en la Web y Android tanto como sea posible para ayudar a reducir los recursos necesarios para la transición. | Estamos trabajando para alinear nuestros enfoques en Chrome y Android, y así evitar crear confusión o fragmentación en la industria. Cualquier diferencia en nuestro enfoque se debe en gran medida a las diferencias técnicas necesarias entre las plataformas web y de aplicaciones para dispositivos móviles que los desarrolladores ya tendrán en cuenta. |
| Recursos para probar las APIs de Privacy Sandbox | Dificultades para asignar suficiente
para probar las APIs de Privacy Sandbox según las dificultades económicas actuales. |
Google mejora continuamente la documentación y la asistencia disponibles para los verificadores a fin de simplificar la complejidad y facilitar la adopción de las APIs. Estos esfuerzos incluyen listas de distribución específicas de la API, horarios de atención y actualizaciones continuas en developers.chrome.com. |
| Indicador de inhabilitación de la API de Sandbox | Solicita proporcionar un indicador que indique que el usuario inhabilitó las APIs de la zona de pruebas, que la tecnología publicitaria y los sitios web pueden usar. | Observamos muchos casos históricos en los que los sitios web reaccionan a las elecciones de los usuarios, como "desactivar las cookies de terceros", presionándolos para que cambie su configuración, a veces bloqueando el acceso al sitio web, a menos que esto suceda. También se puede usar un indicador de rechazo como un indicador adicional para la creación de huellas digitales. En este momento, Google no tiene la intención de proporcionar un indicador de inhabilitación. |
| (También se informa en el segundo trimestre)
Cronogramas más claros |
Programaciones de lanzamientos más claras y detalladas | Actualización del P3:
Como se explica en la sección Cambios en respuesta a los comentarios que aparece a continuación, Google actualizó el cronograma de Privacy Sandbox en julio a fin de darle al mercado más tiempo para realizar pruebas y comentarios preliminares, así como más tiempo para realizar pruebas una vez que se lancen por completo las APIs de Privacy Sandbox antes de que las cookies de terceros dejen de estar disponibles. |
| (También se informa en el segundo trimestre)
Cronogramas de baja de las cookies de terceros |
Solicitudes para evitar un mayor retraso en la baja de las cookies de terceros | Actualización del P3:
En julio, Chrome anunció un cronograma actualizado para la baja de las cookies de terceros, que reflejaba nuestro compromiso de actuar con responsabilidad debido a la complejidad de las tecnologías y su importancia para el ecosistema. Antes de este cambio, tuvimos en cuenta los comentarios de los reguladores y la industria, y seguimos trabajando estrechamente con todas las partes interesadas. |
| Cookies propias | ¿También se proponen restricciones para las cookies propias? Si esto sucede, las inquietudes sobre la estabilidad a largo plazo, el riesgo de sufrir más cambios impredecibles en el navegador y, por lo tanto, el esfuerzo de ingeniería desperdiciado ahora. | No tuvimos en cuenta ninguna restricción de cookies propias. Privacy Sandbox se enfoca en dar de baja las cookies de terceros. |
Mostrar anuncios y contenido relevantes
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
| (También se informa en el segundo trimestre)
Utilidad para diferentes tipos de interesados |
Se ha planteado preocupación respecto de la utilidad para los sitios según su nivel de tráfico o cuán especializado es su contenido. | Actualización del P3:
Se explorará la utilidad de la API a través de pruebas. De conformidad con el párrafo 17.c.ii de los Compromisos, Google compartirá los resultados de esas pruebas con la CMA. 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. |
| Privacidad/Política | Solicitud para quitar el requisito de filtrado de temas por emisor. | En función de los comentarios de los líderes de opinión, los defensores de la privacidad, los expertos en seguridad, los grupos de derechos digitales y otros miembros del ecosistema, Chrome eligió este diseño para otorgar acceso a la información solo a aquellos que de otro modo lo tenían. Los motivos de esto incluían, entre otros, limitar la filtración incremental de datos en distintas partes, garantizar la transparencia y explicabilidad, adoptar un enfoque fácil de implementar y describir, y limitar el riesgo de la creación de huellas digitales. Los publicadores y terceros que reciben Topics pueden decidir por sí mismos qué información compartirán con los terceros en su sitio. Si un tercero comparte esta información, Chrome le recomienda encarecidamente que sea transparente con los usuarios sobre este tipo de uso compartido y les ofrezca controles. |
| Sitios categorizados incorrectamente | Los sitios están en una categoría incorrecta con el tema equivocado, lo que puede generar una segmentación de anuncios imprecisa. | Los sitios se clasifican mediante una combinación de una lista de anulación seleccionada por humanos que contiene los sitios más populares y un modelo de AA integrado en el dispositivo. Chrome continúa evaluando opciones para que los sitios contribuyan a la clasificación de Topics. Todas las mejoras en la utilidad se deben comparar con los riesgos de privacidad y abuso. Por ejemplo, algunos de los riesgos incluyen:
El público puede inspeccionar estos componentes, con herramientas disponibles a través de chrome://topics-internals o este colab. A través de las pruebas, esperamos que la clasificación mejore con el tiempo y agradecemos los comentarios de ejemplos de sitios que podrían estar en una categoría incorrecta. |
| Requisitos de acceso | El requisito de Topics actual para la entidad DOM en la página como secuencia de comandos o iframe para obtener acceso puede generar comportamientos no deseados por parte de los jugadores en el ecosistema de anuncios. | Combinamos un cambio en la explicación de GitHub. Tenemos la intención de admitir temas en encabezados HTTP. |
| La taxonomía de temas no es lo suficientemente detallada | Las clasificaciones de temas actuales son demasiado amplias y no incluyen temas más detallados, como los temas regionales. | Las mejoras en la taxonomía son un esfuerzo continuo, y esperamos que evolucione con las pruebas y los aportes de los ecosistemas.
Estamos buscando comentarios activamente sobre la taxonomía que sería más útil para el ecosistema. Cuando se evalúa si se debe ampliar la cantidad de temas o incluir temas más detallados, se deben tener en cuenta 1) las posibles implicaciones para la privacidad (p.ej., más temas podrían generar un riesgo para la creación de huellas digitales) y 2) la capacidad de recuperar temas ya observados (p.ej., con más temas, hay menos posibilidades de que una plataforma de tecnología publicitaria haya visto el tema elegido en el pasado). A partir de la expansión en #2, Google busca maximizar la capacidad de los emisores de recuperar temas ya observados, dentro del requisito de filtrado existente, con el objetivo de lograr utilidad y privacidad. |
| Límite de temas | Tres temas por sitio web es muy poca información para los anunciantes para publicar anuncios. | Los comentarios del ecosistema, en especial los de las pruebas de origen, seguirán influyendo en la evolución de la API. Vale la pena señalar que se espera que Topics complemente otros indicadores, como el contexto, a fin de ayudar a encontrar un anuncio adecuado para el visitante. Por lo tanto, puede haber más información disponible para el anunciante además de los temas. |
| (También se informa en el segundo trimestre)
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. | Actualización del P3:
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 sus temas si borran su historial de navegación, del que se derivan los temas. Actualmente, estos controles están implementados en el navegador Chrome a nivel del dispositivo. Aceptamos debates continuos sobre controles de usuario más avanzados, como los que sugieren los desarrolladores. Sin embargo, debemos asegurarnos de que las nuevas incorporaciones estén bien calibradas para abordar las inquietudes presentadas y que no generen cambios graduales. |
| Impacto en la SEO | Si los publicadores ajustan los nombres de host de su sitio web para reflejar mejor los temas, pueden tener un impacto negativo en la SEO. | Advertimos a los sitios que no cambien sus nombres de host solo para usar Topics. Es cierto que un sitio puede influir de esta manera en los temas asignados. Sin embargo, en el mejor de los casos, los beneficios de hacerlo no están claros y socavaría el valor de Topics para todo el ecosistema si los sitios intentaran "manipular" el modelo de clasificación. Las asignaciones de temas tampoco son fijas; esperamos que la taxonomía continúe evolucionando con las pruebas y las entradas. En relación con estas pruebas, fomentamos los comentarios, incluidos los ejemplos de sitios que puedan estar en una categoría incorrecta. |
| Fraude y abuso | Asegúrate de que la parte que compra verifique que el tema que ve realmente sea generado por el navegador. | Agradecemos la sugerencia de admitir un mecanismo para que los compradores de tecnología publicitaria verifiquen los temas que pasaron los vendedores en las subastas de publicidad programática. Alentamos al ecosistema a participar en el debate activo aquí. Si bien actualmente nos centramos en otras mejoras de mayor prioridad, reconocemos que esta podría ser una adición importante al diseño en el futuro. |
| Fraude y abuso | Permite la revisión pública de las partes que son usuarios legítimos de los datos de Topics mediante el mismo tipo de publicación y opinión públicas al que estaría sujeto un conjunto propio. | Agradecemos la sugerencia y estamos de acuerdo en que la responsabilidad pública es una herramienta importante para lograr los objetivos de Privacy Sandbox. Las llamadas a la API de Topics son públicas de forma inherente, ya que cualquier persona puede visitar un sitio y observar las llamadas de un dominio a la API de JavaScript. Por lo tanto, las personas y las organizaciones pueden ver la actividad relevante y evaluar qué sitios usan Topics y cómo lo hacen. Creemos que este es un mejor enfoque que evaluar la "legitimidad" de un sitio como parte de la funcionalidad de la API de Topics en sí misma. |
| Impacto en los indicadores propios | Los indicadores de temas pueden ser muy valiosos y, por lo tanto, desvaloran otros indicadores propios basados en intereses. | Creemos que la publicidad basada en intereses es un caso de uso importante para la Web, y Topics está diseñado para admitirlo. Como se describió anteriormente, otras partes interesadas del ecosistema expresaron su preocupación respecto de que Topics podría no ser lo suficientemente útil para proporcionar valor. En todos los casos, las mejoras en la taxonomía son un esfuerzo continuo, y esperamos que evolucione con las pruebas del ecosistema y los aportes de datos. |
FLEDGE
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Subasta de FLEDGE | ¿Cómo pueden las SSP dar formato a los datos que se envían a Google Ads para ofertar en una subasta de FLEDGE? | Se recomienda a las empresas que participan en las pruebas que publiquen documentación sobre sus planes de pruebas y que trabajen juntas cuando corresponda.
Trabajamos con la CMA para desarrollar nuestro enfoque sobre las pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño del experimento para proporcionar más información a los participantes del mercado que planean participar en las pruebas y una oportunidad para comentar los enfoques propuestos. El equipo de Ad Manager publicó aquí documentación para los vendedores interesados en probar FLEDGE con publicadores que usan Ad Manager como servidor de anuncios. Encuentra detalles técnicos adicionales que se describen aquí. |
| FLEDGE en marcos protegidos anidados | Los marcos cercados permiten realizar pruebas menos restrictivas y restringir más en un futuro indefinido. Este cronograma desconocido presenta un desafío para el ecosistema. | Actualmente, las empresas pueden probar FLEDGE con marcos protegidos. Para proporcionar una opción de integración más fácil, las empresas pueden optar por implementar FLEDGE primero. Después de implementar FLEDGE, pueden probar marcos protegidos con su diseño de FLEDGE. |
| Política de manejo de datos | ¿Cuál es la política de manejo de datos para los grupos de interés y FLEDGE? | En el diseño de FLEDGE, todos los datos almacenados en grupos de intereses, o sobre qué personas están en cada grupo de intereses, permanecen en el dispositivo. Estos datos no se envían a un servidor de Google.
Algunas protecciones de la privacidad que Chrome planifica para FLEDGE implican la interacción con un servidor de k-anonimato ejecutado por Google. Esa interacción se está diseñando cuidadosamente para evitar compartir información sobre los usuarios y que se ejecute en un entorno de ejecución confiable (TEE) para garantizar la paridad de información en todo el ecosistema de anuncios. \ Google se comprometió a la CMA a diseñar e implementar las propuestas de Privacy Sandbox de manera que no distorsione la competencia prefiriendo el negocio de Google y a tener en cuenta el impacto en la competencia de la publicidad digital y en los publicadores y anunciantes. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos. |
| Políticas de edad | ¿Cómo se asegura Chrome de que los públicos creados por FLEDGE cumplan con las restricciones de edad? | Los publicadores y anunciantes están mejor posicionados para evaluar si los públicos que crean con FLEDGE satisfacen las leyes aplicables. A fin de proteger aún más a los usuarios, las APIs de Privacy Sandbox no estarán activas para ningún usuario que acceda a Chrome si la edad asociada con su cuenta es menor de 18 años, incluso durante el período de prueba. (en el caso de los usuarios que salieron de sus cuentas, Chrome no recopila indicadores de perfil que permitan que el navegador infiera la edad del usuario). |
| Servicios de par clave-valor de FLEDGE | Hay más claridad sobre lo que permitirá el servicio de par clave-valor de FLEDGE, como la cantidad de claves y la frecuencia con la que se pueden actualizar. | Las empresas que usan FLEDGE pueden tener todas las claves que quepan en la RAM. Para obtener más detalles, consulta la explicación aquí.
Estamos buscando proporcionar una ruta más rápida para modificar los datos y recibir sugerencias para todos los requisitos. |
| Prueba | Es difícil probar FLEDGE con Google Ads | Consulta la documentación de integración de Google Ads para saber cómo participar y realizar pruebas de la mejor manera en la prueba de origen. |
| API de servicios de ofertas y subastas | ¿Cuál es la dirección de Google para la API de servicios de ofertas y subastas? ¿Tendrá prioridad por encima o por debajo del FLEDGE del navegador Chrome en las subastas de dispositivos? | Mantenemos nuestro compromiso con el diseño actual de ofertas integradas en el dispositivo de FLEDGE. Se propuso que los servicios de ofertas y subastas exploren posibles soluciones para admitir un subconjunto de casos de uso en los que la potencia de procesamiento o la velocidad de la red del dispositivo puedan ser limitadas. |
| Informes globales | Solicita admitir informes agregados en función de todos los indicadores disponibles para generateBid. | Pronto compartiremos más información al respecto. |
| Anuncios contextuales | Se publican anuncios contextuales con FLEDGE. | Consideramos esta opción y, por los motivos que se explican en esta discusión, actualmente, no recomendamos usar FLEDGE para los anuncios contextuales. |
| Pruebas en el mundo real | Orientación sobre cómo aislar FLEDGE de las cookies de terceros para realizar pruebas en el mundo real. | Estamos investigando formas de proporcionar poblaciones de prueba.
Trabajamos con la CMA para desarrollar nuestro enfoque sobre las pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño del experimento para proporcionar más información a los participantes del mercado y la oportunidad de comentar los enfoques propuestos. |
| Prueba de FLEDGE y la API de Attribution Reporting | ¿Cuál es la mejor manera de implementar la API de Attribution Reporting con FLEDGE? ¿Es una buena idea separar FLEDGE y Attribution o realizar pruebas en conjunto? | Más adelante, admitiremos las pruebas de FLEDGE y la API de Attribution Reporting como una solución integrada, pero recomendamos a los desarrolladores que primero prueben la API de Attribution Reporting de forma independiente y, luego, con FLEDGE cuando se complete la integración. |
| Visibilidad del precio de la oferta | Solicitud para ofuscar los precios de ofertas. | Es posible establecer puntos de interrupción en `generateBid()` o `scoreAd()` para acceder a los valores de oferta de Herramientas para desarrolladores. El equipo de Chrome consideró el vector de ataque limitado presentado en estos comentarios sobre FLEDGE. Sin embargo, los modelos de seguridad y privacidad de Chrome consideran a los usuarios en los que se puede confiar en que hagan lo que quieran con la información de su propio dispositivo y, por lo tanto, no hay una manera factible de ocultar los datos de ofertas como se solicita. |
| Solicitudes de documentación | Documentación y ejemplos para realizar pruebas en un ecosistema en vivo. | Valoramos que los desarrolladores hayan encontrado útil nuestro material actual y nos comprometemos a proporcionar más material durante las próximas semanas y meses para que puedan seguir entendiendo cómo les pueden servir las nuevas tecnologías.
También organizamos sesiones de consulta públicas externas para desarrolladores con el fin de compartir prácticas recomendadas y demostraciones, además de sesiones de preguntas y respuestas con líderes de ingeniería y productos, de modo que se puedan realizar discusiones y preguntas en vivo. |
| API de Private Aggregation | ¿Deseas obtener más información sobre la API de Private Aggregation? | Hay una explicación pública disponible con la información más reciente que podemos compartir en este momento. Se proporcionará más documentación a medida que se desarrolle la API y se definan los casos de uso. |
| Latencia de datos | ¿La recuperación de datos del servidor de par clave-valor de FLEDGE se realizará en tiempo real? | Es posible que el servidor pueda mostrar un poco de inactividad del orden de minutos, no horas, antes de que el servidor pueda mostrar los datos actualizados para las consultas, como se explica en un problema abierto de GitHub. También queremos recibir comentarios de los desarrolladores. |
| Servicios de ofertas y subastas | ¿Los precios de las ofertas se ocultarán para el usuario si se utilizan los servicios de ofertas y subastas (B&A)? | Para el enfoque del servidor de B&A, el usuario no puede ver el precio de la oferta individual, ya que la solicitud de oferta se realiza directamente desde el servicio de subastas de la SSP al servicio de subastas de DSP y, por lo tanto, ya no está disponible en el navegador.
Sin embargo, el precio de la oferta ganadora seguirá siendo visible para el navegador (se trata en más detalle más arriba en relación con las solicitudes para ofuscar precios de ofertas). |
| Servicios de ofertas y subastas | ¿Cómo podemos balancear la carga de los servicios de ofertas y subastas? | En este momento, no tenemos orientación sobre el balanceo de cargas, pero es una preocupación importante desde la perspectiva de rendimiento y privacidad. Proporcionaremos más detalles en el futuro. |
| Límites de FLEDGE | Solicite aumentar el límite de duración de joinAdInterestGroup de 30 a 90 días. | Creemos que el período de retención de datos de 30 días está alineado con otras APIs de publicidad de Privacy Sandbox, como el límite de 30 días en Attribution Reporting y la retrospectiva de 3 semanas en Topics. Este período aborda tanto las necesidades de la tecnología publicitaria como las expectativas de privacidad de los usuarios.
Sin embargo, agradecemos que nos envíes más comentarios a medida que seguimos analizando el problema aquí. |
| Almacenamiento compartido en FLEDGE | ¿Es posible usar la API de Shared Storage en FLEDGE? | Tenemos la intención de admitir la API de Shared Storage en FLEDGE en el futuro y estamos trabajando para que esté disponible en una próxima prueba de origen. |
| Control de frecuencia por clics | ¿Es posible tener una limitación de frecuencia por clics (no por ejemplo) en FLEDGE? | FLEDGE especifica que un marco vallado puede llamar a navigator.leaveAdInterestGroup() (sin parámetros) para abandonar el grupo de interés que hizo que se mostrara el anuncio. Esta llamada se puede realizar la primera vez que se recibe un clic para evitar ofertas futuras, como una forma de limitación de frecuencia. En la actualidad, esta solución no funcionaría para la limitación después de más de un clic. |
| FLEDGE en marcos protegidos anidados. | No se pueden informar los clics mediante los Informes de anuncios de marco vallado si se producen en un marco vallado anidado. | Publicamos una propuesta para corregir el problema aquí. |
| Medida | Se necesita orientación para recopilar datos de latencia de los ofertantes en una subasta de FLEDGE. | Estamos trabajando para publicar pronto un documento sobre la medición del rendimiento. |
| Informes | ¿Cómo se controlarán los informes de FLEDGE? | Los informes de FLEDGE sobre las victorias, el resultado de la subasta y el evento (p.ej., los clics estarán disponibles a través de las APIs de FLEDGE, como reportResult()). En los informes con la conversión de anuncios, la integración con la API de Attribution Reporting será independiente de FLEDGE, pero hay conversaciones continuas con el ecosistema sobre posibles enfoques.
La API de Private Aggregation también se puede usar para informar resultados de subastas desde los entornos de ejecución aislados. Consulte la explicación aquí. |
| Tamaño del grupo de interés | ¿Existe alguna forma de que las plataformas de tecnología publicitaria verifiquen el tamaño de un grupo de interés (es decir, la cantidad de usuarios en el grupo)? | La pertenencia a un grupo de interés se almacena en el navegador, en el dispositivo del usuario, y no se comparte con el proveedor del navegador ni con nadie más.
Sin embargo, en teoría, el propietario de un grupo de interés puede hacer un seguimiento de cada llamada a navigator.joininterestgroup(...). El seguimiento de esta llamada no garantiza el tamaño exacto de un IG (ya que los usuarios pueden abandonar un grupo en cualquier momento), pero le proporciona al propietario un límite superior y una aproximación de cuál podría ser el tamaño. |
| Rendimiento | ¿Se compila el código de JS/WebAssembly de Bidding en cada subasta? | El código de JS/WebAssembly para Licitación se compila una vez durante cada subasta. |
| Rendimiento | ¿Cuál es el alcance de BiddingDurationMsec? | BiddingDurationMsec incluye la compilación del tiempo de la secuencia de comandos. No incluye el tiempo de descarga, el tiempo de compilación de Wasm, el tiempo de red; el tiempo de recuperación del servidor de par clave-valor o cualquier otro paso antes de la compilación de JS. |
| Personalización | ¿Es posible actualizar adComponent de modo que esté personalizado para el usuario? | adComponent se puede actualizar cuando el llamador actualiza los grupos de interés al llamar a joinInterestGroup o cuando Chrome realiza una llamada adailyUpdateURL. Esto permite que el llamador actualice el adComponent en función del conocimiento del usuario del sitio actual o de la información k-anónima, respectivamente.Puedes encontrar la propuesta original de turtledove a nivel del producto aquí que incluye un análisis de RTB House sobre el impacto en las métricas principales para el caso de uso de recomendaciones. |
| Grupo de interés | ¿Es posible que el propietario de un grupo de interés quite a ciertos usuarios de forma condicional? | La membresía del grupo de interés se almacena solo en el navegador del usuario y solo se puede quitar de este (p.ej., al borrar los datos del sitio).
Sin embargo, es posible que el propietario de un grupo de interés llame a navigator.leaveAdInterestGroup() (con alguna lógica condicional a su alrededor), si el usuario regresa a una página bajo el control del propietario del grupo de interés. |
| Rendimiento | ¿Cómo se mide el rendimiento de generateBid? | El tiempo de compilación y ejecución se puede medir con bidDurationMsec. El tiempo de descarga se puede medir con chrome://net-export. En las versiones recientes de Chrome, el tiempo de compilación y ejecución se mostrará en la pestaña Performance de Herramientas para desarrolladores. |
| Frecuencia de las actualizaciones de grupos de interés | ¿Con qué frecuencia se actualizará el grupo de interés de los navegadores? | En el caso de los grupos de intereses que no se actualizaron en las últimas 24 horas, Chrome intenta actualizarlos cuando se llama a navigator.updateAdInterestGroups() o cuando tuvieron la oportunidad de participar en una subasta. Para obtener más detalles, consulta la explicación aquí. |
| Proveedores de servicios de agregación | ¿Cuándo se admitirá el servicio de agregación para admitir otros proveedores de servicios en la nube? | En este momento, no tenemos novedades sobre los horarios específicos, pero compartiremos más información cuando lo hagamos. Por el momento, solo AWS cumple con los requisitos de seguridad del servicio de agregación. |
| Cronograma de pruebas de FLEDGE | ¿Durante cuánto tiempo FLEDGE realizará pruebas en BYOS? ¿Habrá suficiente tiempo para cambiar del modelo BYOS al modelo basado en TEE? | Para garantizar que el ecosistema tenga tiempo suficiente para realizar pruebas, no esperamos exigir el uso de los TEE hasta algún momento después de la baja de las cookies de terceros. Enviaremos avisos importantes para que los desarrolladores comiencen las pruebas y la adopción antes de que se lleve a cabo esta transición. En este momento no tenemos más actualizaciones, pero compartiremos más novedades cuando lo hagamos. Encuentra la información más reciente aquí. |
| Límite de tamaño de los datos | ¿Cuál es el límite de tamaño de los datos para wasm en la función de ofertas? | Existe un requisito de que las actualizaciones de grupos de interés no pueden generar un grupo de interés que supere los 50 KB, como se explica aquí, pero aún no se definió el límite de tamaño de los datos para wasm, por lo que nos gustaría conocer su opinión sobre este tema. |
| Indicadores de subasta | ¿Habrá una estructura de datos estandarizada para AuctionSignals? | Esto aún no está definido, pero estamos abiertos a recibir comentarios. |
| Consulta servidores de tecnología publicitaria | ¿Es posible consultar datos del servidor de tecnología publicitaria en tiempo real desde un servidor de K/V? | No, el servidor de K/V se ejecuta en un modelo de confianza que aplica “Sin red, acceso al disco, cronómetros o registros” para evitar filtrar datos del usuario. Consulta la explicación del modelo de confianza aquí para obtener más detalles. |
| Frecuencia de actualización de adComponents | Por el momento, no es posible actualizar el campo adComponents (actualmente solo en la configuración de IG) mediante el historial de navegación del usuario. | Privacy Sandbox busca satisfacer las necesidades del ecosistema web sin el seguimiento entre sitios, lo que significa impedir el acceso al historial de navegación. Recomendamos usar alternativas como Topics. |
| Resultados de la subasta | ¿Hay alguna manera de que las tecnologías publicitarias conozcan las tasas de éxito de subastas? | El resultado de la subasta se informa llamando a las funciones reportResult() y reportWin() en el código de subasta proporcionado por el vendedor y el comprador ganador, respectivamente, de modo que cada uno tiene la oportunidad de registrar el resultado de la subasta y generar informes sobre él. |
| (También se informa en el segundo trimestre)
Compatibilidad con la segmentación negativa por grupos de interés |
Una API para admitir la segmentación negativa por grupos de interés: muestra anuncios solo si un usuario no pertenece a un grupo de interés. | Actualización del P3:
Compartimos una nueva propuesta y queremos conocer tus comentarios. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Requisitos de PO | Quita las restricciones de la política de permisos solo durante / para el OT. | Consulta nuestros cambios anunciados en la Política de Permisos durante las pruebas. La preocupación subyacente de las partes interesadas que se aborda en este cambio es permitir que las DSP prueben la API en una mayor cantidad de iframes de origen cruzado. Originalmente, las DSP debían coordinar con los publicadores/SSP para asegurarse de que se establecía la política de permisos correcta a fin de probar la API en iframes de origen cruzado. Sin embargo, con este cambio, las DSP podrán llamar a la API de forma predeterminada y los SSP y publicadores podrán inhabilitar la API si es necesario durante la prueba de origen. |
| Ruido | Feedback de que el nivel de ruido es demasiado alto y afecta la utilidad de los informes. | Recibiremos comentarios sobre el ruido, que usaremos para determinar cómo establecer ciertos parámetros relacionados con el ruido. También queremos publicar más recursos, herramientas y otros documentos para ayudar a los verificadores con esta tarea. |
| Conversiones multidominio | ¿Cómo hacer un seguimiento de las conversiones que son multidominio, como con 2 o más destinos? | Estamos analizando y solicitando comentarios sobre esta pregunta. |
| Requisitos de depuración | ¿Deseas permitir que los desarrolladores verifiquen el presupuesto de privacidad restante cuando implementen o realicen pruebas del informe de resumen? | Puedes hacer un seguimiento de esta solicitud de función aquí. |
| Políticas de uso de la API | Comentarios en los que se sugieren políticas sobre quién puede usar una API determinada en función de restricciones, como la creación de huellas digitales | Esta es una idea muy interesante y es algo con lo que nos encantaría continuar trabajando con otros proveedores de navegadores y con el ecosistema web más amplio. |
| Configuración de vencimiento en el informe de conversiones | Solicitud de compatibilidad con el filtro o vencimiento de informes en menos de 24 horas. | Los vencimientos por hora son una fuente de preocupación respecto de la privacidad, ya que permiten que la tecnología publicitaria sepa exactamente a qué hora un usuario visita el sitio del anunciante. El vencimiento a nivel del día permitirá que la tecnología publicitaria filtre impresiones no válidas sin determinar a qué hora visitó el sitio el usuario. |
| Vencimiento del token de OT | Solicita la extensión de la validez de los tokens de OT existentes para reducir la sobrecarga operativa. | Reconocemos que los tokens se deben renovar y estamos trabajando para facilitar el proceso para los desarrolladores y proporcionar avisos adicionales. |
| Asistencia regional | En la actualidad, el servicio de agregación no admite todas las regiones. | Esta es una limitación actual para la versión beta. Esperamos admitir más regiones a medida que avancen las pruebas, pero aún no hay un cronograma claro para hacerlo. |
| Demora en los informes a nivel del evento | La demora de 2 a 30 días en los informes a nivel del evento puede ser demasiado larga para ciertos casos de uso. | Compartimos una propuesta aquí para permitir que las tecnologías publicitarias controlen cuándo se envían los informes a nivel del evento por vencimiento. El valor predeterminado es de 30 días, pero se puede establecer más corto. |
| (También se informa en el segundo trimestre)
Atribución de múltiples puntos de contacto |
Permite la atribución de múltiples puntos de contacto, como multidispositivo o entre apps. | Actualización del P3:
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. |
| Cronograma de integración de FLEDGE y Attribution Reporting | ¿Cuál es el cronograma para la integración de la API de Attribution Reporting y FLEDGE? | Por el momento, no tenemos novedades, pero brindaremos más información públicamente cuando podamos comprometernos con un cronograma específico. |
| Varios tipos de activadores | Solicita más flexibilidad para registrar activadores. | Proponemos un sistema de anulación de duplicación para las APIs agregadas que brindará a las plataformas de AdTech más flexibilidad en la forma en que controlan los informes agregables y a nivel del evento. |
| Medida | Solicita recibir datos de medición para saber si el inventario tiene un buen rendimiento. | Agradecemos los comentarios y estamos buscando mayor claridad sobre los casos de uso para esta solicitud. |
| Vencimiento de la conversión | Solicita admitir el vencimiento de la conversión en la etiqueta del activador en lugar de solo en la etiqueta de origen. | Agradecemos los comentarios y estamos buscando mayor claridad sobre los casos de uso para esta solicitud. |
| Informes por lotes | Solicitud de medición adicional en los informes por lotes. | Agradecemos los comentarios mientras seguimos pensando en el impacto en el servicio de agregación. Nos interesa saber cómo las tecnologías publicitarias están pensando en los informes por lotes, su frecuencia esperada y los comentarios sobre cómo cambia la estrategia de lotes a lo largo del año. |
| Epsilon | ¿Cuándo se determinará el valor de épsilon? | Estamos trabajando activamente con los evaluadores del ecosistema para ultimar el valor de épsilon y cómo se implementará en DG. El valor estará visible en público, junto con el debate que llevó a la decisión del valor. Si tienes algún comentario, publícalo en este problema de GH. |
Limita el seguimiento encubierto
Reducción de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Dependencias de implementación | Cómo abordar las dependencias de implementación de usuario-agente (SUA) estructuradas | Lanzamos la "Fase 4", es decir, la reducción de versiones secundarias para el 100% de los usuarios de Chrome en las versiones 101 y superiores. Consulta la actualización aquí. |
| Prueba | Solicitud de Meta para extender la prueba de origen de reducción de usuario-agente. | Ampliamos la prueba de origen y obtuvimos permiso para quitar los límites de tráfico a fin de adaptarse a sitios más grandes. Los límites de tráfico relajados se aplican a cualquier sitio, grande o pequeño. |
Client Hints de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
| (También se informa en el segundo trimestre)
Inquietudes contra el fraude y el abuso |
Algunas funciones que pueden perderse con UA-CH: la herramienta de seguimiento de redireccionamiento de clics y los clics fraudulentos. | Actualización del P3:
Recibimos comentarios positivos de empresas que indicaron que no notaron ningún efecto adverso en sus canalizaciones antifraude (consulta los resultados aquí y aquí). El equipo sigue investigando estos posibles problemas con las partes interesadas en la lucha contra el fraude y la medición. |
| Política de permisos | ¿La política de permisos se almacena en caché? | La política de permisos no se almacena en caché como se explica en este problema de GitHub. |
Gnatcatcher (en construcción)
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Casos de uso de la ubicación geográfica | Gnatcatcher puede impedir que funcionen en el futuro los casos de uso legítimos de la ubicación geográfica, como la personalización del contenido basada en la ubicación geográfica. | Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo los casos de uso legítimos de las direcciones IP. |
Fortalecer los límites de privacidad entre sitios
Conjuntos propios
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Política | Preocupación de que el FPS no es coherente con las disposiciones de los compromisos de la CMA en relación con la "Legislación Aplicable de Protección de Datos", porque el GDPR no impone un límite a la cantidad de sitios en un conjunto, mientras que la FPS establece un límite de 3. | Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de manera que no distorsione la competencia por autopriorizar los negocios de Google y a tener en cuenta el impacto en la competencia en publicidad digital, los publicadores y los anunciantes, así como el impacto en los resultados de privacidad y el cumplimiento de los principios de protección de datos establecidos en la Legislación Aplicable de Protección de Datos. La inquietud expresada no revela ninguna incompatibilidad con el GDPR. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos. Se incluyen más detalles en la sección "Cambios en respuesta a comentarios" que aparece a continuación. |
| Documentación | Solicite ejemplos adicionales y actualice las explicaciones existentes. | Los ejemplos de nuestras explicaciones están en proceso de revisión. Se aclararán o quitarán algunos según sea necesario. |
| Uso compartido de preferencias | Propuesta para establecer preferencias en los conjuntos de la misma parte. | Agradecemos los comentarios y estamos analizando la idea activamente aquí. |
| Aplicación | Los procesos de aplicación transparentes implican un riesgo de abuso por parte de personas o entidades que actúan de mala fe. | Agradecemos los comentarios y participamos activamente en conversaciones con las partes interesadas en GitHub (considerando los puntos planteados en este problema y buscando incorporar las sugerencias mencionadas en este problema) y otros foros para evaluar este riesgo y, además, identificar posibles mitigaciones. |
| Propiedad común | Propuesta de declaración de propiedad común procesable. | Agradecemos y fomentamos las opiniones sobre nuestra propuesta. |
| Propiedad de los subdominios | ¿Deben ser parte del mismo conjunto propio diferentes subdominios con distintos responsables del tratamiento de datos, diferentes políticas de privacidad o que operan distintas entidades? | En función de los comentarios recibidos, planeamos quitar el caso de uso común de eTLD. |
| Mitigación de abusos | Solicita más detalles sobre las medidas de mitigación de abusos. | Se está considerando la administración del proceso y se compartirán más detalles en los próximos meses. |
| Vector de ataque potencial | Se podría usar un conjunto asociado engañoso para páginas de fácil búsqueda para dirigir tráfico a otras páginas que se presentan como independientes de forma engañosa. | Recopilamos activamente comentarios del público y estamos investigando posibles formas de abordar este problema. |
| Configurar validación | Se valida el conjunto mediante políticas comunes con consentimiento. | Varios miembros de la comunidad de estándares de la Web y el ecosistema más amplio indicaron que no es factible. |
| Límite de dominios | Solicitud para expandir la cantidad de dominios asociados. | Estamos analizando el límite de dominios en FPS, por lo que nos gustaría recibir más comentarios de la comunidad sobre la cantidad de dominios asociados que requieren para sus casos de uso. |
| Interacción del servicio de subconjunto | Inquietud relacionada con el servicio y la interacción con el subconjunto asociado. | Agradecemos los comentarios. Analizaremos la posibilidad de incluir más detalles en las especificaciones futuras. |
| (También se informa en el segundo trimestre)
Mejoras en la privacidad |
Si hay demasiados sitios en el mismo conjunto, se podrían generar resultados similares a los de las cookies de terceros. | Actualización del P3:
La propuesta más reciente sugiere un límite de tres dominios para el subconjunto "asociado" (que no incluye los ccTLD ni dominios de servicio). Chrome interactúa activamente con el ecosistema para determinar si este límite es apropiado. |
| (También se informa en el segundo trimestre)
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. | Actualización del P3:
Una política de privacidad común ya no es un requisito para formar parte del mismo conjunto. |
API de Fenced Frames
| Tema de comentarios | Resumen | Respuesta de Chrome |
| ¿Por qué agregar un elemento nuevo en lugar de atributos en los iframes? | Pregunta relacionada con la propuesta Frenced Frame en lugar de las propuestas existentes de iFrame. | Apreciamos los comentarios y estamos abiertos a ideas sobre cómo converger el estado actual de las cosas, como se explica aquí. |
| Observador de intersección en marcos cercados | Preguntas relacionadas con la visibilidad de la información dentro de un Marco vallado | Esto se encuentra en un debate activo y en el período de comentarios en este documento y en GitHub. Invitamos a los socios a que compartan casos de uso con nosotros para comprender mejor cómo brindar asistencia. |
| Compatibilidad con inventario nativo y de video | ¿Los marcos cercados son compatibles con el inventario nativo y de video? | En cuanto a las capacidades de reproducción de video, los marcos cercados no difieren de los iframes y por eso no se mencionan explícitamente en ninguna documentación pública. Si detectas algún problema con los anuncios de video, nos gustaría que envíes tus comentarios para que podamos seguir investigando. |
| Paquetes web | ¿La publicación o renderización de anuncios mediante paquetes web se convertirá en un requisito en el futuro con el marco cercado y FLEDGE? | El objetivo a largo plazo es admitir paquetes web para renderizar contenido de anuncios en un marco vallado. Sin embargo, la implementación actual de FLEDGE no lo admite y requiere la renderización de un recurso HTML recuperado de renderUrl. |
| Dimensiones del elemento | Solicitud de render_url para admitir una macro para la altura y el ancho del espacio, de modo que podamos responder con una creatividad del tamaño adecuado | Este tema se analiza de forma activa aquí. |
API de Shared Storage
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Integración de FLEDGE | ¿Cómo se integrarán el almacenamiento compartido y FLEDGE? | Si bien actualmente no tenemos pensado hacerlo, nos interesa explorar esta idea para poder garantizar la preservación de las protecciones de la privacidad. Recomendamos a las partes interesadas que envíen sugerencias para posibles casos de uso que esta propuesta pueda admitir en el repositorio de GitHub de almacenamiento compartido o en el repositorio de GitHub de FLEDGE. . |
| Retención de datos | Liberar el almacenamiento compartido reduce la utilidad. ¿Se consideran alternativas las extensiones del período de retención o la capacidad de borrar pares clave-valor individuales? | Siempre buscamos un equilibrio entre la privacidad del usuario y las compensaciones de utilidades. Estamos dispuestos a recibir comentarios sobre los ajustes y recomendamos a los socios que envíen más comentarios y detalles a medida que prueban el almacenamiento compartido. |
| Indicador negativo | Señal negativa de Mozilla con respecto a la propuesta de almacenamiento compartido. | Agradecemos a Mozilla por el cuidadoso análisis de nuestra propuesta. Planeamos responder a sus comentarios próximamente. |
CHIPS
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Requisito particionado | Se agregó el requisito de comportamiento explícito para el atributo "Particionado" en las cookies propias. | Analizamos este tema en una llamada de PrivacyCG y realizamos un seguimiento del problema de GitHub con notas. Seguimos trabajando con navegadores, desarrolladores y la comunidad de privacidad para alinearnos con respecto a un comportamiento y especificarlo. |
| Incorporaciones autenticadas | Es posible que CHIPS afecte el flujo de acceso al SSO actual debido a que las diferentes particiones afectan a las incorporaciones autenticadas. | Conocemos el caso de uso de las incorporaciones autenticadas y estamos trabajando para explorar soluciones. |
| Límite de partición de cookies | Le preocupa que el límite actual de 10 cookies puede no ser suficiente para ciertos casos de uso. | Nos estamos alejando de un límite en la cantidad de cookies a un límite de memoria de 12 KB. Esto nos permite abordar inquietudes relacionadas con el límite de cookies y garantizar al mismo tiempo que el rendimiento y la superficie de memoria del navegador no se vean afectados negativamente. |
| Cronograma de la prueba de origen | La extensión de OT sigue la eliminación del requisito de limitación del nombre de host. | Extendimos la fecha límite de la prueba de origen luego de los comentarios del ecosistema. |
| Limitaciones de las pruebas en Chrome | Existe la posibilidad de probar CHIPS en Firefox debido a las limitaciones actuales en Chrome. | La implementación de Firefox es aproximadamente diferente, Chrome tiene un límite de cookies más bajo y CHIPS es un mecanismo de aceptación, pero Firefox se particiona de forma predeterminada. |
| (También se informa en el segundo trimestre)
Incorporaciones autenticadas |
¿Se preserva el estado de acceso con CHIPS? | Actualización del P3:
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. |
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
| (También se informa en el segundo trimestre)
Vectores de ataque potenciales |
Posibles vectores de ataque a través de decoración de vínculos y ataques de tiempo | Actualización del P3:
Trabajamos con Mozilla para lograr un entendimiento común de cómo abordar el problema de los ataques de tiempo. Encuentra más detalles aquí. Ahora estamos realizando el prototipado de este cambio arquitectónico y esperamos realizar experimentos en los próximos trimestres. |
| Proveedores de identidades | Selector de cuentas: Proveedor de identidad único. Solicita permitir múltiples proveedores de identidad. | Trabajamos con proveedores de navegadores y el FedID CG para lograr que se permitan múltiples proveedores de identidad y llegamos a una fórmula que vale la pena probar. La descripción de la propuesta está aquí, y esperamos desarrollar prototipos y realizar experimentos en los próximos trimestres. |
| Problemas conocidos con la federación | Solicitud para enumerar los casos en los que la federación podría tener problemas con la baja de las cookies de terceros. | El FedID CG tiene un elemento de trabajo que es enumerar las formas en las que se interrumpe la federación aquí y aquí. También está compilando una matriz de decisión para asignar fallas a las APIs de plataforma web aquí. |
| Parámetro del sustantivo | ¿El parámetro Nounce podría afectar el flujo de acceso? | Esto podría considerarse seguimiento entre sitios, pero aún estamos recopilando información y analizando cómo tratar estos casos. |
| Consentimiento del usuario | Vinculación de diferentes terceros de confianza (RP) y el consentimiento del usuario para cada origen | Esta especificación no puede controlar cómo comparten cookies los orígenes dentro del mismo dominio. La especificación permite idtoken del origen del IdP al origen del RP, pero depende del RP elegir si el estado de acceso del usuario se debe almacenar en una cookie bloqueada para ese origen único o en una cookie compartida con orígenes dentro del mismo dominio. |
| Cuenta de IdP
portabilidad |
Opción del usuario de migrar los IdP si así lo desean al realizar la transferencia entre dos IdP. | Eso parece ser algo que el usuario tendría que hacer directamente en la página de registro del nuevo IdP que elija, no a través de la API de FedCM. |
| Eliminación de cuenta | Revocación del IdP contando por la eliminación de la cuenta con el IdP. | Esta solicitud de función está abierta para su entrada y investigación. |
| Reclamo de IU | Declaraciones sobre aspectos específicos de la interfaz del navegador | Consulta la solicitud de extracción para abordar este problema. |
| Verificación de referencias de IdP | Verificaciones de IdP para el referente del RP. | Se agregó la verificación obligatoria del referente de IdP a la especificación. Consulta la solicitud de extracción. |
| Flujo de acceso | Solicitud de que los flujos de acceso se personalicen según las preferencias de RP. | Apreciamos la idea y la conversamos activamente. |
Combate el spam y el fraude
API de Trust Tokens
| Tema de comentarios | Resumen | Respuesta de Chrome |
| Fraude y abuso | Herramientas para garantizar que un bot no haya engañado a un emisor para que le otorgue un token, que un bot no haya vulnerado un token emitido a un usuario real y para evitar que los bots emitan tokens maliciosos | Si bien los bots pueden obtener tokens de un emisor, se recomienda a los emisores que establezcan límites sobre la frecuencia con la que emiten tokens y métodos sólidos para emitirlos y actualizar su lógica de emisión, ya que los actores maliciosos intentan eludirlos. Es probable que las entidades emisoras que no tengan una lógica lo suficientemente sólida para emitir tokens pierdan confianza en el ecosistema, ya que los sitios web priorizan la dependencia de entidades emisoras más sólidas. |
| Fraude y abuso | ¿Hay alguna manera de que un canjeador de tokens de confianza pueda especificar que solo aceptará tokens de confianza de entidades específicas? | Sí, esto es posible. En la sección Canje de token de confianza de la explicación, se describe cómo funciona este proceso. |
| Fraude y abuso | ¿Hay alguna manera de que una entidad emisora de tokens de confianza defina una lista de canjeadores y no permita que otra persona canjee tokens? | Por ahora no, pero el equipo está investigando este caso de uso. |
| Cronograma | ¿Cuándo estará disponible la API de Trust Token para el público en general? | Compartiremos más información públicamente en cuanto podamos establecer un cronograma. |
| (También se informa en el segundo trimestre)
Sobrecarga de mantenimiento |
No está claro cuánto tiempo se admitirán las versiones de protocolo. | Actualización del P3:
Se está agregando compatibilidad adicional en las APIs para admitir varias versiones simultáneas a fin de permitir una transición correcta entre versiones, aunque aún se están definiendo los plazos para la compatibilidad o la baja. |