Informe trimestral del primer 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 Competition and Markets Authority, 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 y tecnologías de Topics, Fledge y Attribution Reporting.
Es posible que los comentarios recibidos recientemente aún 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
Temas en común de todas las fuentes de comentarios
Un tema común en nuestros canales de debate y comentarios son las preguntas sobre los plazos, los niveles de tráfico y la disponibilidad de las pruebas. En particular, los verificadores querían constantemente que se confirme cuándo estarán disponibles las APIs para las pruebas y si las pruebas estarán disponibles en todo el mundo.
Para abordar estos comentarios, Chrome se comunicó abiertamente y publicará una pregunta frecuente para confirmar que las pruebas estarán disponibles en todo el mundo. Además, Chrome continuará actualizando los cronogramas públicos periódicamente en consulta con la CMA.
Muestra contenido y anuncios relevantes
| API y tecnología | Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Temas | Utilidad de temas poco detallados | Surgió la preocupación respecto de que la taxonomía de temas generalizada podría no ser lo suficientemente útil para la publicidad basada en intereses. | Se explorará la utilidad de la API a través de pruebas. Chrome espera que la taxonomía evolucione en función de los resultados de las pruebas. |
| Temas | 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. |
| Temas | Utilidad para diferentes tipos de sitios | 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. | 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. |
| Temas | Metodología de clasificación de sitios | Solicitar que los sitios puedan decidir o influir en su clasificación de Topics | Chrome está explorando esta solicitud, pero escucharon inquietudes (de la comunidad de navegadores web y de las DSP) sobre el riesgo potencial de que los sitios puedan "engañar al sistema" para segmentar a los usuarios de una manera que incumpla la privacidad o reducir la relevancia de los anuncios. Chrome está buscando comentarios y analizando los posibles cambios. |
| Temas | 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. |
| Temas | Permisos de terceros controlados por el sitio | Solicitar que los sitios puedan elegir qué tecnologías publicitarias pueden llamar a la API de Topics desde su sitio | Esta función solicitada ya es compatible con la política de permisos "browsing-topics", como se menciona en la explicación. |
| Temas | Efecto de la API de Topics en el rendimiento de la página | Inquietudes sobre los retrasos en el primer anuncio como resultado de la dependencia de la API de Topics | Chrome está debatiendo la posible compatibilidad de temas en los encabezados de solicitud HTTP para mejorar el rendimiento. Estamos realizando pruebas para ver si esos cambios son necesarios. |
| Temas | Privacidad / Política | Preguntas relacionadas con el propósito de filtrar las respuestas por emisor en caso de que terceros compartan sus temas con alguien que llama | 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. |
| Temas | Documentación | Interés en la documentación que cubre los detalles del modelo del clasificador y la taxonomía que usa Chrome como lo hizo con FLoC, por ejemplo, la frecuencia con la que cambiarán el clasificador y la taxonomía | Chrome ya proporciona la taxonomía que se usa como parte de las pruebas de origen, y el modelo clasificador que categoriza sitios web en Topics está disponible en la base de código de Chrome como parte del código abierto. Como parte de las pruebas de origen, Chrome se reserva el derecho de realizar cambios a medida que se reciben comentarios y se recopilan aprendizajes sobre su funcionamiento. |
| FLEDGE | Limitación de frecuencia | Desean poder controlar la frecuencia por usuario en una campaña o un grupo de anuncios. | FLEDGE admitirá la limitación de frecuencia para las subastas integradas en el dispositivo. Hay un problema abierto en el que se aborda este tema para que FLEDGE también admita las campañas contextuales o de desarrollo de la marca. El almacenamiento compartido, otra API en desarrollo y los límites específicos del sitio también se pueden usar para obtener controles adicionales de la limitación de frecuencia. |
| FLEDGE | Impacto de FLEDGE en el rendimiento | Se plantearon inquietudes sobre el posible impacto de los ofertantes que hacen un uso intensivo de los recursos informáticos en la subasta de FLEDGE. | Chrome está conversando de forma activa con los desarrolladores sobre el impacto potencial en el rendimiento del sitio. Chrome agradece la oportunidad de aprender más durante las pruebas. |
| FLEDGE | Cómo probar FLEDGE con otras funciones | Cuándo y cómo se llevarán a cabo las pruebas con otras funciones (servidor de k-anonimato, servidores de pares clave-valor, etcétera). | Chrome está lanzando funciones intencionalmente en fases para nuestras pruebas de origen iniciales a fin de facilitar las pruebas. Chrome reconoce que es importante proporcionar claridad sobre el cronograma para otras funciones y lo aclarará siempre que sea posible. |
| FLEDGE | Coordinación de pruebas | Cómo coordinar las pruebas entre varias tecnologías publicitarias | Chrome está investigando ofrecer asistencia adicional para coordinar experimentos, de modo que diferentes tecnologías publicitarias experimenten con los mismos usuarios. Este también es un enfoque clave de la comunicación de las asociaciones de Chrome; los organismos comerciales de la industria también expresaron interés en desempeñar un papel importante. |
| FLEDGE | Límites de grupos de interés | ¿Habrá límites en la cantidad de grupos de interés a los que se puede agregar un usuario o que se puede incluir en la subasta? | Chrome está dispuesto a definir mejor estos límites por motivos relacionados con el rendimiento de las páginas web o la experiencia del usuario durante el período de prueba en función de los comentarios y el impacto medido en la latencia. Los verificadores debaten de forma continua las formas adicionales de permitir que los compradores y vendedores ajusten el uso de los recursos. |
| FLEDGE | Capacidades entre API | ¿Cómo funcionarán los informes de atribución con FLEDGE? | Aún no se conocen todos los detalles, y Chrome espera tener una actualización al respecto en el segundo trimestre. Chrome espera seguir proporcionando informes a nivel del evento para los resultados de la subasta (ganancias y derrotas) durante la prueba de origen. |
Medición de anuncios digitales
| API y tecnología | Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Attribution Reporting (y otras APIs) | Prueba el tráfico | Inquietudes si habrá suficiente tráfico para realizar pruebas | Chrome está iniciando la prueba de origen con un tráfico muy bajo para garantizar que no haya errores o problemas graves en los controles de usuario. Los primeros verificadores desempeñan un papel importante a la hora de confirmar que las APIs funcionan según lo previsto desde el punto de vista técnico, lo que ayuda a aumentar más rápido el tráfico. Una vez que tengas la certeza de que las APIs funcionan según lo esperado, Chrome aumentará la prueba de origen para admitir pruebas de utilidad. |
| Informes de atribución | Ergonomía para registrar eventos | Preguntas sobre las formas de registro admitidas en los eventos | Chrome publicó una respuesta en GitHub para aclarar qué formas de registro se admiten actualmente. Chrome recopila comentarios del ecosistema sobre el diseño actual para determinar si los cambios propuestos abordan estas inquietudes de forma adecuada o si se necesitan más actualizaciones. |
| Informes de atribución | Generación de ruido | Quieres obtener más detalles sobre cómo se genera ruido en los informes agregados. | Chrome publicó una respuesta en GitHub para proporcionar más detalles sobre la forma sistemática de generar ruido. Chrome planea proporcionar una biblioteca para simular ruido y realizar pruebas con un rango de parámetros durante OT. Chrome también planea proporcionar documentación y guías adicionales para desarrolladores para el modo de informes agregados. |
| Informes de atribución | Datos menos precisos para sitios pequeños | Preocupación de que los sitios o las campañas más pequeños recibirán 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. |
| Informes de atribución | Impacto de las demoras en las conversiones en la utilidad | Te preocupa que las demoras en las conversiones interfieran en la configuración y la verificación de la campaña, o bien en su optimización. | Chrome recibió algunos comentarios contradictorios sobre el impacto de las demoras en los informes de conversiones. Sin embargo, dado que la API de Attribution Reporting produce demoras aleatorias en los informes para proteger la privacidad de los usuarios, Chrome espera que los casos de uso o las inquietudes específicos sean más claros durante el período de prueba y se pueden abordar mediante asistencia de depuración adicional u orientación para desarrolladores. |
| Informes de atribución | Ventana de atribución más extensa | Solicitud para extender la ventana de atribución de 30 días | Chrome publicó una respuesta para obtener más comentarios sobre la duración de la ventana de atribución, teniendo en cuenta tanto la minimización de datos como la utilidad. |
| Informes de atribución | Impresiones no visibles | Preguntas acerca de si las impresiones no visibles se registran para los informes de conversiones posimpresión | Chrome publicó una respuesta en GitHub para brindar más claridad sobre las impresiones visibles. |
Limitar el seguimiento encubierto
| API y tecnología | Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Reducción de usuario-agente | 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. |
| Reducción de usuario-agente o Client Hints de usuario-agente | Inquietudes contra el fraude y el abuso | Contar con la mayor cantidad de información posible es importante cuando se depuran ciertos tipos de ataques, incluida la denegación del servicio. Perder parte de la información de la cadena de UA puede suponer desafíos. | Chrome está analizando y evaluando maneras de mantener la privacidad al mismo tiempo que proporciona suficiente información que será útil para la depuración. |
| Reducción de usuario-agente | Confusión en la configuración de OT | Varios participantes de la prueba de origen recomendaron mejorar la documentación con ejemplos de cómo inscribirse en la prueba de origen. | La prueba reducida de origen de UA finalizará, pero Chrome pretende mejorar las instrucciones para la prueba de baja (lo que incluye destacar la demostración de ejemplo). |
| Reducción de usuario-agente | Inquietud sobre los valores de una sugerencia específica | Preguntas sobre si Sec-CH-UA-Model es igual que <deviceModel> en la string de usuario-agente. | Sec-CH-UA-Model es lo mismo que <deviceModel> en la string de usuario-agente. Chrome intentará dejar esto más claro en documentación futura. |
| Reducción de usuario-agente | Inquietud por inscribirse en la prueba de baja | Preguntas sobre cómo inscribir una gran cantidad de dominios en la prueba de baja | Chrome consideró enfoques centralizados al diseñar la prueba de baja, pero cree que la prueba de origen existente es la mejor opción, ya que les otorga todo el control a los desarrolladores (ya que pueden elegir enviar el encabezado o no). |
| Client Hints de usuario-agente | Inquietudes sobre la naturaleza prescriptiva de UA-CH | Existe una preocupación respecto de que UA-CH sea 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).
Sin embargo, el problema seguirá abierto en caso de que otras personas también compartan esta preocupación y quieran enviar comentarios. |
| Client Hints de usuario-agente | Inquietud de que la API se usa para bloquear ciertos navegadores | Inquietud de que un sitio esté usando la API para buscar "Google Chrome" o "Microsoft Edge" y bloqueando todos los demás navegadores | El concepto de una lista de marcas se diseñó para abordar este caso: un navegador puede enviar "Google Chrome" además de sus propias marcas. |
| Client Hints de usuario-agente | Solicitud de un método para enumerar todas las sugerencias compatibles | Me interesa tener una manera programática de conocer todas las sugerencias compatibles para un navegador. | Chrome está evaluando la solicitud de función. |
| Reducción de usuario-agente o Client Hints de usuario-agente | Inquietudes contra el fraude y el abuso | Las sugerencias de cliente no están disponibles en la primera carga para HTTP1 | Una de las API de Client Hints Reliability (elemento Aceptar_CH) solo está disponible a través de HTTP2 y HTTP3. En el caso de los servidores que todavía reciben servicios a través de HTTP1, deberán confiar únicamente en el canal Critical-CH. |
| Reducción de usuario-agente | Impacto en Chrome para Android | Preguntas sobre cómo esto afecta a Chrome en Android en particular | La reducción de UA y UA-CH se lanzarán en Chrome para Android y en computadoras de escritorio. En el caso de Chrome para Android, los cambios solo se llevarán a cabo en la "Fase 6", actualmente programada para Chrome 110. |
| Gnatcatcher (WIPB) | Usos y métodos no conformes | Debe aclarar cuáles serían los usos no conformes y los métodos no conformes. | Chrome actualizará la explicación con más detalles. |
| Gnatcatcher + reducción de usuario-agente | Reducimos las señales de prevención de fraudes | El impacto antifraude de la reducción simultánea de la IP y el acceso de UA. | Esperar las estipulaciones de la política antifraude por ceguera de IP voluntaria (para permitir el uso de IP en casos de uso antifraude) resolverá las inquietudes de defensa en torno a la proxy de IP. |
| Seguimiento de navegación | Preocupación por futuras fallas | A los anunciantes les preocupan las posibles fallas, pero los proveedores de identidad también expresaron interés en los planes de Chrome. | Chrome no está realizando cambios rotundos inminentes y aún está explorando casos de uso. |
| Cookies de SameSite | Interoperabilidad con otros navegadores | Preguntas sobre los planes de Chrome para corregir crbug.com/1221316, ya que es un área donde las implementaciones de Chrome difieren de otros navegadores. | Chrome descubrió un error en las métricas y, como resultado, encontró métricas nuevas. Chrome está recopilando datos para comprender mejor el impacto de corregir el error. |
| Particionamiento del almacenamiento | Inquietud sobre la partición de canales de mensajes | Preguntas relacionadas con los canales de mensajería (p.ej., SharedWorker y BroadcastChannel). | Chrome está evaluando los comentarios, pero cree que es necesario particionar los canales de mensajería junto con el almacenamiento para evitar el seguimiento encubierto. |
Fortalecer los límites de privacidad entre sitios
| API y tecnología | Tema de comentarios
(Clasificado por prevalencia) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| Conjuntos propios | 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. |
| Conjuntos propios | Es probable que la Entidad Independiente de Aplicación de Políticas (IEE) reciba una gran cantidad de comprobaciones de validez de los FPS. | Resumen de los desafíos previsibles para determinar la validez de los FPSs: el texto o la política de privacidad no coinciden con los miembros del set, la claridad sobre cómo definir la membresía evidente para el usuario, los desafíos de ancho de banda y tiempo, y la experiencia especializada en la estructura corporativa. | Chrome aún está definiendo los requisitos de nuestra política y tendrá en cuenta estos comentarios. |
| Conjuntos propios | Proceso para mantener la lista de FPS de navegadores | Inquietudes sobre las barreras de entrada a sitios web en países no occidentales, las versiones inconsistentes de la lista de FPS para los navegadores debido a las diferencias en la frecuencia de actualización y la capacidad de los navegadores más pequeños o nuevos para usar la lista | Chrome sigue definiendo los requisitos de nuestra política, el proceso de aceptación y los derechos de uso de la lista, y tendrá en cuenta estos comentarios.
Chrome también analizará el aprendizaje de otras listas estáticas utilizadas en la plataforma web, como la lista pública de sufijos |
| Conjuntos propios | Diseño de aserción dinámico por sitio | Un diseño dinámico (a diferencia de una lista estática) podría ser más propenso a afirmaciones falsas de propiedad común y a fallas o latencia de carga de la página. | Actualmente, Chrome busca el enfoque de lista estática. Ten en cuenta estos comentarios si se vuelve a evaluar el enfoque de aserciones firmadas en el futuro. |
| Conjuntos propios | Posibles casos de uso para conjuntos propios (si se puede crear una versión confiable y equitativa de la lista de FPS) | Inicio de sesión único, mensajes de datos personalizables y posibilidades de informes de transparencia mejorados para los usuarios. | Chrome tendrá en cuenta estos comentarios a medida que considera los próximos pasos para los conjuntos propios |
| CHIPS | 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. |
| CHIPS | Requisito de diseño | Preocupación de que podría no ser factible incluir el prefijo de nombre de host __ | Chrome quitó el requisito de denominación para la prueba de origen y evaluará si se hará permanente al final del período de prueba. |
| CHIPS | Uso de CHIPS para casos de uso de anuncios | Preguntas sobre si es posible usar CHIPS para casos de uso de anuncios | CHIPS permite que un tercero cree cookies del cliente que se particionan en función del sitio de nivel superior (o su conjunto propio). Si el caso de uso necesita un estado de partición en lugar de un estado entre sitios, entonces se puede usar CHIPS para ese caso de uso. |
| CHIPS | Integración de CHIPS con FPS | Preocupación de que las pruebas con CHIPS podrían no ser posibles junto con otras propuestas de Privacy Sandbox, como los conjuntos propios | Chrome está explorando activamente cómo facilitar entornos de prueba que permitan que se lleven a cabo este tipo de pruebas. Chrome también publicó instrucciones para las pruebas locales de FPS y CHIPS, que puedes usar mientras tanto. |
| FedCM | 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 reconoce el inconveniente y continuará trabajando con el ecosistema para abarcar tantos temas como sea posible y hacerlo lo más expresivo posible. Algunas ideas que Chrome está explorando incluyen la personalización de marcas (por ejemplo, logotipos y colores) y la personalización de cadenas (p. ej., "acceder a este artículo" en lugar de "acceder con"). |
| FedCM | Participación del navegador | Preocupación de que el navegador esté más involucrado en el flujo de federación de identidades que antes, por lo que está al tanto de forma más explícita de los sitios web a los que accedió el usuario (también con qué IdP). | Chrome reconoce que el navegador ahora desempeña un papel más activo, pero este nivel adicional de participación es necesario para que el navegador distinga y evite el seguimiento entre sitios, sin dejar de admitir la federación. |
| FedCM | 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. |
| FedCM | Varios desafíos de la API | Preocupación de que FedCM aún es pionero o maduro y le llevará mucho tiempo ofrecer todas las funciones que necesita el ecosistema. | Chrome explorará esto más a fondo como parte de las pruebas del ecosistema. |
| FedCM | Políticas empresariales y controles de usuario | Preocuparse por si habrá un control (p.ej., políticas empresariales o configuración del usuario) que permita a las empresas mantener su implementación de identidad federada sin ningún cambio. Hay muchas implementaciones locales de identidad federada que son excepcionalmente difíciles de volver a implementar o cambiar, por lo que hay mucha resistencia hacia las nuevas APIs de navegadores que requieren que los IdP vuelvan a realizar la implementación. | Chrome está explorando controles para los administradores y usuarios empresariales que considere que resolverán estas inquietudes. Chrome agradece los comentarios de las empresas sobre casos de uso específicos que les gustaría que se tengan en cuenta. |
Combate el spam y el fraude
| API y tecnología | Tema de comentarios
(Clasificado por prevalencia por API) |
Resumen de preguntas e inquietudes | Respuesta de Chrome |
| API de Trust Token | Límites de canje | Inquietudes que alrededor de 2 por página son demasiado restrictivas, en especial para situaciones en las que una de ellas podría estar incorporada en la misma página varias veces o tener un segundo dominio de entidad emisora dentro de su organización Es probable que uno mismo alcanzara el límite sin considerar a otros participantes del mercado. | Chrome está dispuesto a ampliar ligeramente el límite de canje por página si aumenta la adopción, pero necesita mantenerlo relativamente bajo para introducir una entropía excesiva. Además, almacenar en caché un registro de canje puede reducir la necesidad de que una entidad emisora canjee varios tokens de un mismo usuario en un período breve. |
| API de Trust Token | Latencia | Por lo general, las solicitudes de oferta deben responderse en un plazo de 10 ms o menos, por lo que el canje de un token en la primera página que se carga hace que sea casi imposible incluir en las decisiones de tráfico no válido anterior a la oferta | Chrome intenta comprender cómo afecta la latencia a los casos de uso anteriores a la oferta mediante pruebas. |
| API de Trust Token | Adopción de OpenRTB | Para los casos de uso de Prebid, es fundamental pasar la información del token canjeado a las SSP y DSP para usarla en la toma de decisiones sobre anuncios | Chrome está abierto a colaborar con IAB para ayudar a garantizar que cualquier señal útil de protección contra fraudes y abusos se pueda propagar a través de openRTB, aunque posee el estándar para agregar todos los campos predeterminados nuevos. |
| API de Trust Token | Privacidad | Preguntas sobre la viabilidad a largo plazo de cualquier forma de propagación de datos entre sitios, aunque con poca cantidad de entropía (~2.5 bits) | Dadas las sólidas protecciones de usuario para evitar la capacidad de identificación de usuarios únicos, Chrome cree que hay un buen argumento para aceptar el ecosistema. Chrome trabaja estrechamente con partes interesadas clave para garantizar la viabilidad a largo plazo. |
| Indicadores de certificación de la plataforma | Medición del interés en una nueva idea/propuesta | Compatibilidad sólida con varios indicadores factibles (e inviables), como la transmisión de indicadores de integridad de dispositivos que la plataforma puede proporcionar | Chrome planea llevar esta idea al grupo comunitario contra el fraude de W3C como una nueva idea para recibir comentarios. |
| Servidores confiables y antifraude | Medición del interés en una nueva idea/propuesta | Es un concepto interesante, pero es probable que requiera más investigación de 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. |