Se usó la API de Cloud Translation para traducir esta página.

Informe de comentarios - 3er trim. de 2023
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Informe trimestral del tercer 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. Como reflejo del enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Protected Audience 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
Preparación del ecosistema	Las SSP destacaron su preocupación por el hecho de que los publicadores no están listos y no realizan el trabajo de implementación necesario.	Privacy Sandbox tiene una divulgación enfocada específicamente en educar a los publicadores, lo que incluye seminarios en línea y reuniones exclusivos con publicadores y SSP presentes para impulsar el trabajo de implementación.
Baja de las cookies de terceros	Las preocupaciones sobre la baja de las cookies de terceros (3PCD) aumentan en el cuarto trimestre de 2023 debido a un apagón tecnológico de la industria.	Se analizó el cronograma de Privacy Sandbox con la CMA, y la secuenciación lleva a que esté listo para la segunda mitad de 2024. Privacy Sandbox publicará información más detallada sobre la secuenciación para implementar 3PCD. Según los Compromisos, el 3PCD está sujeto a que se aborden las inquietudes sobre la competencia de la CMA.
Google Ad Manager	Google Ad Manager se niega a exponer la plataforma de la API, lo que dificulta las pruebas.	Respuesta proporcionada por Google Ad Manager: Por los motivos que se explican en esta respuesta de Google Ad Manager, los planes de Google Ad Manager para su integración con la API de Protected Audience no incluyen la compatibilidad con el servidor de anuncios del publicador de Google sin control de la subasta de nivel superior.
Google Ad Manager	Google Ad Manager tiene un precio mínimo secreto que solo se expone a ADX o a las SSP de Open Bidding.	En la documentación pública de Google Ad Manager, se indica que el ganador de la subasta contextual se pasa a la lógica de puntuación de nivel superior y no a ninguna subasta de componentes, incluidas AdX o las ofertas abiertas. Además, en esa documentación, se indica lo siguiente sobre la lógica de puntuación de nivel superior: "Ad Manager comparará la oferta ganadora de cada subasta de componentes, incluida la propia subasta de componentes de Ad Manager para las ofertas de grupos de intereses de sus compradores, así como el mejor anuncio contextual (que se selecciona a través de la asignación dinámica), y publicará el anuncio con la oferta más alta".
Google Ad Manager	Los productos de Google Ads deben estar sujetos a las mismas reglas que los productos de anuncios de terceros.	Los productos de Google Ads ya están sujetos a las mismas reglas que los terceros.
Pruebas facilitadas por Chrome	Agrega etiquetas para los navegadores que no están en A o B.	Por el momento, no estamos considerando hacerlo, ya que nuestra investigación reveló que agregar etiquetas que no sean de experimentos podría complicar las inquietudes sobre la privacidad en relación con el tráfico en modo Incógnito.
Agencia de publicidad	¿Las agencias o empresas sin JavaScript en los sitios web pueden usar las APIs de Privacy Sandbox?	Cualquier persona puede llamar a las APIs de Privacy Sandbox. Si una agencia o cualquier otra persona quiere compilar tecnologías directamente en las APIs, puede hacerlo. Las APIs del cliente requieren integración con el cliente, al igual que las cookies. Muchas de las APIs, como las cookies, también tienen una interfaz de encabezado HTTP. Ya vimos un framework de la industria publicitaria, Prebid, compilar integraciones del cliente con las APIs. Otras organizaciones podrían hacer lo mismo.
Soluciones del cliente	¿Por qué Google adopta soluciones del cliente para Privacy Sandbox cuando un ingeniero ya expresó su preocupación por la escalabilidad de esas soluciones en 2012?	La tecnología para la mejora de la privacidad (PET) como campo de estudio evolucionó significativamente desde 2012 y, con ella, las aplicaciones comercialmente viables. En el centro de Privacy Sandbox, se encuentran combinaciones de PET que no habrían sido posibles hace más de una década. Además, la potencia de procesamiento personal aumentó, al igual que las expectativas de los consumidores sobre los navegadores y las expectativas regulatorias de privacidad.
Aprendizaje automático	¿Cuál es el uso planificado de Privacy Sandbox por parte de Google para el aprendizaje automático?	Gran parte del ecosistema de tecnología publicitaria usa el aprendizaje automático en la actualidad, y no esperamos que eso cambie. Privacy Sandbox no impide que las empresas de tecnología publicitaria ni nadie más siga usando el aprendizaje automático. Tampoco requiere que las empresas que integran sus APIs usen el aprendizaje automático. Es razonable esperar que las empresas sigan creando productos y servicios de manera que satisfagan las necesidades de sus clientes, ya sea que incluyan el aprendizaje automático o no. Por supuesto, los integradores de Privacy Sandbox conocerán cualquier modelo de aprendizaje automático que compilen y, por lo tanto, no se ocultará.
Verificación de datos	¿Cómo pueden las empresas verificar que los datos que reciben del uso de Privacy Sandbox sean precisos y que Google esté dispuesto a que se los revise a través de una entidad como el Media Ratings Council (MRC)?	Las APIs de Privacy Sandbox se compilan en la plataforma de código abierto que alimenta a Chrome. Las partes de las APIs diseñadas para ejecutarse en entornos de ejecución confiables también son de código abierto y auditables. Cualquier persona que quiera inspeccionar el código puede hacerlo, incluido el MRC.
Asistencia de producción (también se informó en trimestres anteriores)	¿Cuál es el proceso establecido para que Chrome admita los problemas técnicos y las derivaciones de Privacy Sandbox que afectan al ecosistema?	Google ofrece una variedad de canales para permitir que las tecnologías publicitarias informen problemas técnicos y habiliten las derivaciones necesarias para resolverlos. Además, Chrome espera compilar y escalar aún más un proceso para resolver problemas técnicos y derivaciones que afectan el estado del ecosistema. Chrome se compromete a garantizar los recursos para esta iniciativa. Consulta nuestros foros públicos y privados para obtener comentarios y derivar el caso.
Modos de prueba que facilitó Chrome	Más información sobre los cronogramas y las implementaciones exactas de los modos de prueba facilitados por Chrome.	Compartimos una entrada de blog sobre los modos de prueba y estamos trabajando para compartir más información pronto. Aceptamos sugerencias sobre el tamaño que deben tener las etiquetas del modo de prueba.
Integración con otros estándares de la industria	¿Las APIs de Privacy Sandbox se conectarán al MTC v2.* o al modo de consentimiento, o a ambos?	No tenemos planes para integrar las APIs de Privacy Sandbox directamente con el MTC v2 ni el modo de consentimiento. Sin embargo, las empresas y los grupos comerciales de la industria pueden adaptar sus productos y frameworks para que funcionen en conjunto con las APIs de Privacy Sandbox. Por ejemplo, con marcos de trabajo como el MTC, cada participante debe determinar su propio enfoque de cumplimiento en función del indicador del MTC que recibe y las políticas asociadas del MTC. Esperamos que las empresas determinen cuándo y cómo usar las diversas funciones que ofrecen nuestros componentes básicos de Privacy Sandbox.

Inscripción y certificación

