Informe trimestral del 1ᵉʳ trimestre de 2023 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.
Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se realiza una agregación de la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas de comentarios comunes, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos de Google y los formularios públicos.
Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios público. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de las preguntas frecuentes publicadas, las respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. En función del enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, FLEDGE y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período de informes actual aún no tengan una respuesta de Chrome.
Glosario de acrónimos
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- FPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IDP
- Proveedor de identidad
- IETF
- Internet Engineering Task Force
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Usuario de confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- Cadena de usuario-agente
- UA-CH
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera IP intencional
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Pruebas | Relevancia de las pruebas para informar la evaluación de la CMA si las APIs de Privacy Sandbox no están completas cuando comienza la prueba | El desarrollo de las APIs de Privacy Sandbox avanza a buen ritmo.
Ya están disponibles en la prueba de origen para pruebas y estarán disponibles para el 100% del tráfico este verano. Además, aclaramos los cronogramas de ciertas funciones (como los informes a nivel del evento de FLEDGE y la renderización de FLEDGE con iframes) que no se verán afectadas antes de 2026. Animamos al ecosistema a probar las APIs y a proporcionar comentarios a la CMA según lo que los verificadores esperan usar una vez que las cookies de terceros dejen de estar disponibles. Esto puede contribuir a su evaluación del posible impacto de la baja de las cookies de terceros. |
| Controles de usuario | Orientación clara al ecosistema sobre las implicaciones de los controles de usuario de las APIs de Privacy Sandbox | No podemos brindar asesoramiento legal sobre los controles de usuario que puede usar el ecosistema. Al mismo tiempo, Chrome está experimentando con mostrar controles de usuario actualizados de Privacy Sandbox ("Privacidad mejorada de los anuncios") a un porcentaje muy pequeño de usuarios, como parte de nuestro esfuerzo continuo por mejorar las tecnologías de Privacy Sandbox. Las actualizaciones incluyen un lenguaje y diseños más claros y útiles. Una vez que Chrome haya evaluado estos refinamientos y decida si expandirlos a una población más grande, podrá compartir más información con el ecosistema. |
| Filtración de datos | Riesgo de filtración de datos de origen a Google y a otras partes en caso de que se vea comprometido el navegador | En nuestra explicación de FLEDGE, queda claro que los datos de una tecnología publicitaria solo se comparten con esa misma tecnología publicitaria (ya sea con sus worklets o sus servidores de confianza) o cuando esa tecnología publicitaria los comparte de forma explícita (por ejemplo, cuando un comprador le muestra a un vendedor la URL del anuncio que desea mostrar). La única excepción es que la verificación de k-anonimato debe realizarse en un servidor global centralizado, un área a la que seguimos dedicando recursos significativos. Consulta la explicación de la anonimización por k para obtener una vista detallada de cómo pensamos en la privacidad. Además, podemos proporcionar más detalles sobre cómo funcionan las protecciones de la tecnología publicitaria que se emplean en el diseño del servidor de k-anonimato. |
| Foro adicional para el debate | Solicitud de un foro adicional al W3C para que los participantes del ecosistema no técnicos compartan comentarios | El formulario de comentarios de Privacy Sandbox es adecuado para comentarios generales y específicos, técnicos y no técnicos. El grupo de ubicaciones de la empresa para mejorar la publicidad web es un foro para debatir a través de llamadas semanales y un repositorio de GitHub. En la página Comentarios de Privacy Sandbox, se explican otros mecanismos para proporcionar comentarios y participar en debates. Chrome también sigue organizando eventos, como sesiones públicas, para facilitar las preguntas y el uso compartido de contenido. Además, Chrome organizó o asistió a más de una docena de eventos de la industria durante el último trimestre. |
| Aclaración sobre el cronograma | Aclaración sobre la fecha exacta de la disponibilidad general en el 3ᵉʳ trimestre de 2023 | Según el cronograma publicado en PrivacySandbox.com, la disponibilidad general se lanzará con la versión 115 de Chrome. |
| reCAPTCHA | Impacto de las APIs de Sandbox para el caso de uso de detección de spam de reCATPCHA | Recibimos comentarios de reCAPTCHA periódicamente para garantizar que las propuestas de Privacy Sandbox no afecten de manera significativa la seguridad web ni el fraude. Están desarrollando su propio plan para prepararse y adaptarse a la baja de las cookies de terceros, por lo que es mejor que ellos respondan esta pregunta. |
| Extensiones de Chrome | ¿Las tecnologías de Privacy Sandbox, como las medidas contra el seguimiento encubierto (ACT), se aplicarán a las extensiones de Chrome? | No hemos hecho ningún anuncio sobre si la ACT se puede aplicar a las extensiones de Chrome. Sin embargo, si una tecnología recopila información sobre un usuario de forma encubierta, esto no se alinearía con nuestros principios de privacidad. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Revisión de diseño de TAG | TAG publicó la Revisión temprana del diseño de Topics. | Mantenemos nuestro compromiso con Temas y compartimos una actualización sobre este tema en la página de actualizaciones más recientes y en este número. Respondimos, punto por punto, a la revisión de TAG y compartimos nuestra visión de nivel superior aquí. La API de Topics seguirá siendo parte de la colección de APIs que el ecosistema de anuncios debe probar durante 2023. Esperamos que los comentarios de las pruebas y la experiencia de implementación que obtengamos sean contribuciones valiosas en los futuros esfuerzos para trabajar en estándares multinavegador en este espacio. Esperamos seguir interactuando con el ecosistema para facilitar una posible transición en la que la API de Topics podría ser un estándar acordado con compatibilidad multinavegador. |
| Enfoque de los temas | Compatibilidad con el enfoque abierto que tiene Chrome para desarrollar la API de Topics | Agradecemos tu opinión y esperamos seguir trabajando con el grupo de la industria para desarrollar una API de Topics que aporte valor al ecosistema en general. |
| (También se informó en el tercer trimestre de 2022) La taxonomía de temas no es lo suficientemente detallada. |
La taxonomía de temas generales no incluye temas más detallados, incluidos los específicos de la región. | Actualización del 1ᵉʳ trimestre: Las mejoras en la taxonomía son un esfuerzo continuo y, en el 2ᵉʳ trimestre, anunciaremos una taxonomía actualizada para la API de Topics. Para crear esta nueva taxonomía, trabajamos en estrecha colaboración con empresas de todo el ecosistema. Estamos buscando activamente comentarios sobre la taxonomía que sería más útil para el ecosistema. Cuando evalúes si expandir la cantidad de temas o incluir temas más detallados, ten en cuenta algunas consideraciones, como 1) las posibles implicaciones de privacidad (más temas pueden generar un riesgo de creación de huellas digitales) y 2) la capacidad de recuperar temas observados anteriormente (por ejemplo, con más temas, es posible que haya menos probabilidades de que una tecnología publicitaria haya visto el tema elegido en el pasado). |
| (También se informa en el cuarto trimestre de 2022) Impacto en los indicadores propios |
El indicador de temas puede ser muy valioso y, como resultado, desvaloriza otros indicadores basados en intereses propios. | Creemos que la publicidad basada en intereses es un caso de uso importante para la Web, y Topics está diseñado para admitir ese caso de uso. Entendemos que algunos publicadores grandes temen que Topics afecte negativamente sus estrategias de datos de origen. Esperamos con ansias las pruebas del ecosistema, que nos proporcionarán estadísticas sobre el impacto que Temas tiene en los publicadores. |
| Casos de uso de temas no relacionados con Google Ads | Uso de Topics para fines distintos de mostrar publicidad basada en intereses | Topics está diseñado para abordar el caso de uso de la publicidad basada en intereses, que creemos que es un caso de uso fundamental para la Web libre y abierta. Actualmente, estamos evaluando y buscando comentarios sobre otros casos de uso. |
| Estado de habilitación predeterminado | Impactos de la legislación regional para el consentimiento predeterminado de Topics | No es nuestra función comentar sobre opiniones legales. |
| (También se informó en el 3ᵉʳ trimestre de 2022) Sitios con categorías incorrectas |
Segmentación de anuncios cuando los temas se clasifican de forma incorrecta para un sitio determinado | Actualización del 1ᵉʳ trimestre: En el 2ᵉʳ trimestre, anunciaremos un clasificador actualizado para la API de Topics y esperamos interactuar con el ecosistema en él. En respuesta a los comentarios actuales, 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 sigue evaluando opciones para que los sitios contribuyan a la clasificación de temas. Cualquier mejora de utilidad debe sopesarse con los riesgos de privacidad y abuso. Por ejemplo, algunos de los riesgos incluyen sitios que usan el autoetiquetado como método para codificar diferentes significados (y potencialmente sensibles) en los temas, sitios que tergiversan sus temas para obtener ganancias financieras, sitios que atacan temas para reducir su utilidad para otros (por ejemplo, enviar spam a los temas del usuario con ruido sin sentido). El público puede inspeccionar estos componentes, con herramientas disponibles a través de chrome://topics-internals o este colab. Con las pruebas, esperamos que la clasificación mejore con el tiempo y agradecemos los comentarios sobre ejemplos de sitios que podrían estar mal categorizados. |
| Clasificador de temas | Solicita que se devuelva información adicional que muestre los motivos cuando se devuelva "No topics" al llamador con fines de depuración. | Entendemos y apreciamos que las herramientas de depuración son útiles para los desarrolladores, ya que trabajan para integrar la API de Topics en sus sistemas. Sin embargo, si exponemos información adicional (como el motivo por el que no se mostraron temas), es posible que, de forma involuntaria, compartamos información que les permita a las partes descubrir detalles adicionales (por ejemplo, si un usuario está en modo Incógnito, inhabilitó la API, etcétera) más allá de lo previsto, lo que perjudicaría la privacidad del usuario. Si bien no tenemos previsto proporcionar herramientas de depuración adicionales en este momento, estamos abiertos a recibir comentarios sobre qué herramientas serían valiosas. |
| Recuperación de información privada (PIR) | Solicitud para que la API de Topics adopte la recuperación de información privada | Anteriormente, investigamos el uso de PIR y compartimos las compensaciones aquí. |
| Flujo de ofertas | ¿Los temas se representarán de forma distinta a los públicos definidos por el vendedor en el flujo de ofertas? | La API de Topics es una propuesta de Privacy Sandbox desarrollada por Chrome, que es distinta de la propuesta de Seller-Defined Audiences de IAB Tech Lab. Esperamos que ambos se representen de forma distinta dentro del flujo de ofertas. Obtén información sobre cómo se representarán los temas en las solicitudes de oferta de OpenRTB. |
API de Protected Audience (antes conocida como FLEDGE)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Disponibilidad de funciones de FLEDGE | Se aclararon los cronogramas de prueba e implementación de las funciones de FLEDGE, como la aplicación forzosa de marcos delimitados, el k-anonimato, etcétera. | Compartimos el estado de varias funciones de FLEDGE centradas y cuándo se admitirán. Agradecemos los comentarios adicionales sobre el anuncio mientras seguimos desarrollando FLEDGE. |
| Restricciones de renderización de productos | Solicitud para flexibilizar las restricciones de los anuncios compuestos por varias piezas para los marcos de FLEDGE | Como anunciamos en febrero, el uso de marcos delimitados seguirá siendo opcional hasta, al menos, 2026, y el comportamiento de los iframes será compatible con urn-iframes. Te agradeceríamos que nos brindes más detalles sobre este tema. |
| Problemas de escalabilidad | Rendimiento de FLEDGE a medida que aumenta el uso | Estamos haciendo un seguimiento activo de los comentarios y entendiendo mejor el contexto para poder proponer soluciones prácticas. El primer paso fue separar los comentarios en dos categorías, lo que hicimos:
|
| (También se informó en el tercer trimestre de 2022) Visibilidad de la lógica de ofertas |
Preocupación por que la lógica de ofertas de la DSP se exponga en JavaScript | Actualización del 1ᵉʳ trimestre: Compartimos una propuesta que limitaría la capacidad de los adversarios de solicitar datos del servidor de forma exploratoria (navegación forzada). Invitamos a los actores del ecosistema a compartir sus comentarios o su apoyo a la propuesta. |
| Dificultades de las pruebas | Posibilidad de que las DSP más pequeñas prueben FLEDGE de forma adecuada y mitiguen el riesgo de que a los anunciantes solo les interese realizar pruebas con DSP más grandes | Nos comprometemos a trabajar con DSP más pequeñas y recomendamos encarecidamente que se realicen pruebas expandidas entre DSP y anunciantes de todos los tamaños a medida que FLEDGE pasa a la disponibilidad general. Nos interesa saber cómo podemos ayudarlos a probar FLEDGE con otros miembros del ecosistema y recibimos con gusto las ideas y los esfuerzos de la industria para motivar a los anunciantes a realizar pruebas con DSP más pequeñas. |
| Remarketing dinámico | ¿Se podrá seguir usando el remarketing dinámico con FLEDGE después de la baja de las cookies de terceros? | Estamos considerando una respuesta a esta pregunta y les damos la bienvenida a los participantes del ecosistema para que compartan estadísticas adicionales sobre cómo pretenden usar el remarketing dinámico. |
| Fraude o abuso | ¿Cómo puede el ecosistema reducir los riesgos y evitar que las personas o compradores que actúan de mala fe se posicionen como un público deseable? | Esperamos interactuar más con los actores del ecosistema sobre el fraude y el abuso, y recibir más comentarios sobre este tema. |
| Preferencias de usuario | Proceso para guardar las preferencias del usuario y usarlas en la selección de anuncios | En el caso de los anuncios específicos, la tecnología publicitaria relevante es la parte mejor posicionada para ofrecer controles sobre qué creatividades se muestran o cómo se seleccionan. |
| Propuesta de pruebas cuantitativas | Para que las pruebas cuantitativas sean justas, ¿se debe realizar la prueba en el tráfico sin cookies de terceros o con SSP que solo usen FLEDGE? ¿Cómo se puede evitar la combinación de indicadores de las cookies de terceros? | Agradecemos estos comentarios y estamos trabajando junto con la CMA para diseñar experimentos que proporcionen una imagen confiable del impacto de la baja de las cookies de terceros y la introducción de las propuestas de Privacy Sandbox en el ecosistema. Te recomendamos que compartas directamente con la CMA los comentarios adicionales sobre la propuesta de pruebas cuantitativas de la CMA. |
| Documentación más clara | Solicita documentación más clara sobre la configuración de subastas | Esperamos compartir una entrada de blog con una descripción general adicional de los informes de subastas de FLEDGE en las próximas semanas. |
| Paralelización | ¿El servicio de ofertas y subastas (B&A) admitirá la paralelización? | Una tecnología publicitaria que usa servidores de ofertas o subastas puede iniciar varios servidores que pueden entregar resultados en paralelo. |
| Mitigación de abusos | ¿El servidor de anonimato k de FLEDGE que usa tokens de estado privados será suficiente para garantizar la privacidad del usuario? | La motivación para el k-anonimato se enfoca menos en la segmentación micro y más en tener un resguardo durante la fase provisional en la que FLEDGE permite informes a nivel del evento. Compartimos más ideas y agradecemos los comentarios adicionales. |
| Conflicto de módulos de ES | Solicitud para quitar generateBid como función global, ya que entra en conflicto con el módulo de ES |
Estamos analizando esta solicitud y agradecemos los comentarios adicionales. |
| Subasta de componentes | Solicitar que los publicadores tengan más control sobre los diseños de subasta | Plan de ofertas y subastas para admitir subastas de componentes, al igual que Chrome integrado en el dispositivo |
| Cronogramas de B&A | Claridad sobre el cronograma para las tecnologías publicitarias interesadas en probar los servidores B&A | Acabamos de actualizar la explicación de B&A y actualizamos la sección de cronograma para incluir definiciones claras de los cronogramas de las diferentes fases de las pruebas de B&A de Chrome, después de alinearnos con la CMA. |
| Esquema de control de tiempo de espera | Mejora del esquema de control de tiempo de espera disponible actualmente para FLEDGE | Esta es una propuesta interesante. Lo agregaremos a la fila de propuestas para estudiar y te informaremos sobre nuestros avances. |
| Flujos de ofertas de creatividades | Capacidad para revisar y filtrar una oferta ganadora en función de la creatividad | Esta es una propuesta interesante. Lo agregaremos a la fila de propuestas para estudiar y te informaremos sobre nuestros avances. |
reportWin |
Propuesta para proporcionar información adicional sobre la oferta con la puntuación más alta de un propietario de grupo de intereses diferente al ganador en la función reportWin |
Esta es una propuesta interesante. Consideraremos agregar indicadores adicionales en los informes agregados y agradecemos los comentarios adicionales aquí. |
| Tipos de eventos | Estandarizar los tipos de eventos en las APIs de medición cuando se integran con FLEDGE | Esta es una propuesta interesante. Lo agregaremos a la fila de propuestas para estudiar y te informaremos sobre nuestros avances. Esto requerirá coordinación con nuestros esfuerzos más amplios en este campo, ya que afectaría a otras APIs de Privacy Sandbox más allá de FLEDGE. Te invitamos a enviar comentarios adicionales aquí. |
| Soluciones a largo plazo para los informes a nivel del evento | Interés en mantener ciertos datos, como highestScoringOtherBid, disponibles incluso después de la baja de las cookies de terceros |
Como compartimos en la entrada de blog de febrero, los informes de ganancias de subasta a nivel del evento se admitirán hasta "al menos 2026". Por el momento, no tenemos más detalles para compartir, pero recibimos con gusto comentarios adicionales sobre por qué es importante mantener ciertos datos disponibles después de la baja de las cookies de terceros. |
| Límite de grupos de interés | ¿Cuál es el límite de la cantidad de grupos de intereses a los que un origen puede agregar un solo navegador? | Chrome permite hasta 1,000 grupos de intereses por propietario y hasta 1,000 propietarios de grupos de intereses. Se trata de límites de seguridad que no deben superarse durante el funcionamiento normal. |
| Indicadores a nivel del evento | Compatibilidad con una propuesta para tener indicadores a nivel del evento para generateBid y reportWin, que se podrían usar en el entrenamiento de aprendizaje automático |
Compartimos nuestra decisión sobre los indicadores diseñados por el navegador y los indicadores definidos por la tecnología publicitaria aquí y recibimos con gusto más comentarios. |
| Secuencia de comandos de ofertas | Incluye el ID de usuario en la URL de la secuencia de comandos de ofertas. | Esto no será posible, ya que FLEDGE tiene el requisito adicional de que la tupla del propietario del grupo de intereses, la URL de la secuencia de comandos de ofertas y la creatividad renderizada deben ser k-anónimas para que se muestre un anuncio. |
| Aplicación forzosa de K-anon | ¿Se aplica el k-anonimato en el par (componentAd, size)? | Sí, lo será. Consulta turtledove/issues/312. |
| Requisitos de los servicios de ofertas y subastas | ¿Cómo los servicios de B&A admiten a los participantes que se integran con FLEDGE integrado en el dispositivo y otros con servicios de B&A? | Aún estamos ultimando el diseño y agradecemos los comentarios adicionales que nos envíes aquí. |
| Atribución posterior a la vista | ¿Se admitirá la atribución posterior a la vista? | Actualmente, no tenemos ningún tipo de definición estándar de visibilidad y dependemos de la creatividad en sí para marcar un evento de vista. Consulta turtledove/issues/452. |
| Segmentación por usuarios similares | ¿Privacy Sandbox admite la "segmentación por usuarios similares"? | Estamos analizando el caso de uso aquí y agradecemos las entradas adicionales. |
| API de supervisión en tiempo real | Propuesta de un enfoque de supervisión de FLEDGE en tiempo real | Estamos analizando la propuesta y agradecemos las aportaciones adicionales que se hagan aquí. |
| Informes de FLEDGE | reportWin y reportResult deben realizarse en orden aleatorio para evitar informes excesivos o insuficientes. |
El vendedor debe ejecutar reportResult() primero, antes de que el comprador ejecute reportWin(), para que los indicadores del vendedor de reportResult() se puedan incluir en reportWin(). Consulta la explicación para obtener más información. |
| Servidores de pares clave-valor (K/V) personalizados | ¿Se admitirán servidores K/V personalizados en el futuro? | Estamos analizando la pregunta aquí y recibimos con gusto cualquier comentario adicional. |
| Subasta de nivel superior | ¿Se debe ser el servidor de anuncios para ejecutar las mecánicas de subasta de nivel superior? | La API de FLEDGE no especifica qué parte debe llamarla; no hay requisitos en ese sentido en el diseño de FLEDGE. Cualquier persona puede ejecutar la subasta de FLEDGE (incluidas las subastas de varios vendedores). Como se menciona en el informe del cuarto trimestre de 2022, FLEDGE permite que cada publicador elija la estructura de la subasta, incluida la elección de vendedores de componentes y de nivel superior. |
| Alcance de la API | ¿FLEDGE tiene la intención de trabajar con datos de origen? | En el segundo trimestre de 2023, publicaremos contenido en el que aclararemos que los datos de origen sí se pueden usar con FLEDGE para 1) usarlos como lógica para determinar la membresía en el grupo de intereses y 2) enviarlos como indicadores de ofertas del usuario para usarlos en la generación de lógica de ofertas posteriores. |
| Grupos de interés multidominio | Posibilidad de crear grupos de intereses de dominios cruzados | Cualquier información disponible en el momento de agregar un navegador a un grupo de interés se puede usar para informar a ese público. Cuando se eliminen gradualmente las cookies de terceros, se limitará la disponibilidad de los datos entre sitios para informar la creación de grupos de intereses. |
| Lógica de ofertas del cliente | Portar la lógica de ofertas existente del servidor al cliente | Nos interesa obtener más información sobre las áreas que representan un desafío o que actualmente no están disponibles en el proceso de portabilidad, y agradecemos cualquier comentario adicional o estadísticas. |
| Valores del servidor de par clave-valor | ¿Los valores del servidor de par clave-valor deben ser de tipo cadena? | El valor debe ser una cadena, pero puede almacenar objetos en JSON o en el buffer de protocolo y serializarlos en una cadena. |
| Lista de bloqueo de anunciantes | ¿Qué indicadores serían adecuados para proporcionar a un comprador para una lista de bloqueo de anunciantes? | El lugar adecuado está en auctionSignals o en perBuyerSignals. |
| Unidad de oferta | Compatibilidad con diferentes unidades de ofertas, como CPI y CPM | Nos gustaría obtener más información sobre por qué esto es necesario en función del diseño actual y recibir comentarios adicionales. |
| Lógica de subasta | ¿El navegador o el servidor de anuncios deciden quién gana una subasta? | Toda la selección de ganadores se ejecuta dentro de la zona de pruebas, y el código del vendedor toma todas las decisiones. El navegador solo proporciona un entorno sellado y privado dentro del cual se ejecuta el código del comprador y del vendedor. |
| Permissions-Policy | ¿Se seguirá aplicando la política de permisos de FLEDGE actual después de que finalice la prueba de origen? | En el caso de la Prueba de origen, las listas de entidades permitidas predeterminadas actuales de ambas funciones son temporales y se cambiarán. Nos interesa saber cuánto tiempo necesitarán las tecnologías publicitarias para prepararse para el cambio antes de que comencemos a aplicarlo. |
| Restricción de tamaño de la señal | Las solicitudes de indicadores de ofertas confiables se combinan en varios grupos de intereses con el mismo trustedBiddingSignalsUrl. El límite de tamaño de 2 MB es una restricción. |
La restricción existe para los llamadores integrados en el dispositivo para evitar que se saturen los recursos del dispositivo. Los emisores de un servidor de B&A tendrán una restricción más relajada. |
| Indicadores de informes | Agrega un indicador adicional, script-errors, para permitir la recuperación de la cantidad de errores del cliente por propietario del grupo de intereses y por computeBid o reportWin / reportResult. |
Estamos considerando las posibles inquietudes sobre la privacidad de esta propuesta y alentamos a los actores del ecosistema a que compartan estadísticas adicionales sobre por qué es necesario. |
| Tamaño de la ventana de K-Anon | Aumenta el tamaño de la ventana de K-Anon desde el límite actual de 7 días. | Estamos considerando esta opción y, por el momento, estamos esperando (y agradecemos) más aportes del ecosistema. |
| Rendimiento por dispositivo | ¿Cómo controla FLEDGE el rendimiento del dispositivo si el usuario pertenece a una gran cantidad de grupos de intereses? | FLEDGE ofrece varias opciones de tiempo de espera, priorización y límite en las SSP y DSP que brindan a las tecnologías publicitarias un control detallado en situaciones en las que el rendimiento del dispositivo puede ser un motivo para limitar la participación en la subasta cuando el dispositivo se encuentra en una gran cantidad de grupos de intereses. |
| Pruebas de los servicios de B&A | Solicita a los jugadores del ecosistema que usen su propio servidor durante la fase de prueba para tener más registros disponibles para la depuración. | B&A permite a los usuarios iniciar y escalar los servidores de proveedores de servicios en la nube aprobados. Para mantener la privacidad del usuario, aplicamos la ejecución dentro de un entorno de ejecución confiable (TEE). Pronto lanzaremos una explicación sobre la depuración de TEE de B&A y estamos desarrollando funciones para admitirla. Necesitamos más comentarios sobre el tema. |
| Requisitos reglamentarios | ¿FLEDGE trabajará con proveedores de servicios en la nube de diferentes países para ayudar a garantizar el cumplimiento de los requisitos reglamentarios locales? | Siempre estamos abiertos a sugerencias para otros proveedores de servicios en la nube, pero, por el momento, planeamos admitir, al menos, GCP y AWS cuando se aplique la baja de las cookies de terceros. Consulta esta explicación para obtener más información. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Análisis de datos del impacto del ruido | Orientación para realizar un análisis de datos sobre el impacto del ruido | Compartimos documentación adicional sobre el ruido y las decisiones de diseño que se pueden usar para cambiar el impacto del ruido en los datos de la tecnología publicitaria. También hay disponible una guía más detallada. |
| Informes nulos | Mayor claridad en la implementación de informes nulos | Actualmente, estamos trabajando en una propuesta para implementar informes nulos y pronto compartiremos más detalles. La implementación de informes nulos nos permitirá reducir los retrasos de los informes sin comprometer la privacidad. |
| Nivel de ruido | Cómo ajustar el nivel de ruido según la duración de la ventana de atribución | Aceptamos esta propuesta y estamos considerando agregarla a la especificación. Envía tus comentarios adicionales aquí. |
| Tamaño de los datos del activador | ¿Por qué el tamaño de los datos del activador está limitado a 3 bits? | El tamaño se limita a 3 bits y 8 valores distintos para garantizar que la cantidad de información contextual o entre sitios sobre un usuario sea limitada. Invitamos a los actores del ecosistema a enviar comentarios sobre si la parametrización actual para los informes a nivel del evento tiene sentido. |
| Activadores de informes a nivel del evento | Permite la priorización dentro de una clave de anulación de duplicación | Estamos explorando soluciones para este problema y recibimos con gusto más comentarios. |
| Asistencia con la depuración | Claridad sobre la depuración después de la baja de las cookies de terceros | Nos gustaría admitir la depuración después de la baja de las cookies de terceros y estamos considerando las opciones. Queremos recibir comentarios y más ideas. |
| Alternativas de conversión posclic | Solicita más orientación sobre las alternativas para las conversiones posclic | Recomendamos al ecosistema que use la API de Attribution Reporting como un sistema de medición privado duradero para los casos de uso de medición de conversiones aplicables. Existen otras alternativas, y los proveedores de tecnología publicitaria deberán decidir la solución adecuada en función de sus necesidades de privacidad y utilidad. |
| Casos de uso de facturación | Claridad sobre el grado en que Attribution Reporting admitirá casos de uso de facturación basados en conversiones | Estamos trabajando para publicar información de forma pública y aclarar el alcance de la API de Attribution Reporting para la facturación. En un principio, el alcance de la API de Attribution Reporting no era compatible directamente con la facturación de CPA, sino con la facturación de CPC y CPM, que es la estructura de facturación que usa la mayoría de las tecnologías publicitarias. Es posible que admitamos esta opción en el futuro si recibimos más comentarios sobre el ecosistema. |
| Compatibilidad con casos de uso | Documentación de casos de uso de la API de medición | Estamos trabajando para aclarar la documentación de todas las plataformas de informes de Privacy Sandbox. |
| Calidad del clic | Solicitud para agregar un indicador que distinga los clics intencionales y no intencionales en un anuncio | Estamos analizando la solicitud y agradecemos los comentarios adicionales. |
| Solución de medición | Compatibilidad con soluciones de medición en varias DSP | Los proveedores de medición pueden usar la API de Attribution Reporting para eliminar duplicados entre varias DSP. Además, proponemos la compatibilidad con una lista de URLs en attributionsrc, lo que facilitará que las DSP admitan solicitudes a la API de Attribution Reporting del proveedor de medición. Agradecemos cualquier comentario adicional sobre la propuesta anterior. |
| Informes a nivel del evento | Solicita que la cantidad de días antes de que se envíe el informe esté disponible directamente | Las tecnologías publicitarias ya pueden calcular esta solicitud con la información disponible actualmente. No recibimos ningún otro comentario del ecosistema con respecto a esta solicitud, pero estamos abiertos a recibirlos. |
source_registration_time |
Agrega source_registration_time en los informes de atribución a nivel del evento. |
Estamos considerando esta solicitud y recibimos con gusto comentarios adicionales sobre si los jugadores del ecosistema consideran que es una función útil. |
| Modo Incógnito | ¿Las soluciones de medición estarán disponibles cuando el usuario esté en el modo Incógnito? | No, las soluciones de medición no estarán disponibles cuando un usuario esté en el modo Incógnito. Las cookies de terceros están desactivadas de forma predeterminada en el modo Incógnito. |
| Salas limpias de datos | ¿Las APIs de medición serán compatibles con las salas limpias? | Una sala limpia de datos típica es un entorno en el que los datos de identificadores individuales de diferentes fuentes se suben a una base de datos para ejecutar análisis basados en la combinación de esos datos subyacentes. Los dos marcos de medición para las APIs de Privacy Sandbox son los informes a nivel del evento y los informes de resumen. Los informes a nivel del evento contienen un ID de evento proporcionado por la tecnología publicitaria que se podría usar en una sala limpia de datos, pero la información asociada al lado de la conversión será limitada y con ruido. Los informes agregables encriptados no se pueden usar directamente en una sala limpia, pero los resultados de resumen que proporciona el servicio de agregación se pueden usar como entrada para los análisis que realices o como información complementaria. |
Servicio de agregación
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en el 4º trimestre de 2022) Retrasos en los informes |
¿Cuál es el retraso de los informes esperado? | Actualización del 1ᵉʳ trimestre de 2023: Tras los comentarios de los socios, compartimos propuestas para reducir la demora y mitigar su impacto. Las dos propuestas recibieron la aprobación de las tecnologías publicitarias durante las llamadas de WICG. |
| Regla de no duplicados | ¿Cómo se controla un "informe agregable retrasado" si ya se procesaron los informes agregables que tienen el mismo ID compartido? | Compartimos una propuesta para agregar una demora adicional a los informes agregables y la definición de ID compartido para el servicio de agregación para abordar parcialmente el impacto de la pérdida de demora en la API agregada. Agradecemos cualquier comentario sobre la propuesta. |
| Procesamiento de datos | Solicita habilitar la compatibilidad con varios pases de datos respetando la privacidad diferencial con el presupuesto de privacidad | Estamos analizando la posibilidad de usar una forma más flexible de consumir el presupuesto de privacidad para habilitar este caso de uso y recibimos con gusto comentarios adicionales. |
| (También se informó en el 2° trimestre de 2022) Ergonomía de las consultas | Habilita la consulta agregada de claves. | Actualización del 1ᵉʳ trimestre de 2023: La solicitud de función aún está en proceso de consideración, pero no tenemos ninguna propuesta para compartir en este momento. |
| Limitaciones de las pruebas de origen | Se debe aclarar el alcance del servicio de agregación, como la “regla de no duplicados”, que actualmente no se aplica en la prueba de origen. | Estamos considerando actualizar nuestra documentación para aclarar qué estará disponible en la prueba de origen y qué en la versión GA. |
API de Private Aggregation
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Presupuesto de contribución de Private Aggregation | El presupuesto de contribución de nivel 1 es demasiado restrictivo. | Cada llamada a la API de agregación privada se denomina contribución. Para proteger la privacidad del usuario, se limita la cantidad de contribuciones que se pueden recopilar de una persona. Cuando sumas todos los valores agregables en todas las claves de agregación, la suma debe ser menor que el presupuesto de contribución. Con el diseño actual, establecemos un límite en las contribuciones de un origen de informes en particular durante las últimas ~24 horas (como un período continuo). Ese es el presupuesto de contribución de L1 que se menciona en los comentarios. Recomendamos que los desarrolladores escalen los valores que aportan en función del volumen esperado (es decir, no solo usen un valor de 1). Por lo tanto, podría ser conveniente usar un valor más pequeño para los eventos más comunes para evitar agotar el presupuesto. Actualmente, estamos buscando comentarios sobre el presupuesto de contribución de la API de Private Aggregation en el límite numérico y el alcance. Estamos considerando cambiar el alcance de por origen a por sitio y mover el límite existente a un período de diez minutos con un límite diario más grande. |
Limita el seguimiento encubierto
User-Agent Reduction/User-Agent Client-Hints
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Adopción de UA-R | De los 10,000 sitios principales del Reino Unido, solo el 1% de los sitios que usan publicidad programática envían sugerencias de cliente HTTP. Es posible que las DSP que no completaron la migración tengan un impacto en las capacidades de prevención de fraudes. | Después de ejecutar un análisis en el mismo conjunto de datos, descubrimos que, si tienes en cuenta el uso de UA-CH con la etiqueta <meta> HTML y las APIs de JavaScript, la cantidad de sitios que usan UA-CH es significativamente mayor que el 1% que se proporcionó en los comentarios. En función de esto y de otros aspectos, incluidos los comentarios del ecosistema, tenemos confianza en seguir adelante con el lanzamiento gradual de la Fase 6 de la reducción de UA, de acuerdo con el cronograma publicado, y mantener al CMA informado. Ten en cuenta que los sitios tuvieron casi dos años de tiempo de preparación para la transición y que aún está disponible una prueba de baja para los sitios que creen que no están listos. |
| Sugerencias para otros factores de forma | Solicitud para que UA-CH proporcione factores de forma adicionales, como TV y VR | Agradecemos esta propuesta y estamos considerando incorporarla al diseño. Envíanos tus comentarios adicionales. |
| Pruebas automáticas | Solicitud para resolver el error UA-CH en Chrome sin interfaz gráfica antes de que se envíe la fase 6 de la UAR | Se corrigió el error en cuestión. |
| Compatibilidad con UA-CH en iOS | Un sitio que se basa en información detallada de UA para casos de uso de anuncios señala que Chrome para iOS no es compatible. | En el caso de los navegadores para iOS que no sean Safari (incluido Chrome para iOS), el proyecto WebKit deberá agregar compatibilidad con UA-CH para que se puedan habilitar (ya que controlan la pila de red). |
IP Protection (antes Gnatcatcher)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Casos de uso de la ubicación geográfica (también informados en el cuarto trimestre) | La Protección de IP puede impedir que los casos de uso legítimos de la ubicación geográfica funcionen en el futuro, como la personalización de contenido basada en la ubicación geográfica. | Nuestra respuesta no ha cambiado desde el cuarto trimestre de 2022: "Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos de las direcciones IP. Estamos buscando comentarios del ecosistema sobre el nivel de detalle de la geolocalización de IP". |
| Cumplimiento de las normativas | Si una región tiene menos de 1 millón de habitantes, el umbral actual de 1 millón para la protección de IP impediría que los sitios web usen direcciones IP para el cumplimiento normativo. | Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos de las direcciones IP. Estamos buscando comentarios del ecosistema sobre el cumplimiento normativo de la protección de la propiedad intelectual. |
| Mitigación de abusos | Las partes pueden eludir la Protección de IP compartiendo direcciones IP no enmascaradas con otras personas. | Somos conscientes del riesgo de que la propuesta actual de protección de IP no impida técnicamente que las partes compartan direcciones IP sin enmascarar con otras. Estamos trabajando en mitigaciones que evitarán
este riesgo de abuso. A medida que iteramos en la propuesta, te recomendamos que envíes más comentarios y que los discutas. Específicamente, nos gustaría conocer los casos de uso en los que las partes creen que deben compartir direcciones IP sin enmascarar con otras partes. |
| Bloqueo de red | Las partes pueden eludir el bloqueo de red mediante proxies de protección de IP. | La entidad que realiza el bloqueo deberá inhabilitar la Protección contra IP en este caso. Respondimos al problema y recibimos con gusto más comentarios. |
| Listas de bloqueo de direcciones IP afectadas por la propuesta de Protección de IP | Muchas empresas de tecnología publicitaria utilizan una lista de bloqueo básica de direcciones IP, como la lista de IP del centro de datos de TAG, para evitar ofertas en inventarios de anuncios que tengan una alta probabilidad de ser fraudulentos (o, al menos, no monetizables). En caso de que una tecnología publicitaria también sea un servicio de seguimiento y pueda estar sujeta a la propuesta de Protección de la IP, es posible que esa empresa pierda la capacidad de realizar una verificación básica de los anuncios antes de comprar el inventario publicitario. | Te recomendamos que envíes más comentarios y que debatas sobre la propuesta de protección de la propiedad intelectual en relación con posibles problemas y soluciones. Una opción es aplicar listas similares a la Protección de IP, de modo que no usemos proxy para los clientes que provienen de direcciones IP marcadas anteriormente. |
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos propios
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Límite de dominios (también se informó en el cuarto trimestre) | Solicitud para expandir la cantidad de dominios asociados | Nuestra respuesta no ha cambiado desde el cuarto trimestre de 2022: "En las llamadas de WICG, aclaramos que Chrome se compromete a proporcionar una solución utilizable que también tenga en cuenta los intereses de privacidad de los usuarios. En ese sentido, agradecemos los comentarios de la comunidad sobre casos de uso específicos que podrían verse afectados por el límite de dominios, de modo que el equipo pueda considerar formas de abordar estos casos de uso y, al mismo tiempo, seguir protegiendo la privacidad del usuario." |
| Envío alternativo de FPS | Propuesta de una forma alternativa de enviar listas globales para FPS | En este momento, nos estamos preparando para enviar conjuntos propios (FPS) en Chrome y configuramos un repositorio centralizado de GitHub para aceptar envíos de conjuntos. Dado que esperamos que los FPS cubran una brecha con las soluciones de plataformas web existentes en preparación para la baja de las cookies de terceros, esperamos aprender de ellos cómo los autores de sitios aprovechan los FPS. A medida que la lista de conjuntos crece con el tiempo y el ecosistema se adapta a un mundo posterior a las cookies de terceros, también podemos madurar el proceso hasta el punto en que podamos considerar esquemas descentralizados alternativos, como el propuesto. Con el proceso actual, esperamos establecer períodos de actividad fijos, lo que nos permitirá evolucionar el proceso de entrada con el tiempo. Podemos volver a revisar esta idea una vez que el proceso de envío esté más maduro. |
| Moderación de repositorios | Implementar la moderación de la comunidad del repositorio de envíos de FPS para evitar abusos Las personas que actúan de mala fe pueden abrumar fácilmente el proceso con orígenes de quemador para proponer conjuntos, y un volumen abrumador de solicitudes podría afectar las operaciones de propuestas de conjuntos genuinas. | Intentamos que las verificaciones sean lo más objetivas posible, por lo que nos basamos en verificaciones de validación técnicas. Creemos que este es el enfoque más escalable para el proceso de envío. De acuerdo con este objetivo, también intentaremos garantizar que el proceso sea resistente a los envíos de spam o de teléfonos quemados. |
| Subconjuntos asociados | ¿FPS podrá admitir casos de uso de flujos de proveedores o SaaS de terceros a través de subconjuntos asociados? | Los flujos de proveedores externos o SaaS no son un caso de uso que, actualmente, se considere dentro del alcance de los conjuntos propios. Aceptamos comentarios adicionales sobre cómo se usan las cookies entre sitios para estos casos de uso. |
| Integración de FPS y CHIPS | Solicitud de integración de FPS y CHIPS para admitir casos de uso como las pruebas A/B | Estamos analizando este caso de uso y también consideramos analizarlo en una llamada de WICG. Recibimos comentarios adicionales aquí. |
| GDPR | Propuesta de un nuevo subconjunto de FPS que se modelará según los conceptos del RGPD | Analizamos esta propuesta de forma interna y la comparamos con otros comentarios recibidos, así como con nuestros objetivos de privacidad. Te enviamos una respuesta en la que explicamos por qué no llevaremos a cabo esta propuesta en este momento. |
| Memoria | Cambio esperado en el tamaño de la memoria del navegador cuando se incorpora la lista de FPS | Hay precedentes de navegadores que almacenan este tipo de listas con un impacto mínimo en la memoria, como la lista de protección contra el seguimiento de Disconnect. Si bien la lista de conjuntos propios se copiará de forma local en cada cliente de Chrome, seguiremos supervisando el tamaño del archivo y estamos seguros de que podemos optimizar el espacio en memoria. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Limitaciones de los marcos delimitados | Claridad sobre las limitaciones que imponen los marcos delimitados | En marzo, actualizamos nuestra explicación sobre los fotogramas con cercas, que proporciona información sobre sus capacidades. Aceptamos cualquier comentario adicional. |
| Expande la información de acceso | Solicitar que se expanda el acceso a la información de los fotogramas adyacentes | Queremos comprender mejor por qué este es un requisito del ecosistema y recibimos con gusto cualquier comentario adicional. |
| Marcos vallados y iframes | Preguntas sobre la paridad de funciones entre los marcos delimitados y los iframes | Todas las APIs y los informes disponibles de Privacy Sandbox estarán disponibles para los iframes y los FencedFrames de la misma manera. |
| Cómo cambiar el tamaño de los marcos vallados | La restricción de los cambios de tamaño de fotogramas afecta a ciertos casos de uso. | Nos interesa obtener más información sobre los tipos de casos de uso afectados por la restricción y recibir comentarios adicionales. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Worklets de terceros | ¿Pueden los terceros escribir en Shared Storage particionado por origen? ¿O llamas a otras worklets para la medición de terceros? | El origen del contexto de navegación en el que se ejecuta el código determina en cuyo almacenamiento compartido se escriben los datos. Cuando se agrega código de terceros a una página, este se puede incorporar como un iframe con su propio contexto de navegación, lo que le permite escribir en su propio origen. El código de terceros también se puede incorporar como una secuencia de comandos en lugar de un iframe, que no cambia el contexto de navegación, y el tercero puede escribir en el almacenamiento compartido del incorporador. Ten en cuenta que solo el propietario de ese almacenamiento compartido puede leerlo. |
| Anulación de duplicación | La anulación de duplicación no sería posible para las interacciones fuera del ecosistema de Chrome. | El almacenamiento compartido está diseñado para proporcionar resultados de alcance únicos basados en el navegador Chrome dentro de Chrome. Nos interesa trabajar con tecnologías publicitarias para comprender cómo se pueden usar estos resultados como parte de sus modelos de alcance más amplios. Entendemos que los resultados en sí solo pueden representar una parte de las interacciones y nos interesa trabajar con tecnologías publicitarias para explorar metodologías de modelado adicionales que se puedan superponer. |
| Ventana de visualización de conversiones | Solicita tener una ventana de visualización para el porcentaje de conversiones para ver los cambios en las conversiones a lo largo del tiempo | Esto se puede implementar mediante el procesamiento de las diversas rutas de conversión en el lado del cliente con el almacenamiento compartido, lo que brinda flexibilidad adicional para las estadísticas avanzadas en comparación con el almacenamiento seguro del navegador no particionado. |
| Período de vencimiento del artículo | Solicitud para extender el período de vencimiento a 90 días | La política de retención de datos se actualizó en noviembre de 2022 y establece que cada clave se borra después de treinta días de la última escritura. Nos complace recibir comentarios adicionales para comprender si la nueva política funcionará para el ecosistema. |
| Rotación de creatividades | Los casos de uso de la rotación de creatividades no reflejan las acciones reales después de la subasta. | Nos interesa saber la opinión de más empresas de tecnología publicitaria orientadas a la compra sobre si la documentación de rotación de creatividades es precisa o no. |
CHIPs
No se recibieron comentarios este trimestre.
FedCM
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Extremo de declaración de identidad | Permite de forma explícita solicitudes arbitrarias al extremo de la afirmación de identidad. | Colaboramos con Mozilla en esta solicitud de extracción para limitar la capacidad de los sitios web de realizar solicitudes de credenciales de origen cruzado de forma silenciosa sin causar molestias a los usuarios. Además, seguiremos revisando y abordando otros comentarios. |
| Cómo prepropagar la identidad | ¿Se puede usar FedCM para prepropagar formularios de acceso con un proveedor de identidad de la lista de FedCM? | La preocupación de este caso de uso es que puede provocar la filtración de información cuando un sitio que no interactuó con el usuario puede consultar la última IDP que usó el usuario. Estamos analizando este problema y valoramos los comentarios adicionales. |
| Selección de cuenta contextual | Propuesta para agregar indicadores contextuales en la IU de selección de cuenta | Estamos considerando esta propuesta y agradecemos los diálogos adicionales. |
Cómo combatir el spam y el fraude
API de Private State Tokens (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Encuesta de recopilación de capacidades | A principios del 1ᵉʳ trimestre, terminamos de recopilar los resultados de nuestra encuesta sobre las capacidades necesarias para varios casos de uso de prevención de fraudes y los compartimos públicamente (minutos, resultados). | Planeamos incorporar estos comentarios a medida que desarrollamos nuevas propuestas y prototipos para APIs específicas y que preservan la privacidad para capacidades de prevención de fraudes. Esperamos priorizar el desarrollo cuando haya una necesidad suficiente y una tecnología existente en la que podamos basarnos para presentar la función en la Web y, al mismo tiempo, preservar la privacidad del usuario. Por ejemplo, la integridad del dispositivo y del inicio obtuvo una clasificación alta, y muchas plataformas tienen APIs existentes que comparten de forma segura una evaluación de la integridad del dispositivo, por lo que es un buen candidato para explorar dentro de los grupos de la comunidad. |
| Comentarios sobre el intent de envío de PST | Como parte de la intención de enviar, recibimos una inquietud para continuar, ya que estamos usando una versión anterior de Privacy Pass. También recibimos comentarios sobre la falta de claridad de la especificación en algunas secciones y que se debe mejorar para facilitar la compatibilidad con los navegadores. | Planeamos implementar muchos de los cambios sugeridos en las especificaciones antes de enviarlos a GA, así como algunos cambios en la API. Los comentarios llegaron al final del primer trimestre, por lo que estamos haciendo un seguimiento de los problemas de GitHub con detalles específicos y una actualización de nuestro plan de lanzamiento (en curso, a partir de la publicación de este informe de comentarios). En el caso de los cambios más grandes en la API, estamos dispuestos a considerarlos, pero creemos que la mejor manera de avanzar es continuar con el lanzamiento a la disponibilidad general y obtener comentarios prácticos de más desarrolladores. Esperamos continuar con este debate y buscar la estandarización de los navegadores. Si y cuando surja un nuevo estándar, consideraremos adoptar y desarrollar un plan para realizar la transición con cuidado. |