Informe trimestral del primer trimestre de 2023 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 |
|---|---|---|
| Pruebas y pruebas | La relevancia de las pruebas para informar la evaluación de la CMA si no se completan las APIs de Privacy Sandbox antes de que comience la prueba. | El desarrollo de las APIs de Privacy Sandbox avanza a su ritmo.
Ya están disponibles en la prueba de origen para pruebas y, de forma general, estarán disponibles para el 100% del tráfico este verano. Además, aclaramos los cronogramas para 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. Recomendamos que el ecosistema pruebe las APIs y proporcione comentarios a la CMA en función de lo que esperan los verificadores una vez que las cookies de terceros dejen de estar disponibles. Esto puede contribuir a su evaluación del impacto probable 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 proporcionar 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 de anuncios mejorada") 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 perfeccionamientos y haya decidido si expandirlos a una población más grande, puede 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 el caso de que el navegador se vea comprometido | Nuestra explicación de FLEDGE hace evidente que los datos de una tecnología publicitaria solo se comparten con esa misma tecnología publicitaria (ya sea con sus worklets o servidores de confianza) o cuando se comparten explícitamente por esa tecnología publicitaria (por ejemplo, si un comprador le muestra a un vendedor la URL del anuncio que quiere mostrar). La única excepción es que la verificación del k-anonimato debe realizarse mediante un servidor centralizado global, que es un área a la que seguimos dedicando recursos significativos. Consulta la explicación del k-anonimato para obtener una vista detallada de nuestra visión de la privacidad. Más allá de eso, estamos dispuestos a proporcionar más detalles sobre cómo funcionan las protecciones de tecnología publicitaria empleadas en el diseño del servidor de k-anonimato. |
| Foro adicional de debate | Solicitud de un foro adicional al W3C para que los jugadores no técnicos del ecosistema compartan comentarios | El formulario de comentarios de Privacy Sandbox es apropiado para comentarios generales y específicos, técnicos y no técnicos. El Better Web Advertising Business Group es un foro para debatir mediante llamadas semanales y un repositorio de GitHub. En la página Comentarios de Privacy Sandbox en developer.chrome.com, se explican otros mecanismos para proporcionar comentarios y participar en debates. Chrome también sigue organizando eventos como horarios de atención públicos para facilitar las preguntas y el uso compartido de contenido. Además, Chrome albergó o asistió a más de una docena de eventos de la industria en el último trimestre. |
| Aclaración sobre el cronograma | Se aclaró la fecha exacta de disponibilidad general en el 3er trim. de 2023 | Según el cronograma publicado en PrivacySandbox.com, la disponibilidad general está prevista para comenzar el lanzamiento 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 tengan un impacto significativo en la seguridad web o el fraude. Están desarrollando su propio plan para prepararse y ajustarse a la baja de las cookies de terceros, por lo que es mejor responder esta pregunta. |
| Extensiones de Chrome | ¿Las tecnologías de Privacy Sandbox, como las medidas del seguimiento encubierto (ACT), se aplicarán a las extensiones de Chrome? | No recibimos ningún anuncio sobre si el ACT podría aplicarse a extensiones de Chrome. Sin embargo, si una tecnología recopila información sobre un usuario de forma encubierta, no se alinearía con nuestros principios de privacidad. |
Muestre anuncios y contenido relevantes
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Revisión de diseño de TAG | TAG lanzó la Revisión de diseño temprana de Topics. | Mantenemos nuestro compromiso con Topics y compartimos una actualización sobre nuestro compromiso con Topics en la página de actualizaciones más recientes y en este problema. Respondimos punto por punto a la revisión de TAG y compartimos nuestra visión de nivel superior aquí. La API de Topics seguirá formando parte de la colección de APIs que el ecosistema de anuncios debe probar durante 2023. Esperamos que los comentarios sobre las pruebas que recibamos y la experiencia de implementador que obtenemos sean contribuciones valiosas en los futuros esfuerzos para que funcionen los estándares entre navegadores en este espacio. Esperamos seguir colaborando con el ecosistema para facilitar una posible transición en la que la API de Topics pueda ser un estándar acordado con compatibilidad entre navegadores. |
| Enfoque sobre Topics | Compatibilidad con el enfoque abierto que Chrome tiene para desarrollar la API de Topics | Agradecemos la opinión y esperamos seguir trabajando con el grupo de la industria para desarrollar una API de Topics que proporcione valor al ecosistema en general. |
| (También se informó en el 3er trim. de 2022) La taxonomía de temas no es lo suficientemente detallada |
La taxonomía de temas generales no incluye temas más detallados, incluidas las específicas de una región. | Actualización del 1er trim.: Las mejoras en la taxonomía son un esfuerzo continuo, y en el segundo trimestre anunciaremos una taxonomía actualizada para la API de Topics. Para elaborar esta nueva taxonomía, trabajamos estrechamente con empresas de todo el ecosistema. Buscamos activamente comentarios sobre la taxonomía que sería más útil para el ecosistema. Cuando se evalúa si ampliar la cantidad de temas o incluir temas más detallados, hay 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 para recuperar temas ya observados (por ejemplo, cuando hay más temas, hay menos posibilidades de que una plataforma de tecnología publicitaria haya visto el tema elegido en el pasado). |
| (También se informó en el 4o trimestre de 2022) 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. Entendemos que a algunos publicadores grandes les preocupa que Topics afecte de forma negativa sus estrategias de datos de origen. Esperamos con ansias las pruebas del ecosistema, que proporcionarán estadísticas sobre el impacto de Topics en los publicadores. |
| Casos de uso de Temas no relacionados con Google Ads | Uso de Topics para otros fines además de mostrar publicidad basada en intereses | Topics está diseñado para abordar el caso de uso de publicidad basada en intereses, que creemos que es un caso de uso fundamental para la Web abierta y sin restricciones. Estamos buscando comentarios sobre otros casos de uso y estamos evaluando. |
| Estado de habilitación predeterminado | Impacto de la legislación regional para el consentimiento predeterminado de Topics | No es nuestra posición para comentar opiniones legales. |
| (También se informó en el tercer trimestre de 2022) Sitios con la categoría incorrecta |
Orientación de anuncios cuando los temas están en una categoría incorrecta de un sitio determinado | Actualización del 1er trim.: En el segundo trimestre, anunciaremos un clasificador actualizado para la API de Topics y esperamos poder interactuar con el ecosistema en cuestión. 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 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. Estos son algunos de los riesgos: sitios que usan el autoetiquetado como método para codificar significados diferentes (y potencialmente sensibles) en temas; sitios que tergiversan sus temas para obtener beneficios económicos; sitios que atacan temas con el fin de desafiar su utilidad para otros (por ejemplo, envían spam a los temas de los usuarios con ruido sin sentido). 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. |
| Clasificador de Topics | Solicitud para mostrar información adicional en la que se muestran los motivos por los que se muestra "No hay temas" al emisor 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, cuando se expone información adicional (como el motivo por el que no se mostró Topics), podemos compartir de forma involuntaria información que permite a las partes descubrir detalles adicionales (por ejemplo, si un usuario está en modo Incógnito, inhabilitó la API, etc.) más allá de lo previsto, lo que daña la privacidad del usuario. Si bien no planeamos 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 a la API de Topics para adoptar la recuperación de información privada | Ya investigamos el uso de PIR y compartimos las compensaciones aquí. |
| Flujo de ofertas | ¿Los temas se representarán de forma diferenciada de 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 Públicos definidos por el vendedor de IAB Tech Lab. Esperamos que ambos estén representados de forma clara en el flujo de ofertas. Obtén más información sobre cómo Topics se representará en las solicitudes de oferta de OpenRTB. |
API de Protected Audience (anteriormente, FLEDGE)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Disponibilidad de funciones de FLEDGE | Aclaramos los cronogramas para las pruebas y la implementación de las funciones de FLEDGE, como la aplicación forzosa de marcos protegidos, el anonimato de K, etcétera. | Compartimos una entrada de blog sobre varias funciones de FLEDGE con alcance y cuándo se admitirán. Agradecemos los comentarios adicionales sobre el anuncio a medida que seguimos desarrollando FLEDGE. |
| Restricciones de renderización de productos | Solicitud para flexibilizar las restricciones de anuncios compuestos por varias piezas para marcos cercados de FLEDGE | Como anunciamos en febrero, el uso de Fenced Frames seguirá siendo opcional hasta al menos en 2026, y el comportamiento de iframes será compatible con urn-iframes. Te pedimos que continúes conversando sobre este tema. |
| Problemas de escalabilidad | Rendimiento de FLEDGE a medida que se escala el uso | Estamos realizando un seguimiento activo de los comentarios y comprendiendo más contexto para poder proponer soluciones prácticas. El primer paso fue separar los comentarios en dos categorías:
|
| (También se informa en el tercer trimestre de 2022) Visibilidad de la lógica de ofertas |
Inquietud de que la lógica de ofertas de la DSP se exponga en JavaScript | Actualización del 1er trim.: Compartimos una propuesta que limitaría la capacidad de los adversarios de solicitar datos del servidor de forma exploratoria (forzar la navegación), y aceptamos que los jugadores del ecosistema compartan sus comentarios o su asistencia con respecto a la propuesta. |
| Dificultades para las pruebas | Capacidad de DSP más pequeñas para probar correctamente FLEDGE y mitigar el riesgo de que los anunciantes solo estén interesados en probar con DSP más grandes | Nos comprometemos a trabajar con DSP más pequeñas y recomendamos que ampliemos las pruebas entre DSP y anunciantes de todos los tamaños a medida que FLEDGE pase a la disponibilidad general. Nos gustaría saber cómo podemos ayudarlos a probar FLEDGE con otros en el ecosistema, además de recibir ideas y esfuerzos de la industria para motivar a los anunciantes a probar con DSP más pequeñas. |
| Remarketing dinámico | ¿El remarketing dinámico seguirá siendo posible con FLEDGE tras la baja de las cookies de terceros? | Consideramos responder a esta pregunta y agradecemos que los participantes del ecosistema 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 que actúan de mala fe o los compradores se posicionen como un público deseable? | Esperamos poder interactuar más con los participantes del ecosistema en relación con el fraude y el abuso, y agradecemos que nos envíes más comentarios al respecto. |
| Preferencias de usuario | Proceso para guardar las preferencias del usuario y usarlas en la selección de anuncios | En el caso de anuncios específicos, la tecnología publicitaria relevante es la que mejor se posiciona para ofrecer controles sobre las creatividades que se muestran o cómo se seleccionan. |
| Propuesta de prueba cuantitativa | Para que las pruebas cuantitativas sean justas, ¿la prueba debe realizarse en el tráfico sin cookies de terceros o con SSP que solo usan FLEDGE? ¿Cómo se puede evitar la combinación de indicadores de cookies de terceros? | Agradecemos estos comentarios y estamos trabajando con la CMA para diseñar experimentos que brinden un panorama confiable del impacto de la baja de las cookies de terceros y de la introducción de las propuestas de Privacy Sandbox en el ecosistema. Alentamos que los comentarios adicionales sobre la propuesta de pruebas cuantitativas de la CMA se compartan directamente con ellos. |
| Documentación más clara | Solicitud de documentación más clara sobre la configuración de subastas | Esperamos compartir una entrada de blog con una descripción general adicional sobre 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 k-anonimato de FLEDGE que usa tokens de estado privado será suficiente para garantizar la privacidad del usuario? | La motivación por el k-anonimato se enfoca menos en la microsegmentación y más en tener algo de retroceso durante la fase provisional en la que FLEDGE permite los informes a nivel del evento. Compartimos más opiniones y damos la bienvenida a otros comentarios. |
| Conflicto con el módulo de ES | Solicita que se quite 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 | Solicitud para que los publicadores tengan más control sobre los diseños de subasta | Plan de ofertas y subastas para admitir la subasta de componentes, al igual que Chrome en el dispositivo |
| Cronología de B&A | Claridad en el cronograma para las tecnologías publicitarias interesadas en probar servidores de B&A | Acabamos de actualizar la explicación de B&A y actualizamos la sección del cronograma para incluir definiciones claras de cronogramas para las diferentes fases de las pruebas de Chrome-B&A, después de alinearlos con la CMA. |
| Esquema de control de tiempo de espera | Mejora el esquema de control de tiempo de espera disponible actualmente para FLEDGE | Esta es una propuesta interesante. Agregaremos esto a la cola de propuestas para estudiar y, luego, informar sobre nuestros desarrollos. |
| Flujos de ofertas de creatividades | Capacidad de revisar y filtrar una oferta ganadora según la creatividad | Esta es una propuesta interesante. Agregaremos esto a la cola de propuestas para estudiar y, luego, informar sobre nuestros desarrollos. |
reportWin |
Propuesta para proporcionar información adicional sobre la oferta con la puntuación más alta de un propietario del grupo de interés diferente que no sea el ganador en la función reportWin |
Esta es una propuesta interesante. Consideraremos agregar indicadores adicionales en los informes agregados y recibiremos 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. Agregaremos esto a la cola de propuestas para estudiar y, luego, informar sobre nuestros desarrollos. Requerirá la 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. Recibiremos comentarios adicionales aquí. |
| Soluciones a largo plazo para los informes a nivel del evento | Interés en mantener algunos datos como highestScoringOtherBid disponibles incluso después de que se den de baja las cookies de terceros |
Como se compartió en la entrada de blog de febrero, se admitirán los informes de éxito de subastas a nivel del evento hasta, "al menos, 2026". No tenemos más detalles para compartir en este momento, pero aceptamos comentarios adicionales sobre por qué es importante mantener ciertos datos disponibles después de que las cookies de terceros dejen de estar disponibles. |
| Límite de grupos de interés | ¿Cuál es el límite para la cantidad de grupos de interés a los que un origen puede agregar un solo navegador? | Chrome permite hasta 1,000 grupos de interés por propietario y hasta 1,000 propietarios de grupos de interés. Se diseñaron como barreras de seguridad, no para que se alcancen en un funcionamiento normal. |
| Indicadores a nivel del evento | Compatibilidad con una propuesta para que tenga indicadores a nivel del evento para generateBid y reportWin, que podrían usarse en el entrenamiento de aprendizaje automático. |
Compartimos nuestra decisión con los indicadores diseñados por el navegador y los indicadores definidos por la tecnología publicitaria aquí y agradecemos que nos envíes tus comentarios adicionales. |
| 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 interés, 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 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 ayudan los servicios de B&A a la integración de FLEDGE en el dispositivo y a otros con servicios de B&A? | Todavía estamos finalizando el diseño y te damos la bienvenida a los comentarios adicionales aquí. |
| Atribución posterior a la vista | ¿Se admitirá la atribución posterior a la reproducción? | Actualmente, no tenemos ninguna definición estándar de visibilidad y dependemos de la creatividad para marcar un evento de vista. Consulta turtledove/issues/452. |
| Segmentación similar | ¿Privacy Sandbox puede admitir una "segmentación similar"? | Analizaremos el caso de uso aquí y recibiremos más comentarios. |
| API de supervisión en tiempo real | Propuesta de un enfoque de supervisión de FLEDGE en tiempo real | Estamos analizando la propuesta y le damos la bienvenida a los comentarios adicionales aquí. |
| Informes de FLEDGE | reportWin y reportResult deben hacerse en orden aleatorio para evitar informes excesivos o insuficientes. |
El comprador debe ejecutar reportResult() primero antes que el comprador 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 par clave-valor personalizado (K/V) | ¿Se admitirán los servidores K/V personalizados en el futuro? | Analizaremos la pregunta aquí y agradecemos cualquier comentario adicional. |
| Subasta de nivel superior | ¿Es necesario que uno sea el servidor de anuncios para ejecutar una mecánica de subasta de nivel superior? | La API de FLEDGE no especifica qué parte debe llamarla. No hay requisitos en ese sentido para el diseño de FLEDGE. Cualquier persona puede ejecutar la subasta de FLEDGE (incluidas las subastas de varios vendedores). Como se mencionó en el informe del 4o trim. 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 pretende funcionar con datos de origen? | En el segundo trimestre de 2023, publicaremos contenido en el que se aclarará que, con FLEDGE, los datos de origen se pueden usar como lógica para determinar la pertenencia a un grupo de interés y para 2) alimentarse como indicadores de ofertas del usuario a fin de utilizarlos en la generación posterior de la lógica de ofertas. |
| Grupos de interés multidominio | Posibilidad de crear grupos de interés multidominio | Toda la información disponible en el momento de agregar un navegador a un grupo de interés se puede utilizar para informar a ese público. Cuando se eliminen gradualmente las cookies de terceros, se limitará la disponibilidad de datos entre sitios para informar sobre la creación de grupos de interés. |
| Lógica de las ofertas del cliente | Cómo migrar la lógica existente de ofertas del servidor al cliente | Nos interesa obtener más información sobre las áreas que son desafiantes o que faltan en el proceso de portabilidad en este momento y agradecemos cualquier comentario o sugerencia adicional. |
| Valores del servidor de K/V | ¿Los valores del servidor de K/V deben ser de tipo cadena? | El valor debe ser una string, pero pueden almacenar objetos en JSON o un búfer de protocolo y serializarlos en una string. |
| Lista de anunciantes bloqueados | ¿Qué indicadores serían apropiados para proporcionar un comprador a una lista de anunciantes bloqueados? | El lugar apropiado es en auctionSignals o perBuyerSignals. |
| Unidad de ofertas | Compatibilidad con diferentes unidades de oferta, como CPI y CPM | Nos gustaría obtener más información sobre por qué esto es necesario debido al diseño actual y recibir comentarios adicionales. |
| Lógica de la subasta | ¿El navegador o el servidor de anuncios deciden cuál es el ganador de una subasta? | Toda la selección de ganador se ejecuta dentro de la zona de pruebas, y el código del vendedor toma todas las decisiones. El navegador simplemente proporciona un entorno sellado y privado dentro del que se ejecuta el código del comprador y el vendedor. |
| Política de permisos | ¿Se seguirá aplicando la política de permisos de FLEDGE actual después de que finalice la prueba de origen? | Para 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 plataformas de tecnología publicitaria para prepararse para el cambio antes de comenzar a aplicarlo. |
| Restricción de tamaño del indicador | Las solicitudes de indicadores de ofertas de confianza se combinan en varios grupos de interés con el mismo trustedBiddingSignalsUrl; el límite de tamaño de 2 MB es una restricción. |
La restricción existe para que los emisores integrados en el dispositivo eviten una sobrecarga de recursos en el dispositivo. Los emisores de un servidor de B&A tendrán una restricción más flexible. |
| Indicadores de informes | Agrega un indicador adicional, errores de secuencia de comandos, para permitir la recuperación de la cantidad de errores del cliente por propietario del grupo de interés y por computeBid o reportWin / reportResult. |
Consideramos posibles inquietudes sobre la privacidad en esta propuesta y damos la bienvenida a los participantes del ecosistema para compartir estadísticas adicionales sobre por qué esto es necesario. |
| Tamaño de ventana de K-Anon | Aumentar el tamaño de la ventana de K-Anon del límite actual de 7 días | Esto se encuentra en consideración y estamos esperando (y bienvenidos) entradas adicionales del ecosistema. |
| Rendimiento por dispositivo | ¿Cómo controla FLEDGE el rendimiento del dispositivo si el usuario está en una gran cantidad de grupos de interés? | FLEDGE ofrece varias opciones de tiempo de espera, priorización y límite entre las SSP y las DSP que brindan a las tecnologías publicitarias un control detallado de las situaciones en las que el rendimiento del dispositivo puede ser un motivo para limitar la participación en la subasta cuando el dispositivo está en una gran cantidad de grupos de intereses. |
| Prueba de los servicios de B&A | Solicitud para que los jugadores del ecosistema usen su propio servidor durante la fase de prueba a fin de tener más registros disponibles para la depuración | B&A permite a los usuarios iniciar y escalar los servidores desde proveedores de servicios en la nube aprobados. Para mantener la privacidad del usuario, aplicamos que la ejecución se realice dentro de un entorno de ejecución confiable (TEE). Pronto lanzaremos una explicación sobre la depuración de B&A TEE y estamos desarrollando funciones para admitirlo. Solicitamos comentarios adicionales sobre el tema. |
| Requisitos reglamentarios | ¿FLEDGE trabajará con proveedores de servicios en la nube en diferentes países para respaldar el cumplimiento de los requisitos normativos locales? | Siempre estamos abiertos a recibir sugerencias para otros proveedores de servicios en la nube, pero por el momento estamos planificando al menos admitir 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 comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Análisis de datos del impacto del ruido | Orientación para realizar análisis de datos sobre el impacto del ruido | Compartimos documentación adicional sobre las decisiones relacionadas con el ruido y el diseño que se pueden usar para cambiar el impacto del ruido en los datos de tecnología publicitaria. También se encuentra disponible una guía más detallada. |
| Informes nulos | Claridad en la implementación de informes nulos | Actualmente, estamos trabajando en una propuesta para implementar informes nulos y tendremos más detalles para compartir pronto. Implementar informes nulos nos permitirá reducir los retrasos en los informes sin comprometer la privacidad. |
| Nivel de ruido | Ajusta el nivel de ruido en función de la duración de la ventana de atribución | Aceptamos esta propuesta y estamos considerando agregarla a la especificación. Recibiremos 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 está limitado a 3 bits y 8 valores distintos para garantizar que la cantidad de información entre sitios o contexto sobre un usuario esté limitada. Les damos la bienvenida a los participantes del ecosistema a enviar comentarios para saber si la parametrización actual de los informes a nivel de 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 agradecemos que nos proporciones información adicional. |
| Asistencia con la depuración | Claridad en 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 analizando opciones. Esperamos recibir más ideas y comentarios. |
| Alternativas de conversión posclic | Solicitud de más orientación sobre alternativas para las conversiones posclic | Recomendamos que el ecosistema utilice la API de Attribution Reporting como un sistema de medición privado y duradero para casos de uso aplicables de medición de conversiones. 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 | Mayor claridad en cuanto a la medida en que Attribution Reporting admitirá casos de uso de facturación basada en conversiones | Estamos trabajando para hacer publicaciones públicas a fin de aclarar el alcance de la API de Attribution Reporting para la facturación. Al principio, la API de Attribution Reporting no tenía un alcance que admita directamente la facturación de CPA, sino que admite la facturación de CPC y CPM, que es la estructura de facturación que usa la mayoría del uso de las tecnologías publicitarias. Es posible que brindemos asistencia en el futuro si tenemos comentarios adicionales sobre el ecosistema. |
| Asistencia para casos de uso | Documentación de caso de uso para la API de Measurement | Estamos trabajando para aclarar la documentación de todas las plataformas de informes de Privacy Sandbox. |
| Calidad del clic | Solicitud para agregar indicadores a fin de distinguir clics intencionales y no intencionales en un anuncio | Estamos analizando la solicitud y agradecemos que nos envíes información adicional. |
| 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 anular la duplicación entre varias DSP. Además, proponemos admitir una lista de URLs en attributionsrc, lo que facilitará que las DSP admitan las 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 | Solicitud para que la cantidad de días antes del envío del 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 sobre el ecosistema relacionado con esta solicitud, pero estamos dispuestos a recibir comentarios al respecto. |
source_registration_time |
Se agregó source_registration_time en Attribution Reporting a nivel del evento. |
Consideramos esta solicitud y agradecemos los 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 Measurement serán compatibles con los espacios limpios? | Un espacio de limpieza de datos típico es un entorno en el que se suben datos de identificadores individuales de diferentes fuentes a una base de datos para ejecutar análisis basados en la combinación de esos datos subyacentes. Los dos frameworks de medición para las APIs de Privacy Sandbox son los informes de nivel de evento y los de resumen. Los informes a nivel del evento contienen un ID de evento proporcionado por la tecnología publicitaria que podría usarse en un espacio de limpieza de datos, pero la información asociada a las conversiones será limitada y ruidosa. Los informes agregables encriptados no se pueden usar directamente en un espacio limpio, pero los resultados resumidos que proporciona el servicio de agregación podrían usarse como una entrada en los análisis que realizas o como información complementaria. |
Servicio de agregación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en el 4o trimestre de 2022) Demoras en los informes |
¿Cuál es la demora esperada en la generación de informes? | Actualización del 1er trim. de 2023: A partir de los comentarios de los socios, compartimos propuestas para reducir el retraso y mitigar el impacto de los retrasos. Ambas propuestas cuentan con el respaldo de 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 sobre cómo agregar un retraso adicional en los informes a la información compartida de los informes agregables y la definición de ID compartido para que el servicio de agregación aborde 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 sin dejar de respetar la privacidad diferencial mediante el presupuesto de privacidad. | Estamos analizando la posibilidad de usar una manera más flexible de consumir el Presupuesto de privacidad para habilitar este caso de uso y recibir comentarios adicionales. |
| (También se informó en el segundo trimestre de 2022) Ergonomía de las consultas | Habilita la consulta de la agregación de claves. | Actualización del 1er trim. de 2023: La solicitud de función aún se está considerando, pero no tenemos ninguna propuesta para compartir en este momento. |
| Limitaciones de la prueba de origen | Aclara el alcance del servicio de agregación, como la regla “sin duplicados”, que actualmente no se aplica en la prueba de origen. | Estamos buscando actualizar nuestra documentación para aclarar qué estará disponible en la prueba de origen y en la de DG. |
API de Private Aggregation
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Presupuesto de contribución de agregación privada | El presupuesto de contribución de L1 es demasiado restrictivo. | Cada llamada a la API de Private Aggregation se denomina una contribución. Para proteger la privacidad del usuario, la cantidad de contribuciones que se pueden recopilar de una persona es limitada. Cuando sumas todos los valores agregables en todas las claves de agregación, la suma debe ser menor que el presupuesto de contribución. En el diseño actual, establecemos un límite en las contribuciones para un origen de informes específico durante las últimas 24 horas aproximadamente (como un período progresivo). Ese es el presupuesto de contribución de L1 que se menciona en los comentarios. Sin embargo, sugerimos que los desarrolladores escalen los valores que aportan en función del volumen esperado (es decir, no solo con un valor de 1). Por lo tanto, podría tener sentido usar un valor menor para los eventos más comunes a fin de evitar que se agote el presupuesto. En este momento, queremos recibir comentarios sobre el presupuesto de contribución de la API de Private Aggregation sobre el límite numérico y el alcance. Estamos considerando trasladar el alcance de por origen a por sitio y trasladar el límite existente a un período de diez minutos con un límite diario mayor. |
Limita el seguimiento encubierto
Reducción de usuario-agente/User-Agent Client-Hints
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Adopción de UA-R | De los 10,000 principales sitios en el Reino Unido, solo el 1% de los sitios que usan publicidad programática envían sugerencias de clientes HTTP. Las DSP que no se migraron pueden tener un impacto en las capacidades antifraude. | Tras ejecutar un análisis sobre el mismo conjunto de datos, descubrimos que si tienes en cuenta el uso de UA-CH mediante la etiqueta HTML <meta> y las APIs de JavaScript, la cantidad de sitios que usan UA-CH es significativamente mayor que la cifra del 1% proporcionada en los comentarios. En función de esto y otros factores, incluidos los comentarios sobre el ecosistema, nos sentimos seguros de avanzar con el lanzamiento gradual de la fase 6 de la reducción de UA, de acuerdo con el cronograma publicado, sin perder la información de la CMA. Notamos que los sitios tuvieron casi dos años de plazo de entrega para prepararse para la transición, y todavía hay una prueba de baja disponible para los sitios que consideran que no están listos. |
| Sugerencias para factores de forma adicionales | Solicitud para que UA-CH proporcione factores de forma adicionales, como TV o RV. | Agradecemos esta propuesta y estamos considerando incorporarla al diseño. Recibiremos comentarios adicionales. |
| Pruebas automáticas | Solicitud para resolver el error de UA-CH en Chrome sin interfaz gráfica antes del envío de la fase 6 de 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 en iOS no es compatible. | En el caso de los navegadores para iOS que no son de Safari (incluido Chrome en iOS), el proyecto WebKit deberá agregar compatibilidad con UA-CH antes de que se puedan habilitar (porque controla la pila de red). |
Protección de IP (anteriormente conocido como Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en el cuarto trimestre) Casos de uso de ubicación geográfica | La protección de IP puede impedir que funcionen en el futuro casos de uso legítimos de ubicación geográfica, como la personalización del contenido basada en la ubicación geográfica. | Nuestra respuesta no cambió en comparación con el cuarto trimestre de 2022: "Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos para las direcciones IP. Queremos recibir comentarios del ecosistema sobre el nivel de detalle de la ubicación geográfica de IP". |
| Cumplimiento de las normativas | Si una región tiene menos de 1 millón de población, 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 regulatorio. | Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos para las direcciones IP. Estamos solicitando comentarios del ecosistema sobre el cumplimiento de las normativas relacionadas con la protección de IP. |
| Mitigación de abusos | Las partes pueden eludir la protección de IP si comparten direcciones IP sin enmascarar 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 personas. Estamos trabajando en mitigaciones que eviten
este riesgo de abuso. A medida que iteramos sobre la propuesta, te animamos a que nos envíes más comentarios y debate. En concreto, nos gustaría conocer los casos de uso en los que las partes crean 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 de IP para este caso. Respondimos al problema y agradecemos sus comentarios adicionales. |
| Listas de bloqueos de direcciones IP afectadas por la propuesta de protección de IP | Muchas empresas de tecnología publicitaria usan una lista básica de direcciones IP de bloqueo, como la lista de IP de centros de datos de TAG, para evitar las ofertas por inventario de anuncios que probablemente sea fraudulento (o al menos no monetizable). En el caso de que una tecnología publicitaria también sea un rastreador y esté sujeta a la propuesta de protección de IP, esa empresa podría perder la capacidad de realizar una verificación básica de los anuncios antes de comprar el inventario de publicidad. | Te animamos a que envíes más comentarios y debates sobre la Propuesta de protección de IP sobre posibles problemas y soluciones. Una opción es aplicar listas similares a la protección de IP, de modo que no estamos usando proxy con clientes que se originan en direcciones IP marcadas con anterioridad. |
Fortalecer los límites de privacidad entre sitios
Conjuntos propios
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en el 4o trim.) Límite de dominios | Solicitud para expandir la cantidad de dominios asociados | Nuestra respuesta no cambió con respecto al 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, agradeceremos los comentarios de la comunidad sobre casos de uso específicos que pueden 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, proteger la privacidad del usuario”. |
| Envío de FPS alternativos | 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 FPS cubra una brecha con las soluciones existentes de las plataformas web como preparación para la baja de las cookies de terceros, esperamos aprender de ellos cómo los autores de sitios aprovechan FPS. A medida que la lista de conjuntos crece con el tiempo y el ecosistema se adapta a un mundo posterior de las cookies de terceros, también podemos madurar el proceso al punto de considerar esquemas descentralizados alternativos, como el propuesto. Con el proceso actual, esperamos establecer períodos de vigencia establecidos, lo que nos permitirá desarrollar el proceso de admisión a lo largo del tiempo. Podemos repasar esta idea una vez que el proceso de envío haya madurado. |
| Moderación del repositorio | Actuar como moderación en el repositorio de FPS Submission por parte de la comunidad para evitar abusos. Las personas que actúan de mala fe pueden abrumar con facilidad el proceso en el que se emplean orígenes de grabación para proponer conjuntos, y una cantidad abrumadora de solicitudes podría afectar las operaciones de propuestas de conjuntos genuinas. | Tratamos de que las verificaciones sean lo más objetivas posible con base en verificaciones de validación técnica. Creemos que este es el enfoque más escalable para el proceso de envío. Para cumplir con este objetivo, también intentaremos asegurarnos de que el proceso sea resistente a los envíos de spam y quemadores. |
| Subconjuntos asociados | ¿Los FPS podrán admitir casos de uso de flujos de proveedores/SaaS de terceros a través de subconjuntos asociados? | Los flujos de proveedores externos / SaaS no son un caso de uso que, por el momento, se considera dentro del alcance de los conjuntos propios. Recibiremos 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 + CHIPS para admitir casos de uso como pruebas A/B | Estamos analizando este caso de uso y también estamos considerando hacerlo en más detalle en una llamada de WICG. Agradecemos que nos envíes información adicional aquí. |
| GDPR | Propuesta de un nuevo subconjunto de FPS que se basará en los conceptos del GDPR | Analizamos esta propuesta internamente y la comparamos con otros comentarios recibidos y con nuestros objetivos de privacidad. Proporcionamos una respuesta en la que se explica por qué no continuaremos con esta propuesta en este momento. |
| Memoria | Cambio esperado en el tamaño de la memoria del navegador cuando se incorpora la lista de FPS | Hubo precedentes de que los navegadores almacenaran este tipo de listas con un impacto mínimo en la memoria, como la lista de protección del seguimiento de desconexión. Si bien la lista de conjuntos propios se copiará en cada cliente de Chrome de forma local, seguiremos supervisando el tamaño del archivo y confiamos en que podemos optimizar el espacio en memoria. |
API de Fenced Frames
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Limitaciones de los marcos protegidos | Claridad en torno a las limitaciones impuestas por los marcos cercados | En marzo, actualizamos nuestra explicación sobre marcos cercados, que proporciona información sobre sus capacidades, y se aceptan comentarios adicionales. |
| Expandir la información de acceso | Solicitud para expandir el acceso a la información sobre marcos cercanos | Queremos comprender mejor por qué esto es un requisito del ecosistema y agradecemos cualquier comentario adicional. |
| Iframes y marcos protegidos | Preguntas sobre la paridad de funciones entre los marcos protegidos y los iframes | Todas las APIs y los informes de Privacy Sandbox disponibles estarán disponibles para los iframes y los FencedFrames de la misma manera. |
| Redimensionamiento de marcos cercados | La restricción de los cambios en el tamaño de los fotogramas afecta ciertos casos de uso. | Nos interesa obtener más información sobre los tipos de casos de uso que se ven afectados por la restricción y recibiremos comentarios adicionales. |
API de Shared Storage
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Worklets de terceros | ¿Pueden los terceros escribir en almacenamiento compartido, particionado por origen? ¿O llamar a otros worklets para la medición de terceros? | El origen del contexto de navegación donde se ejecuta el código determina en qué 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 permite que el código de terceros escriba en su propio origen. El código de terceros también se puede incorporar como una secuencia de comandos en lugar de un iframe, lo que no cambia el contexto de navegación, y el tercero puede escribir en el almacenamiento compartido de la incorporación. Ten en cuenta que solo el propietario de ese almacenamiento compartido puede leer desde ese almacenamiento compartido. |
| Anulación de duplicación | La anulación de duplicación no sería posible para interacciones fuera del ecosistema de Chrome. | El almacenamiento compartido está diseñado para proporcionar resultados de alcance único 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 mayor alcance. Entendemos que los resultados en sí pueden solo representar una parte de las interacciones y nos interesa trabajar con tecnologías publicitarias para explorar metodologías de modelado adicionales que podrían superponerse. |
| Ventana de visualización de conversiones | Solicitar una ventana de visualización para el porcentaje de conversiones a fin de ver los cambios en la conversión 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, que ofrece flexibilidad adicional para estadísticas avanzadas sobre 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. Agradecemos los comentarios adicionales para comprender si la nueva política funcionará para el ecosistema. |
| Rotación de creatividades | Los casos de uso de rotación de creatividades no reflejan acciones reales posteriores a la subasta. | Nos interesa conocer a más empresas de tecnología publicitaria orientadas a la compra sobre si la documentación sobre rotación de creatividades es precisa o no. |
CHIP
No se recibieron comentarios este trimestre.
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Extremo de aserción de identidad | Permite de forma explícita las solicitudes arbitrarias al extremo de aserción de identidad. | Colaboramos con Mozilla en esta solicitud de extracción para limitar la capacidad de los sitios web de realizar solicitudes con credenciales de origen cruzado de forma silenciosa sin causar molestias a los usuarios. Seguiremos revisando y abordando otros comentarios también. |
| Prepropagar 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 podría provocar la filtración de información cuando un sitio que no interactuó con el usuario puede consultar el último IdP que usó. Estamos Analizando este problema en más detalle y agradecemos tus comentarios. |
| Selección contextual de la cuenta | Propuesta para agregar indicadores contextuales en la IU de selección de cuentas | Estamos considerando esta propuesta y aceptamos debates adicionales. |
Combate el spam y el fraude
API de Private State Token (y otras)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Encuesta sobre la recopilación de capacidades | A principios del primer trimestre, terminamos de recopilar los resultados de nuestra encuesta sobre las funciones necesarias para varios casos de uso antifraude y los compartimos de forma pública (minutos, resultados). | Planeamos incorporar estos comentarios a medida que desarrollamos nuevas propuestas y prototipos para APIs específicas que preservan la privacidad y antifraude. Esperamos priorizar el desarrollo cuando haya una necesidad suficiente y haya tecnología existente en la que podamos basarnos para introducir la capacidad en la Web, a la vez que se preserva la privacidad del usuario. Por ejemplo, la integridad del dispositivo y del inicio tiene una clasificación alta, y muchas plataformas tienen APIs existentes que comparten de forma segura una evaluación de integridad del dispositivo, por lo que es un buen candidato para seguir la exploración dentro de los grupos de la comunidad. |
| Comentarios sobre la intención de envío de PST | Como parte del intent de envío, recibimos tu inquietud para continuar, ya que estamos usando una versión anterior de Privacy Pass. También recibimos comentarios de que la especificación no era clara en ciertas secciones y que debíamos mejorar para facilitar la compatibilidad con el navegador. | Planeamos implementar muchos de los cambios de especificaciones sugeridos antes del envío a DG, 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). Estamos abiertos a considerar los cambios más importantes en la API, pero creemos que la mejor manera de proceder es continuar con el lanzamiento hasta la disponibilidad general y obtener comentarios prácticos de más desarrolladores. Esperamos continuar con este análisis y buscar la estandarización de los navegadores. Si surge un estándar nuevo, consideraremos adoptar y desarrollar un plan para realizar una transición cuidadosa a él. |