Tema de los comentarios	Resumen	Respuesta de Chrome
Restricción	El proceso de inscripción significa que Google puede decidir qué empresa del ecosistema puede usar las APIs de Privacy Sandbox.	El proceso de inscripción y certificación implica, en esencia, la verificación de la entidad (por ejemplo, si tiene un número DUNS, si puede proporcionar un vínculo a una política de privacidad, etcétera) y hace que la certificación pública sea un requisito para llamar a las APIs. Se validarán las entidades que puedan cumplir correctamente con los requisitos de inscripción. En el caso de las empresas que no tienen un DUNS, proporcionamos un proceso acelerado y complementario con Dun & Bradstreet para adquirir uno. El objetivo es mejorar las protecciones de privacidad de las APIs (mediante las medidas que acabamos de mencionar) y también agregar una capa de transparencia a las APIs de Privacy Sandbox, de modo que las partes interesadas puedan comprender mejor quién usa qué API y qué certificaciones realizan. Estamos abiertos a más comentarios de la industria sobre este problema, que ya se usaron para definir el proceso.
Sobrecarga de reinscripción	El archivo de certificación vence cada 12 meses y requiere que los sitios web se vuelvan a inscribir.	Escuchamos los comentarios del ecosistema y modificamos nuestro enfoque según corresponda. Esto significa que los archivos ya no vencerán después de 12 meses ni de ningún período establecido. Actualizaremos nuestra guía para desarrolladores de inscripción con contexto adicional.
Archivo de certificación	¿Cómo se usa el archivo de certificación?	Antes de la fecha límite de aplicación, todas las empresas que realicen llamadas a las APIs de relevancia y medición deberán subir el archivo de certificación a su sitio y mantenerlo para que sea visible para el público, siempre y cuando tengan la intención de seguir realizando llamadas a las APIs. Los sitios web podrían recibir aproximadamente una solicitud por hora de Privacy Sandbox, y es posible que otras entidades potenciales también realicen consultas. Esto se realizará a través del propio mecanismo del sistema de inscripción para consultar los servidores de las entidades inscritas y garantizar que el archivo de certificación sea válido. Las certificaciones se incluirán en los Informes de transparencia y el público en general podrá verlas. Esperamos que las empresas actúen de acuerdo con sus certificaciones declaradas, al igual que el resto del ecosistema y los organismos reguladores relevantes.
Inscripción	¿La inscripción es por sitio o por origen?	La inscripción se realiza a nivel del sitio.

Muestra anuncios y contenido relevantes

Temas

Tema de los comentarios	Resumen	Respuesta de Chrome
Rendimiento	Preocupaciones sobre el rendimiento en relación con el impacto de la tasa de participación en Temas en el Espacio Económico Europeo	Sugerimos a las partes interesadas que se comuniquen con la autoridad de protección de datos correspondiente para informar sobre este problema. Son los más adecuados para abordar esas inquietudes y decidir si las aplicaciones de tecnologías que mejoran la privacidad están incentivadas por las leyes o, en cambio, se tratan como seguimiento, lo que requiere los mismos enfoques de consentimiento. Esto podría provocar que las APIs como las de Privacy Sandbox no estén disponibles con tanta frecuencia.
Inscripción	¿Los ofertantes descendentes deben inscribirse en la API de Topics para usar los indicadores de Topics de las SSP de upstream?	No es necesario inscribir a los receptores descendentes de temas más allá del llamador inicial de la API de Topics, aunque es probable que muchos estén inscritos para otros usos de la API. Se proporcionará una lista de usuarios inscritos en Privacy Sandbox de forma programática como parte de los esfuerzos de transparencia del programa, lo que permitiría que un emisor interesado de la API de Topics verifique si el destinatario al que le envía un tema está inscrito, si así lo desea.
Filtrado de temas	Solicita aplicar el filtrado de otro llamador a los temas que recupera en la página para compartir solo lo que los compradores pueden recuperar.	Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Exclusión de sitios	Excluye los sitios web para que no contribuyan a los temas de un usuario.	No se llama a los temas de forma predeterminada. Es importante tener en cuenta que no se tiene en cuenta el contenido de las páginas cuando se seleccionan los temas, y todos los temas se seleccionan para garantizar que no sean sensibles. Un sitio web también puede restringir que su sitio se incluya en el cálculo de temas a través del siguiente encabezado de la política de permisos: `Permissions-Policy: browsing-topics=()`
Observación de temas	Permite que los publicadores otorguen permisos para que Chrome clasifique los temas según el contenido de la página (por ejemplo, encabezado o cuerpo).	Anteriormente, consideramos ofrecer una funcionalidad para clasificar los sitios en temas según el contenido de la página y tomamos la decisión de no avanzar debido a preocupaciones de privacidad y seguridad. Esta propuesta puede mitigar algunas de esas preocupaciones, pero no está claro en qué medida. Debido al próximo período del experimento de CMA, no esperamos que este cambio se produzca antes del 3PCD. Envíanos tus comentarios adicionales aquí.
Observación de temas	Proporcionar políticas de permisos más detalladas para los publicadores	Proporcionar políticas de permisos más detalladas para los publicadores permitiría que los sitios de los publicadores afecten negativamente la utilidad de la API de Topics para el ecosistema en su totalidad, sin que afecte negativamente la utilidad de la API de Topics para el sitio en sí. Consulta el problema de GitHub Update permissions policy to support separate permissions for retrieve and observe para obtener una explicación más detallada del tema.
Temas médicos y de salud	¿Por qué la taxonomía de temas no abarca temas de las categorías de Medicina o Salud?	Las categorías de salud y medicina se consideran temas sensibles y, por lo tanto, se excluyen de la taxonomía de Topics.
Recuperación de temas	Es una forma más rápida para que las DSP obtengan temas sin recuperarlos con encabezados.	Los métodos de encabezado tienen un mejor rendimiento y son menos costosos que crear un iframe de origen cruzado y realizar una llamada a `document.browsingTopics()` desde él. (Se debe usar un iframe de origen cruzado para la llamada, ya que el contexto de nivel superior para observar un tema debe coincidir con el contexto desde el que se accede a los temas). Esto se analizó en detalle aquí.
Recuperación de temas	Solicitudes para admitir el paso de Topics a través de encabezados en solicitudes de etiquetas de secuencia de comandos de origen cruzado	Desde una perspectiva de seguridad, esto no es posible. Cada documento y su entorno de ejecución están asociados con un solo origen, el del documento. Los subrecursos de terceros que se cargan y ejecutan en ese mismo entorno se consideran propiedad del origen del documento. Esto se hace para evitar la filtración de datos sin consentimiento de un origen a otro. Una alternativa es proporcionar un atributo `browsingTopics` en las etiquetas `<script>`. Esto debe ser claro desde una perspectiva de seguridad y no agregar latencia adicional. Estamos abiertos a los comentarios de las partes interesadas.
Reconocimiento	Mejorar el conocimiento público de la API de Topics y cómo se usará la API	Nos comunicamos con la parte interesada que proporcionó estos comentarios y este problema se resolvió en GitHub. De ahora en adelante, seguiremos apoyando la comprensión del ecosistema de la API y esperamos escuchar las opiniones de las partes interesadas. Mientras tanto, sugerimos a las partes interesadas que quieran obtener más información sobre la API de Topics que se familiaricen con la documentación de la guía para desarrolladores de Chrome.
Notificación	Notificación para alertar al usuario cuando un sitio web observa sus temas.	Abordamos estos comentarios en GitHub. Los usuarios pueden obtener más información sobre los controles de Temas en el Centro de ayuda de Chrome.
Aprendizaje automático	¿Cómo se puede usar el AA para inferir los temas de los usuarios?	Estamos analizando este problema y agradecemos tus comentarios adicionales.
Utilidad para diferentes tipos de partes interesadas	Es posible que las empresas de tecnología publicitaria más pequeñas no puedan observar los temas debido a la forma en que los navegadores los calculan.	Solo las tecnologías publicitarias que observaron que el usuario visitó una página sobre el tema en cuestión en las últimas tres semanas recibirán un tema. Si la tecnología publicitaria no llamó a la API en las tres semanas anteriores para ese usuario en un sitio sobre ese tema, el valor que se muestra estará vacío. Esta función significa que las tecnologías publicitarias cuyos servicios usan una mayor cantidad de propietarios de sitios y, por lo tanto, tienen más oportunidades de observar la visita de un usuario determinado a un sitio, pueden recibir más temas que otras tecnologías publicitarias. Esta función es esencial para las protecciones de privacidad de la API, ya que limita la disponibilidad de la información sobre un usuario solo a aquellas partes que ya pueden observar la misma información subyacente (actualmente, a través de cookies de terceros).
Solicitud de XHR	¿Cuándo dejará de estar disponible la inclusión de Topics en las solicitudes `XMLHttpRequest` (XHR)?	Como anuncio Chrome en agosto de 2023, Chrome comenzó a dar de baja la compatibilidad con XHR cuando se realizó la transición de la prueba de origen a la disponibilidad general. A medida que avanzaba la implementación de Topics, la compatibilidad con XHR solo se incluía para los usuarios en los que estaban habilitadas las funciones de OT y dejó de estar disponible por completo cuando se fusionaron los grupos experimentales de OT individuales. Si usabas Topics con XHR, tus sitios no se dañarán. Los temas no se agregarán a los encabezados de tu solicitud XHR. Te recomendamos que realices la transición a `fetch` para tu solicitud, uses el atributo iframe o la API de JavaScript para recuperar temas. Todos los navegadores modernos admiten la recuperación, pero no Internet Explorer ni Opera Mini.
Proceso de actualización de la taxonomía y el clasificador	Más información sobre la taxonomía de Topics y la cadencia de lanzamientos del clasificador, y cómo las empresas pueden prepararse para esas actualizaciones.	Nuestra respuesta no cambia desde el segundo trimestre: Como se compartió en la entrada de blog reciente, esperamos que la taxonomía evolucione con el tiempo y que la gobernanza de la taxonomía eventualmente se transfiera a una parte externa que represente a las partes interesadas de toda la industria. También compartimos el plan de implementación en el grupo topics-announce.
Abuso	Ataque potencial a través de una cadena de redireccionamientos	Estamos analizando este problema y agradecemos tus comentarios adicionales.
Tipos de inventario del publicador	¿Qué tipos de inventario de publicadores admitirán las pruebas de Protected Audience y Topics?	Ni Protected Audience ni Topics son inherentemente restrictivos en cuanto a los tipos de inventario en los que se pueden utilizar.
Tiempo de aumento	Se recomienda que no haya tiempo de preparación para que las taxonomías nuevas lleguen al 100%.	Después de esta solicitud de comentarios del ecosistema y el debate durante las reuniones del PATCG, anunciamos nuestro plan para el lanzamiento de la nueva taxonomía.

API de Protected Audience (antes conocida como FLEDGE)

Tema de los comentarios	Resumen	Respuesta de Chrome
Subastas de nivel superior	Posibilidad de usar el servidor de anuncios del publicador de Google sin darle a Google Ad Manager el control de la subasta de la API de Protected Audience de nivel superior	Respuesta proporcionada por Google Ad Manager: Los planes de Google Ad Manager para la API de Protected Audience no incluyen la compatibilidad con el servidor de anuncios del publicador de Google sin el control de la subasta de Protected Audience de nivel superior por los siguientes motivos. Para publicar anuncios de forma adecuada a nuestros clientes en el mercado de publicación de anuncios de publicadores, el servidor de anuncios de publicadores de Google debe conservar el control de la subasta de Protected Audience de nivel superior. Como servidor de anuncios para publicadores, nuestro rol es proporcionarles previsiones para que puedan negociar campañas vendidas directamente sin sobrereservas, y para que puedan distribuir y publicar sus reservas directas de manera óptima. Para ello, se debe ejecutar la subasta final para comparar toda la demanda directa e indirecta apta. La previsión y el control de velocidad son funciones principales que los publicadores esperan de un servidor de anuncios. Sin una previsión precisa, los publicadores pueden terminar vendiendo más de su inventario, lo que pone en riesgo su reputación comercial. El ritmo también es fundamental, ya que no poder cumplir con los contratos de reserva con los anunciantes también puede dañar la relación directa entre el publicador y el anunciante, lo que podría tener un impacto significativo en el negocio de un publicador. En resumen, no consideramos que la actividad de un servidor de anuncios del publicador de ejecutar la subasta de Protected Audience de nivel superior sea distinta de las otras actividades del servidor de anuncios del publicador.
`directFrom SellerSignals`	`directFrom SellerSignals` permite que Google Ad Manager evite que el publicador vea el precio de su subasta contextual.	Respuesta de Chrome: No se sabe si la información que se pasa a `runAdAuction()` proviene del vendedor, a menos que el vendedor llame a `runAdAuction()` desde su propio iframe. En una subasta de varios vendedores, es imposible que todos los vendedores creen la llamada de marco `runAdAuction()`. `directFromSellerSignals` resolvió este problema cargando contenido de un paquete de subrecursos cargado desde el origen de un vendedor. Esto garantiza que no se pueda manipular la autenticidad y la integridad de la información que se pasa a una subasta desde la configuración de subastas del vendedor. Si los publicadores desean usar la API de Protected Audience para comprender la información que sus proveedores de tecnología pasan a las subastas de Protected Audience, pueden solicitarles esta funcionalidad. Respuesta proporcionada por Google Ad Manager: Durante años, nos hemos enfocado en la equidad de las subastas, incluido nuestro compromiso de que ningún precio de ninguna de las fuentes publicitarias no garantizadas de un publicador, incluidos los precios de las líneas de pedido no garantizadas, se compartirá con otro comprador antes de que realice una oferta en la subasta, lo que luego reafirmamos en nuestros compromisos con la Autoridad de Competencia de Francia. En el caso de las subastas de Protected Audience, pretendemos cumplir nuestra promesa aprovechando `directFromSellerSignals` y no compartiendo la oferta de ningún participante de la subasta con ningún otro participante antes de que se complete la subasta en subastas de varios vendedores. Para que quede claro, tampoco compartiremos el precio de la subasta contextual con nuestra propia subasta de componentes, como se explica en la actualización Mayor claridad sobre las dinámicas de subasta de nivel superior.
Exposición de la información	El navegador puede exponer la lógica empresarial y los detalles contractuales sensibles.	La persona que usa un navegador web puede ver todo lo que sucede en el navegador. Cuando se produce una subasta de anuncios dentro del navegador, es cierto que la persona cuyo navegador es podría ver que se lleva a cabo esa subasta, lo que incluye ver cuánto eligen ofertar las diferentes partes. Dado que un navegador es el agente del usuario, no creemos que sea posible ni deseable intentar cambiar esto. Sin embargo, solo la persona que usa el navegador tiene visibilidad de estas operaciones. Ningun servidor, incluido el de Google, puede observar una subasta integrada en el dispositivo que se ejecuta con la API de Protected Audience.
`PerBuyerExperiment GroupId`	El rango de valores actual de `PerBuyerExperiment GroupId` podría permitir que los compradores correlacionen los datos contextuales con la solicitud del servidor de confianza.	El uso de la API de Protected Audience de esta manera no es coherente con la certificación obligatoria de Privacy Sandbox que indica que los usuarios de la API no intentarán eludir las protecciones de Privacy Sandbox. En el futuro, el requisito de que los servidores de par clave-valor se ejecuten en entornos de ejecución confiables (TEE) proporcionará protección técnica contra este ataque.
Política de mismo origen	Disminuye la rigurosidad de la política del mismo origen para permitir subdominios.	Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Control de versiones de la API	Solicitud de control de versiones y notas de la versión para cambios en la API de Protected Audience	Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Subastas de varias SSP	Permite que los indicadores de subasta de nivel superior realicen combinaciones JSON con el indicador de componente `auctionSignals`.	Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Límite de oferta	Aumentar el límite de la cantidad de componentes del anuncio que ingresan a la oferta de 20 a 40	Estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema sobre por qué sería útil.
(También se informa en trimestres anteriores) Rendimiento de las subastas de Protected Audience	Informe de los verificadores que indica que las subastas de Protected Audience tienen una latencia alta.	En el caso de las preguntas sobre latencia, la API de Protected Audience, por lo general, siguió el paradigma estándar existente de crear controles que permiten a los vendedores decidir cuánto tiempo y recursos pueden consumir los ofertantes, y crear herramientas que permiten a los compradores decidir cómo usar mejor los recursos disponibles. Por lo general, estos controles y herramientas están disponibles en la actualidad, pero sus beneficios completos solo se verán después de que los compradores y vendedores los adopten. Además, Chrome sigue trabajando en una variedad de mejoras de infraestructura para aumentar la velocidad de las subastas (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Te invitamos a que nos envíes comentarios sobre ambas mitades de este esfuerzo por reducir la latencia: herramientas nuevas que los compradores y vendedores podrían considerar útiles, y los informes de los cuellos de botella observados que los ingenieros de Chrome deberían investigar.
Filtrado orientado a la compra	Se agregó compatibilidad con el filtrado orientado a la compra según los grupos de intereses.	Sugerimos varias formas en que las SSP y las DSP podrían cambiar sus diseños para controlar esto: Se trasladó parte del trabajo al servidor de pares clave-valor de la DSP. Las SSP crean algunos indicadores contextuales y se los proporcionan a las DSP. SSPs que almacenan en caché indicadores contextuales para DSPs
Control de grupos de interés de los publicadores	Asistencia para los publicadores que buscan delegar el uso de los grupos de intereses creados por el editor	Hemos mantenido conversaciones con muchas partes sobre la solicitud. Creemos que todos los casos de uso que involucran la "delegación" de los grupos de interés creados por el publicador se pueden implementar ahora y, además, que debemos crear asistencia adicional para que algunos casos de uso fluyan más sin problemas en el futuro.
Entornos de ejecución confiables (también informados en el segundo trimestre)	Compatibilidad con entornos de ejecución confiables (TEE) en entornos de nube que no son públicos	Nuestra respuesta es similar a la de trimestres anteriores: Si bien seguimos explorando la compatibilidad con opciones más allá de las soluciones públicasbasadas en la nube, no tenemos planes actuales para admitir TEEs on-premise. En esta etapa, dados los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones en las instalaciones, creemos que seguir expandiendo y mejorando las implementaciones basadas en la nube (por ejemplo, admitir Google Cloud además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, recibimos con gusto comentarios adicionales sobre por qué este requisito es necesario y factible, dadas las limitaciones de privacidad y seguridad.
Un entorno de ejecución confiable	Los componentes de la ruta de entrega de TEE, como el balanceador de cargas, pueden observar todo el tráfico y tener información de la dirección IP de cada solicitud.	Actualmente, la dirección IP se pasa como un metadato en los encabezados de solicitud al servicio de anuncios del vendedor no confiable en el caso de las ofertas y subastas, y las subastas de Protected Audience integradas en el dispositivo. Consulta Reenvío de metadatos para obtener más información. A largo plazo, planeamos usar un proxy para la tecnología publicitaria y el tráfico de los servicios de seguimiento a través de un proxy de IP, lo que evitará que los componentes observen todo el tráfico en la ruta de publicación.
Tiempo de actividad (TTL)	¿Se establecerá el tiempo de actividad (TTL) antes de que los servicios deban solicitar claves nuevas o se pretende que sea flexible (o dinámico)?	Por lo general, el TTL es estático. Actualmente, el TTL para el público es de 8 días, y la rotación se produce cada 7 días. El TTL también es el mismo para las claves privadas en el caso del servicio de agregación. En el caso de los servicios de ofertas y subastas, las claves privadas y públicas se recuperan cada N horas en la ruta de acceso sin solicitud y se almacenan en caché en la memoria, de modo que no haya más de una demora de N horas entre la rotación de las claves y los servidores que las recuperan. El búfer de 1 día entre la rotación de claves y el vencimiento es para garantizar que, incluso si falla la generación de claves, los servicios puedan seguir funcionando. Estamos considerando extender el TTL para que sea más resistente a las interrupciones. En caso de una filtración de claves, planeamos forzar la generación de claves de forma manual y invalidarlas antes. Ten en cuenta que las claves públicas se almacenan en caché en los clientes, actualmente durante 24 horas, para garantizar que, en caso de interrupción del coordinador, los servicios aún puedan funcionar.
Determinación por tráfico	Compatibilidad con la conformación de tráfico para los servicios de ofertas y subastas	Los compradores pueden indicar, en función de los datos de origen del publicador o de los datos contextuales, la demanda de subastas de Protected Audience. Los vendedores también pueden realizar determinaciones similares en el servidor de anuncios del vendedor o en el servidor de Ad Exchange. Los modelos se pueden entrenar con datos propios y cualquier informe agregado de las subastas de Protected Audience. Los vendedores pueden usar esta información para evitar enviar solicitudes a los servidores de ofertas y subastas cuando no hay demanda para las subastas de Protected Audience. Creemos que esta puede ser una forma eficaz de moldear el tráfico.
Subasta de componentes	¿Qué auctionSignals de nivel superior se comparten con los vendedores de componentes?	Los compradores en una subasta de componentes solo reciben indicadores del vendedor del componente. Pronto compartiremos documentación sobre la secuencia general de una subasta combinada con la licitación de encabezados y la subasta de Protected Audience.
Renderización de video	Compatibilidad con la renderización de videos con Protected Audience y marcos delimitados	La API de Protected Audience admite la renderización de videos con un mecanismo que se basa en iframes. Sin embargo, aún no diseñamos una solución que sea compatible con los marcos delimitados, y este es uno de los motivos por los que decidimos posponer la aplicación forzosa de los marcos delimitados hasta 2026. Eso significa que, si un socio decide aplicar los marcos delimitados ahora, no tendrá compatibilidad con los videos.
Limitación de frecuencia	(También se informa en trimestres anteriores) Controles de frecuencia por usuario dentro de una campaña y un grupo de anuncios.	Nuestra respuesta no ha cambiado desde los informes anteriores: Protected Audience también admitirá el límite de frecuencia para las subastas integradas en el dispositivo y las campañas contextuales y de desarrollo de la marca. El almacenamiento compartido y los límites específicos del sitio también se pueden usar para controles adicionales de limitación de frecuencia.
Preferencias de anuncios	¿Protected Audience proporciona una forma de inhabilitar o bloquear sitios de anunciantes o una forma de abandonar todos los grupos de intereses del mismo propietario?	Los usuarios pueden bloquear el acceso a la API de Protected Audience y a otras funciones de Privacy Sandbox de varias maneras.
Política del mismo origen para la URL de origen de las secuencias de comandos de ofertas y subastas	Se relajó el requisito de que todos los campos que especifiquen URLs para cargar secuencias de comandos o JSON deben tener el mismo origen que el propietario.	Actualmente, estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema.
`forDebuggingOnly`	Posibilidad de que se haga un uso inadecuado de `forDebuggingOnly .reportAdAuctionWin` si permanece después de 3PCD	En los últimos años, recibimos comentarios del ecosistema sobre las brechas funcionales de Protected Audience una vez que las cookies de terceros dejen de estar disponibles. Estamos trabajando para formular un plan que las admita después de la 3PCD sin comprometer los objetivos de Privacy Sandbox. Aceptamos sugerencias y comentarios adicionales sobre las funciones que faltan y que el ecosistema desea ver.
Varios grupos de interés	Usa varios grupos de intereses en la misma oferta.	Actualmente, esto no es compatible con la API de Protected Audience, ya que generaría un cambio en el modelo de privacidad subyacente. Te invitamos a que participes en el debate aquí.
Subastas en el dispositivo	¿Chrome para Android admitirá subastas de Protected Audience integradas en el dispositivo?	Sí, las subastas integradas en el dispositivo se admitirán en Chrome para Android.
Datos relacionados con los clics (informes del 2º trim. de 2023)	Agrega datos relacionados con los clics a browserSignals.	Seguimos evaluando esta solicitud de función y recibimos con gusto comentarios adicionales sobre por qué se debe priorizar.
Proveedores de entornos de ejecución confiables	¿Hay diferencias sustanciales en las ofertas de entornos de ejecución confiables de los diferentes proveedores de servicios en la nube?	No conocemos ninguna diferencia importante, pero recomendamos que el ecosistema revise las guías de implementación públicas para ver qué solución se adapta mejor a sus necesidades. Google Cloud. AWS.
(Informes de trimestres anteriores) Compatibilidad con la segmentación negativa por grupos de interés	Una API para admitir la segmentación negativa por grupo de intereses: muestra anuncios solo si un usuario no pertenece a un grupo de intereses.	Estamos analizando la implementación de esta función y analizando la solicitud.
Infracción de contenido	Admite funciones que permiten a los usuarios denunciar anuncios no aptos publicados por la API de Protected Audience en marcos delimitados.	Creemos que el mecanismo de informes de anuncios con marcos delimitados existente ofrece buenas opciones para las tecnologías publicitarias que desean un flujo de informes de "Anuncios no aptos" generado por el usuario. Esto permitiría informar sobre anuncios que infringen las políticas de una manera que no cambiaría en esencia con respecto al estándar actual de la industria. Aceptamos solicitudes de funciones adicionales si aún quedan brechas, incluso durante el período posterior a la eliminación de las cookies de terceros, pero antes de que la renderización de marcos delimitados se generalice.
Informes de la API de Private Aggregation	¿Cómo podemos calcular el tiempo que el usuario pasó en ese grupo de intereses?	En Chrome M116 y versiones posteriores, deberías poder usar la actualización según se define en pull/639.
Servidor de k-anonimato	Más información sobre el servidor de k-anonimato	Compartimos más información sobre los servidores de k-anonimato aquí y recibimos con gusto comentarios adicionales.
URLs de creatividades dinámicas	Compatibilidad con URLs de creatividades sin declaración previa y, al mismo tiempo, respeto del k-anonimato	Estamos analizando esta solicitud de función y recibimos con gusto comentarios adicionales sobre por qué se debe priorizar.
Requisito de k-anonimato	¿Se volverá a implementar el requisito de k-anonimato en las actualizaciones de los grupos de interés?	No prevemos cambios en la posición que se indica en esta publicación de GitHub. Como se anunció en esa publicación, decidimos quitar el requisito de anónimo k en las actualizaciones de los grupos de intereses de Protected Audience, lo que no tiene un impacto significativo en las protecciones generales de privacidad de la API. Planeamos considerar otras protecciones potenciales más directas (como la privacidad de la dirección IP o un servidor de actualización de confianza) más adelante, cuando las tecnologías relacionadas estén más desarrolladas, implementadas y adoptadas.
Pruebas beta de los servicios de ofertas y subastas	¿Cuándo comenzarán las pruebas beta de los servicios de ofertas y subastas?	Como se indica en el Cronograma y la hoja de ruta, la primera fase de pruebas de los servicios de ofertas y subastas comenzará en noviembre de 2023.
Publicación simultánea garantizada	Solicita la compatibilidad con la coordinación de creatividades para las redes de publicidad (la SSP y la DSP están en la misma empresa o propiedad).	Agradecemos los comentarios sobre este caso de uso y queremos comprender si a más tecnologías publicitarias les interesa que se admita esta función. Agradecemos los comentarios adicionales.
Publicidad nativa	Compatibilidad con el marco de límite para la publicidad nativa	Estamos considerando admitir el caso de uso y estamos analizando posibles solución y alternativas.
K-anonimato	¿Cómo puedo maximizar los anuncios de grupos de intereses que cumplen con los umbrales de k-anon?	Compartimos algunas orientaciones tácticas sobre este tema.
Compatibilidad con POST	Compatibilidad con el envío de datos de subasta a través de solicitudes POST.	Estamos evaluando esta solicitud de función y aceptamos envío de problemas adicionales a GitHub sobre por qué se debe priorizar.
Nivel de detalle de los informes	¿Cuál es el nivel de detalle de los informes de anuncios de marco limitado con anuncios compuestos por varias piezas?	El diseño actual no permite capturar el ID ni la posición del producto, ya que esto podría poner en riesgo la privacidad del usuario. Solo se puede invocar `reserved.top_navigation`, que se enviaría cuando haya una activación del usuario (como un clic) en el marco cercado del componente del anuncio, lo que genera una navegación de nivel superior.
Subasta de anuncios	¿Una SSP que participa en una subasta de componentes puede activar otra subasta de componentes?	Un `componentSeller` tampoco puede incluir `componentAuctions`. La subasta de varios vendedores solo tiene dos niveles: 1. El componente se subasta en paralelo. 2. La subasta de nivel superior (en la que compite el anuncio ganador de cada `componentAuction`).
Disponibilidad de los servicios de ofertas y subastas	¿Las ofertas y subastas estarán disponibles durante la fase de pruebas facilitadas por Chrome?	El servidor de ofertas y subastas no estará disponible durante la fase de pruebas facilitada por Chrome.
Indicadores de ofertas	Permite que los navegadores soliciten y borren indicadores de ofertas.	Estamos analizando esta solicitud y agradecemos los comentarios adicionales sobre por qué se debe priorizar.
`generateBid()`	Se puede actualizar el `userBiddingSignals` de interestGroup a través de `updateURL`.	Estamos considerando esta propuesta y agradecemos los comentarios adicionales y el debate.
Tipos de inventario del publicador	¿Qué tipos de inventario de publicadores serán compatibles con las pruebas de Protected Audience y TOPICS?	Ni Protected Audience ni Topics son inherentemente restrictivos en cuanto a los tipos de inventario en los que se pueden utilizar.
Integración de servidor a servidor	¿Se requiere la integración directa entre la SSP y la DSP para Protected Audience?	No se requiere la integración directa entre la SSP y la DSP si esta no necesita procesar indicadores contextuales en su propio servidor para pasar esa información procesada a su función de ofertas integradas en el dispositivo.
Un campo `bid_currency` en B&A	Compatibilidad con el campo `bid_currency` en el servicio de ofertas y subastas	B&A aún no admite `bid_currency`, aunque planeamos admitirlo a fines de enero de 2024. Consulta el cronograma aquí.
`perBuyerSignals`	¿Existe un límite de tamaño para `perBuyerSignals`?	No hay límite para la cantidad de indicadores por comprador, pero enviar demasiados datos puede tener efectos perjudiciales en el rendimiento del navegador.
Casos de uso entre sitios	¿Podemos usar los grupos de interés de la API de Protected Audience en varios sitios web?	Protected Audience no está diseñado para esos casos de uso, como se explica en turtledove/issues/282.
Solicitudes HTTP de grupos de intereses	Incluye el BLOB de grupo de interés en los encabezados HTTP.	Estamos considerando esta solicitud y agradecemos más comentarios al respecto.
Control de calidad de los anuncios	Pérdida del control de calidad de los anuncios relacionada con la información entre sitios	Estamos considerando estos comentarios y agradecemos los comentarios adicionales.
Herramientas para desarrolladores de Chrome	Las solicitudes de red salientes de Protected Audience deberían aparecer en la pestaña Red de las herramientas para desarrolladores de Chrome.	Estamos trabajando para habilitar esta función en la pestaña de red y agradecemos los comentarios adicionales sobre por qué se debe priorizar.
Un entorno de ejecución confiable	¿Cuándo se agregarán los detalles sobre qué métricas afectan la privacidad (y su grado) a la explicación sobre la supervisión del entorno de ejecución confiable?	Estamos actualizando la explicación con esta información. La explicación actualizada estará disponible en noviembre de 2023.
`directFrom SellerSignals`	¿Por qué `directFrom SellerSignals` no se empaqueta como un paquete web?	Compartimos el motivo de esta decisión aquí.
Delegación de impresiones	¿Existe alguna forma viable de realizar la delegación de impresiones en la que el resultado de la selección de un grupo de interés sea otra acción de segmentación?	Las subastas anidadas múltiples no son compatibles con nuestros objetivos de privacidad por dos motivos. En primer lugar, cuando el ganador de una subasta se renderiza dentro de un marco limitado, nuestros objetivos de privacidad para Protected Audience incluyen la renderización de la creatividad resultante sin conocimiento del contexto: la URL de la página circundante o la cookie propia son una infracción de la privacidad. En ese entorno, no es viable una subasta anidada. En segundo lugar, el modelo de Protected Audience establece que el ganador de cada subasta debe basarse en los datos de un solo sitio adicional. Las subastas anidadas serían una forma de complicarlo, lo que daría como resultado la posibilidad de elegir anuncios en función de un perfil de varios sitios.
Criterio de datos en reposo	Explica con más detalle el criterio de datos en reposo en el modelo de confianza del servicio de par clave-valor.	Los datos del servicio de par clave-valor se cargan en la memoria y se entregan desde allí, en lugar de realizar cualquier almacenamiento en caché de lectura.
Indicador de datos del comprador	¿Existe un límite de tamaño definido para los indicadores `buyer_data` que se reciben de las DSP?	Actualmente, no hay límites impuestos por el navegador para los indicadores `buyer_data` que se reciben de las DSP.

Medición de anuncios digitales

Attribution Reporting (y otras APIs)

Tema de los comentarios	Resumen	Respuesta de Chrome
Dispositivos múltiples	Planifica la compatibilidad multidispositivo para la API de Attribution Reporting.	La medición multidispositivo presenta nuevos desafíos de privacidad además de la medición en 3PC y también agrega desafíos de distribución de tecnología debido a la variedad de dispositivos y plataformas que puede usar un usuario. Estamos explorando posibles soluciones, pero nos enfocamos en los casos de uso fundamentales que actualmente admiten los informes de atribución y no tenemos planes para implementar la compatibilidad multidispositivo antes de la eliminación de las cookies de terceros.
(También se informa en trimestres anteriores) 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 entre sitios y contextos sobre un usuario sea limitada. Invitamos a los participantes del ecosistema a enviar comentarios sobre si la parametrización actual para los informes a nivel del evento es suficiente.
Embudo de conversión	Informar varios dominios que se utilizaron en la conversión	Este caso de uso es posible desde que se agregan varios destinos. Envíanos tus comentarios adicionales.
Compatibilidad con el mismo dominio en diferentes países	¿Los informes de atribución funcionan con sitios web que tienen el mismo dominio, pero varios TLDs de países?	Este problema se analizó y resolvió con la parte interesada que planteó la pregunta. Si una tecnología publicitaria necesita usar varios TLD de país, deberá tener varias inscripciones, una para cada TLD de país.
Protected Audience y Attribution Reporting	¿Las tecnologías publicitarias pueden acceder a las conversiones posimpresión para las subastas de Protected Audience y a las conversiones posclic para los informes de atribución?	Sí, Privacy Sandbox debería admitir VTC y CTC en Protected Audience.
Retrasos en los informes agregables	Reducir aún más las demoras en los informes agregables	Recibimos comentarios recientes sobre este tema y compartimos ideas aquí. Agradecemos los comentarios adicionales del ecosistema.
Retrasos en los informes agregables	Reducción de las demoras mediante la introducción de la mediación del servidor	Estamos considerando esta propuesta y agradecemos los comentarios adicionales .
Retrasos en los informes a nivel del evento	Reducir los retrasos en los informes a nivel del evento	La propuesta flexible completa a nivel del evento, que se describe en Configuraciones flexibles a nivel del evento, puede reducir las demoras de los informes a nivel del evento hasta en 1 hora con una compensación de ruido.
Origen de los informes de fuentes por fuente	La limitación de los orígenes de informes de fuentes máximos por sitio de informes de fuentes evita que las tecnologías publicitarias registren fuentes de diferentes orígenes de informes para un solo origen de publicador.	Se analizó el problema con la parte interesada que lo planteó, y se está probando una posible solución de usar 1 origen de informes por sitio de informes de origen antes de probar otras posibles soluciones que involucren redireccionamientos. También estamos abiertos a cualquier comentario adicional del ecosistema sobre este límite.
Informes de problemas	¿Cómo podemos informar errores o problemas con la API de Attribution Reporting a Chrome?	Actualmente, recomendamos que las tecnologías publicitarias informen cualquier error de la API de Attribution Reporting que puedan tener como un problema en GitHub. Si tiene un problema relacionado con Chrome, te recomendamos que crees un error de Chromium. En Interactúa y comparte comentarios, encontrarás vínculos sobre cómo y dónde marcar cualquier problema.
Anulación de duplicación	¿Cómo podemos anular la duplicación de las conversiones en diferentes canalizaciones y dispositivos?	La anulación de duplicados en los dispositivos y las canalizaciones de medición es un desafío conocido y actual que las tecnologías publicitarias también enfrentan hoy en día con los 3PC. Con la API de Attribution Reporting, las tecnologías publicitarias pueden decidir cuándo registrar conversiones específicas y agregar metadatos específicos para indicar qué canalizaciones de medición se usaron para hacer un seguimiento de las conversiones (en otras palabras, parte de la clave de agregación), que se pueden comparar con otras canalizaciones de medición. Estamos abiertos a cualquier comentario adicional del ecosistema sobre este tema.
Anulación de duplicación y prioridad	Solicita tener prioridad antes de la anulación de duplicación.	Estamos considerando esta solicitud y agradecemos los comentarios adicionales.
Lucha contra el fraude	Riesgo de que un usuario malicioso manipule los datos a nivel del evento.	La verificación de informes no funciona para los informes a nivel del evento por los motivos que se describen en ¿Por qué no se admiten informes a nivel del evento?.
Tipo de conversión	¿Cómo podemos diferenciar entre la vista a través y la navegación en los informes de atribución?	Tenemos la siguiente opción de filtrado integrada: `source_type`. Aquí encontrarás más detalles.

Servicio de agregación

Tema de los comentarios	Resumen	Respuesta de Chrome
Recuperación del presupuesto	Algunas tecnologías publicitarias solicitaron la capacidad de volver a procesar informes en los casos en que haya fallas, errores o eliminaciones de sus informes.	El equipo está explorando formas de abordar este problema de una manera que preserve la privacidad.
Inscripción del sitio	Varias tecnologías publicitarias solicitaron asistencia para procesar varios orígenes en la misma cuenta para casos de uso como dividir los datos por ubicación geográfica o anunciante. Las tecnologías publicitarias también esperan este comportamiento, ya que la inscripción de la API del cliente ahora se basa en el sitio (y no en el origen). La migración de la inscripción de origen a la del sitio optimiza el proceso de integración de la tecnología publicitaria a través de la coherencia con el proceso de inscripción del cliente.	Pronto lanzaremos la migración de la inscripción de origen a la inscripción del sitio para el servicio de agregación y esperamos recibir comentarios del ecosistema.
Plan de lanzamiento y baja	Se publicó el programa de lanzamiento y depreciación de las funciones y los parches del servicio de agregación. El objetivo del plan es brindar a las tecnologías publicitarias visibilidad de nuestras políticas de lanzamiento para que puedan prepararse para los próximos lanzamientos y bajas, y garantizar que ejecuten versiones estables y seguras de los servicios.	Recientemente, publicamos una propuesta para el plan de lanzamiento y baja del servicio de agregación y recibimos con gusto comentarios adicionales.
Coordinadores	¿Qué sucede si los coordinadores dejan de funcionar en el servicio de agregación?	Ambos coordinadores deben estar completamente disponibles para que el sistema funcione correctamente. La falta de disponibilidad breve se ajusta con reintentos en nuestras bibliotecas cliente. Si la falta de disponibilidad de cualquiera de los dos coordinadores es más prolongada, fallarán las tareas de agregación. Las tareas se pueden volver a ejecutar si aún no se consume el presupuesto de privacidad. En el caso de que una falla del servicio haya provocado el consumo del presupuesto sin un informe de resumen escrito en el almacenamiento de la tecnología publicitaria, actualmente recomendamos que usen informes de depuración para recuperar los resultados con la herramienta de pruebas locales. También estamos trabajando en funciones que permitan la recuperación del presupuesto en caso de fallas, de modo que las tecnologías publicitarias puedan volver a ejecutar sus tareas.

API de Private Aggregation

Tema de los comentarios	Resumen	Respuesta de Chrome
URL del blob	Solicitud para admitir la URL de blob en el almacenamiento compartido.	Se agregó compatibilidad con la URL de Blob en Chrome M116.

Limita el seguimiento encubierto

Reducción de usuario-agente y sugerencias de cliente de usuario-agente

Tema de los comentarios	Resumen	Respuesta de Chrome
API de JavaScript	Disponibilidad de la API de User-Agent Client Hints para JavaScript	No tenemos planes de quitar esta funcionalidad, ya que es nuestra solución principal para los socios que desean acceder de forma activa a los datos de alta entropía más allá de lo que está disponible de forma predeterminada en la UA congelada y reducida.
Información del dispositivo y el factor de forma	Es la capacidad de los sitios web para comprender las entradas, las salidas y otra información que puede admitir el dispositivo que visita el sitio web.	Agregamos compatibilidad con esta solicitud después de recibir comentarios del ecosistema.

IP Protection (antes Gnatcatcher)

Tema de los comentarios	Resumen	Respuesta de Chrome
Tráfico de terceros apto	¿A qué se refiere el "tráfico de terceros apto" en la explicación?	Comprendemos la importancia de esta pregunta y estamos trabajando activamente para identificar qué tráfico de terceros será apto y cuál no. Agradecemos los comentarios sobre este tema.
Auditoría de tráfico de red	Compatibilidad con empresas para realizar auditorías de tráfico de red en sus redes	Solo se verá afectado el tráfico de terceros incorporado en sitios propios, lo que debería limitar la cantidad de tráfico que requiere filtrado. Además, planeamos darles a los usuarios la opción de usar o no la Protección de IP. En el caso de Chrome controlado por empresas, habrá políticas empresariales para inhabilitar la Protección de IP. Por último, estamos explorando qué controles (si los hay) se proporcionarán a los operadores de red para inhabilitar la Protección contra IP. Los comentarios sobre este tema son bienvenidos.
Control de acceso	La Protección de IP puede afectar a los servicios web que usan direcciones IP para el control de acceso.	Comprendemos la importancia de los casos de uso contra el fraude y el posible impacto en ellos. Estamos buscando comentarios del ecosistema sobre cómo podemos admitir mejor los casos de uso de prevención de fraudes que, por lo general, se basan en direcciones IP.
Comunicación entre los proxies de 2 saltos	Cómo garantizar que no haya información entre los proxies	Estamos en proceso de diseñar las interacciones de proxy. Nuestro objetivo es minimizar las posibilidades de que se comparta esa información a través de medios comerciales, de procesos y técnicos.
Autenticaciones que no son de Google	Compatibilidad con autenticaciones que no son de Google	Planeamos publicar más detalles sobre la autenticación de cuentas en el futuro, aunque ya compartimos algunas consideraciones iniciales.
Clasificación de dispositivos de rastreo	¿Cómo determinará la Protección de IP qué constituye un servicio de seguimiento y sus variantes?	Comprendemos la importancia de esta pregunta y estamos trabajando activamente para identificar qué tráfico de terceros será apto y cuál no. Agradecemos los comentarios sobre este tema.
Analytics	La Protección de IP puede afectar la precisión de los servicios de estadísticas.	Queremos comprender mejor el impacto de la protección de la propiedad intelectual y estamos a la espera de más comentarios y ejemplos del ecosistema.
Proxy	Si un usuario usa un proxy o definió uno de forma manual, ¿cómo funcionará la máscara de IP en este caso?	Queremos comprender el impacto que la Protección de IP podría tener en otros proxies. No tenemos planes para compartir en este momento. Aceptamos comentarios sobre este tema.
Oferta premium	¿IP Protection será una función pagada?	La Protección de IP estará disponible para los usuarios de Chrome como parte de la experiencia principal del navegador. No será una función pagada.
Servidor proxy	¿Se usarán los mismos servidores proxy durante las sesiones del usuario?	Una conexión HTTP/S usará un solo par de proxies y mostrará una sola dirección IP enmascarada al origen. Más allá de eso, no hay restricciones estrictas sobre las diferentes conexiones HTTP/S que deben usar los mismos servidores.
Plataformas compatibles	¿En qué plataforma se admitirá la Protección de IP?	Inicialmente, la Protección IP estará disponible en Chrome para Android y computadoras. Seguimos evaluando cómo expandir la protección a otras plataformas.
Inhabilitar	¿Los usuarios podrán inhabilitar IP Protection?	Planeamos ofrecer a los usuarios la opción de usar la Protección de IP o no.
Anonimización	¿Qué tipos de solicitudes se anonimizarán con la Protección de IP?	Las solicitudes HTTP/S y DNS a dominios de terceros aptos se anonimizan a través de los proxies de privacidad. Proporcionaremos detalles adicionales en una próxima explicación sobre cómo determinaremos qué dominios se incluirán. El resto del tráfico (por ejemplo, el resto de las solicitudes de DNS o cualquier otro tráfico HTTP/S) no se ve afectado.
Visibilidad de datos	Se puede acceder a las direcciones de red durante el primer salto en la Protección IP.	En el modelo de proxy de dos saltos, el primer salto (controlado por Google) solo ve la IP del cliente de origen y una solicitud para conectarse al segundo salto, mientras que el segundo salto (controlado por una CDN externa) solo ve una tupla en el primer salto (IP del proxy + puerto) y la IP de destino. Para la respuesta que se muestra desde el origen, el segundo salto puede reenviar la respuesta al proxy y el puerto del primer salto asociados con la solicitud, y no necesita obtener información sobre la IP del cliente original (y el primer salto solo muestra la respuesta al cliente, sin obtener información sobre la IP de destino). De esta manera, el primer salto solo aprende la IP del cliente y el segundo salto, mientras que el segundo salto solo aprende la IP de destino.
WebView	¿La Protección de IP estará disponible para Android WebView en el futuro?	No tenemos planes para compartir en este momento, pero nuestra visión es brindar esta protección de la manera más amplia posible.

Mitigación del seguimiento por rebote

Tema de los comentarios	Resumen	Respuesta de Chrome
Seguimiento de interacciones	¿Cómo se realiza el seguimiento de las interacciones de los usuarios?	Las mitigaciones del seguimiento por rebote hacen un seguimiento de dos tipos de interacciones del usuario: Activaciones del usuario según se define en las especificaciones de HTML. Básicamente, son clics, presiones de teclas, toques en la pantalla táctil, etcétera. Aserciones de webauth correctas Estos son casos en los que un usuario presiona una llave de seguridad o usa una llave de acceso como forma de autenticación. Estas interacciones se asocian con el sitio de nivel superior en las páginas en las que ocurren. Por ejemplo, si un usuario hace clic en un iframe incorporado, la interacción se asocia con el sitio de nivel superior y no con el sitio incorporado. Las interacciones se almacenan en una base de datos que contiene el etld+1 sin esquema y la hora de la interacción. Las interacciones protegen el dominio asociado de la eliminación del estado de mitigación del seguimiento de rebote durante 45 días.
Exenciones incluidas en la lista de entidades permitidas	¿Se pueden eximir los dominios?	Estamos considerando esta solicitud y recibimos con gusto comentarios adicionales del ecosistema.

Privacy Budget

No se recibieron comentarios este trimestre.

Fortalecimiento de los límites de la privacidad entre sitios

Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)

Tema de los comentarios	Resumen	Respuesta de Chrome
Enfoque centralizado	Inquietud por el enfoque de repositorio centralizado para administrar los conjuntos de sitios web relacionados	Un repositorio público de fácil acceso es clave para el diseño de RWS, ya que proporciona responsabilidad por los envíos. En última instancia, la funcionalidad de las cookies de terceros se proporciona mediante el uso de la API de Storage Access o la API de rSAFor, y la membresía de RWS proporciona acceso otorgado automáticamente (en lugar de a través de mensajes con la API de Storage Access). Creemos que un enfoque como el proceso de envío de RWS es un requisito adecuado para el acceso automático a cookies de terceros.
Cambia el nombre del archivo JSON	Con el cambio en el nombre de la API, ¿se debe cambiar el nombre del archivo JSON alojado?	Sí, se cambiaron los lineamientos de envío, y el dominio principal debe entregar un archivo JSON en `/.well-known/related-website-set.json`. No es necesario cambiar los conjuntos existentes en la lista de RWS, pero si se envían modificaciones a los conjuntos existentes, se debe cambiar el archivo JSON.
Límite de dominios (también se informa en trimestres anteriores)	Solicitud para expandir la cantidad de dominios asociados	Como se anunció en una entrada de blog el 31 de agosto, aumentamos el límite de dominios asociados a cinco después de recibir comentarios del ecosistema. Decidimos aumentar el límite de dominios asociados a cinco dominios (más un dominio principal) que coincidan mejor con la implementación más comparable que ofrece otro navegador importante.
Cookies de terceros	¿Los Conjuntos de sitios web relacionados solo funcionarán con las cookies de terceros inhabilitadas?	Los conjuntos de sitios web relacionados funcionarán incluso cuando un usuario no haya bloqueado las cookies de terceros, pero no se observará ningún efecto, ya que las cookies relevantes están disponibles sin necesidad de los conjuntos de sitios web relacionados ni de la API de acceso a almacenamiento.
Ediciones legítimas	¿Cómo el repositorio de conjuntos de sitios web relacionados evita que personas que no son propietarios modifiquen los conjuntos?	Según las guías de envío, cualquier persona puede enviar una solicitud de extracción en GitHub para editar el archivo `first_party_sets.JSON`. Sin embargo, si se aprueba la PR (pasa las validaciones técnicas, etcétera), Google la combinará manualmente en lotes con la lista canónica de FPS una vez por semana (los martes a las 12 p.m., hora del este). Si un usuario malintencionado intenta modificar un conjunto que no le pertenece, no debería ser un problema, ya que no podrá modificar los archivos `.well-known` y, por lo tanto, las validaciones fallarán.
Secuestro de dominio	El secuestro de dominios puede exponer los datos relacionados con el dominio a terceros no autorizados.	Esto no es posible, como se explica en este problema de GitHub de Protected Audience.

API de Fenced Frames

Tema de los comentarios	Resumen	Respuesta de Chrome
Infracción de contenido	Permite que los usuarios denuncien anuncios sospechosos.	Los marcos delimitados no impiden que se denuncien anuncios sospechosos. Los usuarios pueden interactuar con el anuncio y denunciar los anuncios sospechosos a la tecnología publicitaria de la forma habitual.
Interacción con sitios cercanos	Permite la interacción con el sitio web circundante o de nivel superior.	Queremos comprender por qué es necesaria esta solicitud y agradecemos los comentarios adicionales del ecosistema.
Publicidad nativa	Compatibilidad con el marco de límite para la publicidad nativa	Estamos considerando admitir el caso de uso y estamos analizando posibles solución y alternativas.

API de Shared Storage

Tema de los comentarios	Resumen	Respuesta de Chrome
Multidominio	Permite la comunicación entre dominios para el almacenamiento local.	Actualmente, este caso de uso no está alineado con las puertas de salida que preservan la privacidad de Shared Storage, pero recibimos con gusto contexto adicional a medida que desarrollamos propuestas para el almacenamiento no particionado.
URL del blob	Solicitud para admitir la URL de blob en el almacenamiento compartido.	Se agregó compatibilidad con la URL de Blob en Chrome M116.

CHIPs