Informe de comentarios (4o trimestre de 2023)

Informe trimestral del cuarto trimestre de 2023 en el que se resumen 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 comentarios que recibe Chrome de diversas fuentes, como se detalla en la descripción general de 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 función de la API. Para ello, se agrega la cantidad de comentarios que el equipo de Chrome recibió sobre un tema determinado y se organiza en orden descendente de cantidad. Los temas de comentarios comunes se identificaron a partir de la revisión de 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 y los formularios públicos de Google.

Más concretamente, se revisaron las actas de las reuniones de los organismos web estándar y, para obtener 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 público de comentarios. Luego, Google coordinó entre 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 los 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. 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 del informe actual aún no tengan una respuesta de Chrome considerada.

Glosario de acrónimos

CHIPS

Cookies con estado particionado independiente

DSP

Plataforma orientada a la demanda

FedCM

Administración de credenciales federadas

MPS

Conjuntos propios

IAB

Oficina de Publicidad Interactiva

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

TE

Prueba de origen

PatCG

Grupo comunitario de tecnología publicitaria privada

RP

Persona de confianza

SSP

Plataforma de proveedores

TEE

Entorno de ejecución confiable

UA

Cadena de usuario-agente

UA-CH

User-Agent Client Hints

W3C

Consorcio World Wide Web

WIPB

ceguera de IP voluntaria

Comentarios generales, sin API o tecnología específicas

Tema de los comentarios	Resumen	Respuesta de Chrome
Cronograma de 3PCD	Compartir más información sobre el cronograma de 3PCD.	Para facilitar las pruebas, a partir del 4 de enero de 2024, Chrome restringió las 3PC de forma predeterminada para el 1% de los usuarios. Sujeto a las inquietudes restantes de la CMA, Chrome planea dejar de admitir gradualmente las 3PC a partir del tercer trimestre de 2024 y continuar durante el resto del 2024.
Cronograma de 3PCD	Impacto de los tiempos de las 3PCD durante el 4o trim. de 2024, ya que coincide con la temporada de festividades y podría tener un impacto negativo en los publicadores.	No existe un momento perfecto para dar de baja las 3PC. Durante mucho más de un año, estuvimos en claro que nuestra intención era dar de baja las 3PC en la segunda mitad de 2024. Nuestros compromisos con la CMA, que incluyen los plazos potenciales de un período de inactividad, no cambiaron. Si bien entendemos la preocupación del cuarto trimestre, realizar cambios en el cronograma dio como resultado menos preparación para la industria, no más.
Prueba de Chrome (modo a/b)	¿La configuración de prueba para los modos A y B es por instancia o por perfil de Chrome?	Aquí publicamos una aclaración sobre el hecho de que el navegador Chrome en este contexto hace referencia a un cliente de Chrome: una instalación de Chrome en un dispositivo. Cada directorio individual de datos del usuario constituye un cliente diferente.
Prueba de baja	Compartir más información sobre la prueba de 3PCD.	Compartimos más información sobre la prueba de 3PCD aquí.
Prueba de baja	No hay tiempo suficiente para proporcionar tokens de prueba de baja en todos los sitios antes de enero de 2024.	Sabemos que existe un breve período entre el momento en que se abren los registros de la prueba de baja y el momento en que comienza el período de prueba facilitada por Chrome a bloquear el 1% de las cookies. Para abordar estas limitaciones de tiempo, Chrome otorga un período de gracia a los orígenes participantes mientras trabajan en la implementación de tokens de prueba de baja. Durante el período de gracia, que durará hasta el 1 de abril de 2024, los orígenes registrados para la prueba de baja tendrán acceso a las 3PC en Chrome, incluso si todavía no implementaron sus tokens. El propósito de este período de gracia es evitar problemas de compatibilidad web durante la fase de transición. Los orígenes participantes deben implementar tokens de prueba de baja antes de que finalice el período de gracia para seguir teniendo acceso a las 3PC después de que finalice el período de gracia.
Prueba de Chrome (modo a/b)	El modo B es una muestra demasiado pequeña para medir de manera correcta las disminuciones de rendimiento con precisión.	Se debe lograr un equilibrio cuidadoso entre el porcentaje de tráfico y el riesgo de impacto en los usuarios y la funcionalidad en toda la Web.
Controles de prueba	Solo los publicadores de gran tamaño con recursos de desarrollo significativos podrán comprender el rendimiento durante las pruebas y transferirlo a la CMA.	Ya estamos viendo que los proveedores de servicios para publicadores comparten estadísticas públicamente con el ecosistema más amplio y esperamos que esta acción continúe a medida que aumentan las pruebas de Privacy Sandbox. También esperamos que las empresas de tecnología publicitaria que compilan sobre las APIs de Privacy Sandbox sigan desarrollando las funciones que demandan sus clientes, como la generación de informes basados en etiquetas.
Datos de terceros	Inquietud por las empresas de datos de terceros.	Existen diferentes variantes de empresas de datos de terceros. Algunos podrían redoblar la apuesta y recurrir a métodos cada vez más opacos de seguimiento entre sitios web. Otros pueden recurrir a tecnologías que mejoren la privacidad y desarrollar nuevas propuestas de valor con sus clientes. Esperamos que cada vez más elijan hacer lo último y que viajen en la dirección que tanto los usuarios como los reguladores exigen cada vez más. El cambio generará oportunidades de innovación y evolución.
Google Ad Manager	Se necesita más orientación de Google Ad Manager sobre cómo los publicadores pueden probar Privacy Sandbox. Los informes no son suficientes para que los publicadores comprendan el impacto.	Respuesta proporcionada por Google Ad Manager: Google Ad Manager explica cómo se realizarán las pruebas con etiquetas de pruebas facilitadas por Chrome en su Centro de ayuda. Actualmente, Ad Manager proporciona a los publicadores informes sobre Topics y Protected Audience. En el momento de este Informe de comentarios, Ad Manager puede generar informes sobre las impresiones publicadas a través de la API de Protected Audience y puede indicar si los datos de la API de Topics estuvieron presentes en una impresión dada. Los publicadores que estén interesados en obtener informes más sofisticados, como la segmentación de informes basados en etiquetas facilitadas por Chrome, pueden leer las etiquetas directamente desde Chrome (con la documentación de Chrome) y pasarlas como pares clave-valor en solicitudes de anuncios a Ad Manager, así como informes de pares clave-valor para generar informes sobre las etiquetas.
Prueba de incentivo	A los anunciantes les preocupa el tiempo suficiente para probar Privacy Sandbox y los posibles cambios materiales en las APIs.	Entendemos que algunas personas quieren más tiempo, pero hemos escuchado en repetidas ocasiones a la industria que cambiar el plazo puede implicar menos preparación para el ecosistema, no más. Si bien el cronograma para dar de baja las 3PC está sujeto a abordar cualquier inquietud pendiente respecto de la competencia de la CMA, alentamos a todos a prepararse para 3PCD en 2024. Como cualquier tecnología, las APIs de Privacy Sandbox seguirán evolucionando. Esa evolución es producto de los avances en las tecnologías y los aportes del ecosistema. Seguiremos siendo responsables a medida que realicemos cambios y no creemos que los cambios en la tecnología deban inhibir indefinidamente el uso.
CTV	No hay ruta de acceso para admitir videos lineales o de CTV.	Esperamos explorar más los casos de uso de CTV, pero no creemos que las APIs para sus dispositivos de CTV interfieran en el camino de 3PCD en Chrome.
Servidores de anuncios del anunciante	Al parecer, Google está cambiando la segmentación de anuncios a DV360. ¿Qué tipo de asistencia se brindará para los servidores de anuncios de los anunciantes?	Respuesta proporcionada por Chrome: La API de PA está diseñada para que los servidores de anuncios de anunciantes publiquen y midan los anuncios que se muestran a un usuario mediante el uso de informes de iframes, marcos vallados y balizas. Además, trabajarán con partes ascendentes y descendentes para integrar el flujo de entrega, como lo hacen en la actualidad.
Administrador de datos de Google Ads	Recientemente, anunciamos que el "Administrador de datos de Google Ads" se basa en la Segmentación por clientes y las conversiones avanzadas, lo que permite a los anunciantes compartir sus datos de origen de los clientes con Google para mantener todas las funciones de marketing que realizan las terceros. ¿Cómo se alinea esta nueva función con los compromisos de Google con la CMA?	Respuesta proporcionada por Google Ads: El Administrador de datos de Google Ads simplemente facilita la carga de datos de origen de los sistemas de almacenamiento de datos del anunciante (sistemas en la nube) para que los anunciantes los utilicen para la Segmentación por clientes (CM) y las conversiones avanzadas (EC), lo que facilita a las pequeñas y medianas empresas con menos recursos técnicos. El Administrador de datos de Google Ads no habilita ninguna función nueva para CM o conversiones avanzadas en términos de direccionabilidad o medición de los anuncios en publicadores externos de propiedad y administración de Google. Las plataformas de anuncios de Google tienen el mismo acceso a las funciones disponibles en las tecnologías de Privacy Sandbox que otras empresas de tecnología publicitaria.
Configuración de Chrome	La página de configuración interna de Chrome debe proporcionar más información sobre el tamaño de las cookies.	La funcionalidad solicitada ya está disponible en las herramientas para desarrolladores de Chrome. También recibiremos comentarios adicionales sobre los motivos por los que se debe priorizar esta función en la página de configuración.
Heurística	¿Qué heurísticas implementa Chrome para preservar las experiencias críticas del usuario durante 3PCD?	Consulta nuestra respuesta a esta pregunta en GitHub.
Versiones del navegador	¿Puedes diferenciar los navegadores Chrome estables de los no estables?	Se puede hacer una coincidencia aproximada de la versión principal de Chrome con el ciclo de lanzamiento estable.
Cumplimiento	¿Chrome puede proporcionar informes relacionados con SOX?	Chrome no proporcionará informes relacionados con SOX. Las APIs de Privacy Sandbox son una de las muchas APIs web que Chrome pone a disposición de los sitios web que visita un usuario. Al igual que con todas las APIs web, el llamador de la API no celebra un acuerdo con Chrome para usar la API de Privacy Sandbox. El acceso solo depende de si el llamador de la API cumple con algún requisito técnico y si el usuario tiene habilitada la configuración adecuada. Si es así, el llamador de la API por sí solo determina cómo usar la API, incluidos los datos que se almacenarán, las ofertas que se realizarán, los informes que se solicitarán, etcétera.
Cumplimiento	Ampliamos las Preguntas frecuentes sobre el cumplimiento de Privacy Sandbox para responder más inquietudes.	Agradecemos los comentarios y planeamos seguir ampliando las preguntas frecuentes.
Pregunta sobre Chrome	¿La baja de las 3PC en Chrome afecta la disponibilidad de las 3PC en WebView de Android (navegador incorporado)?	Actualmente, no incluimos WebView en esta etapa del lanzamiento y las pruebas de la API de 3PCD o Privacy Sandbox, más allá de la habilitación de la medición de atribución web y entre apps.
Pregunta sobre la API	¿Cómo se puede hacer un seguimiento de los clics y las impresiones de los productos patrocinados?	Este caso de uso se abarca en la API de Attribution Reporting.
Cronograma	¿Por qué cambió el cronograma de 3PCD?	Consulta los motivos aquí.
SSO de extensión de Chrome	Permite el caso de uso del inicio de sesión único entre un sitio web y una extensión de Chrome después de 3PCD.	Estamos analizando este problema y agradecemos que nos envíes comentarios sobre casos de uso adicionales.
Uso de la API	¿Puede Google confirmar una lista de socios para probar las APIs?	Los detalles de los verificadores que se identificaron públicamente están disponibles en GitHub para las siguientes APIs: - API de Topics - API de Protected Audience - API de Attribution Reporting - Almacenamiento compartido - CHIP
Iniciativa Utiq	¿Cuál es la visión de Chrome respecto de la iniciativa Utiq?	Estamos analizando este tema aquí.
Pregunta sobre Chrome	¿Cómo se detectan los usuarios que navegan sin 3PC?	No hay un parámetro de configuración explícito para detectar el bloqueo de las 3PC. Para un enfoque general de "detección de funciones", recomendamos crear la solicitud de iframe o entre sitios, y tratar de establecer una cookie similar para el caso de uso requerido es la solución más cercana.
Pregunta sobre Chrome	¿La navegación en modo Incógnito es lo mismo que ejecutar la prueba de marca (se inicia Chrome con la marca de línea de comandos --test-third-party-cookie-phaseout)?	El modo Incógnito es diferente de la marca. La marca no solo bloquea las 3PC, sino que también habilita la partición de almacenamiento de FedCM y de terceros.
Pregunta sobre Chrome	Más detalles sobre el impacto esperado de los terceros en cada región o país cuando ocurre un 1%.	Los clientes se incluyen en el 1% de forma aleatoria, en todo el mundo, aunque puede haber variaciones regionales. Por ejemplo, puede haber diferencias en la distribución de los dispositivos y las versiones de Chrome.
Tecnologías alternativas para mejorar la privacidad	Se debe permitir que las tecnologías alternativas de mejora de la privacidad realicen seguimientos entre dominios que preserven la privacidad para evitar un monopolio de datos en Chrome y Android.	Hay muchas oportunidades para que los desarrolladores creen ofertas de tecnología que mejoren la privacidad además de los componentes básicos que ofrecemos y que no sean de Privacy Sandbox.
Estudio de CookieGraph	¿Cuál es la perspectiva de Chrome sobre el método CookieGraph, como se describe en este informe dentro del framework de Privacy Sandbox?	Estamos revisando este documento y te damos la bienvenida a los comentarios adicionales.

Inscripción y certificación

Tema de los comentarios	Resumen	Respuesta de Chrome
La inscripción es restrictiva	Google introdujo condiciones de uso específicas para las APIs de Privacy Sandbox. Las condiciones impiden eficazmente que las empresas que se especializan en ayudar a los publicadores a reconocer a los visitantes que dan su consentimiento para probar o integrar las funciones de Privacy Sandbox en su solución de identidad. Los Términos y Condiciones limitan injustamente su capacidad de operar dentro de Privacy Sandbox.	El proceso de inscripción y certificación no implica aceptar las condiciones de uso de la API. La inscripción y certificación son mecanismos destinados a mejorar la transparencia con respecto a qué desarrolladores llaman a las APIs de Privacy Sandbox y cómo usan los datos a los que acceden. Específicamente, la certificación es una declaración pública de que el desarrollador que otorga la certificación no usa las APIs para identificar a los usuarios en sitios o apps, y no elude de ninguna otra manera las protecciones de la privacidad de las APIs. La certificación no requiere realizar declaraciones sobre el uso que hacen los desarrolladores de otros datos o tecnologías.
Inscripción a Privacy Sandbox	¿Cómo puedo actualizar el punto de contacto o la dirección de correo electrónico para la certificación?	La información de inscripción se puede actualizar con el formulario correspondiente. Obtenga más información aquí.
Inscripción a Privacy Sandbox	¿Pueden aclarar las situaciones de límite de acceso en caso de que la certificación no esté disponible?	Privacy Sandbox permitirá que un contacto técnico restablezca el archivo de certificación del sitio inscrito en un plazo de 3 semanas antes de denegar el acceso de una empresa inscrita a las (APIs de medición y relevancia).
Inscripción a Privacy Sandbox	¿Cómo podemos probar las APIs en un entorno local con extremos que no sean de producción?	Respondemos esta pregunta aquí.

Mostrar anuncios y contenido relevantes

Temas

Tema de los comentarios	Resumen	Respuesta de Chrome
Utilidad para diferentes tipos de interesados	A los publicadores les preocupa el impacto de los temas en las ventas basadas en datos. A los sitios de mayor tamaño se les asigna un tema general de "noticias", sin que ningún dato lo vincule al editor específico. Los publicadores especialistas entregan sus datos a cambio de información limitada.	Sabemos que es probable que los sitios con dominios de interés general más aporten temas menos detallados que los sitios con dominios de interés más especializados. Sin embargo, no todos los sitios especializados aportan temas comercialmente valiosos. Además, esta dinámica refleja el statu quo: algunos sitios proporcionan más valor que otros en los sistemas de relevancia del anuncio basados en las 3PC. Topics (y Privacy Sandbox en general) proporciona a los publicadores más control sobre cómo las empresas de tecnología publicitaria con las que se asocian las empresas de tecnología publicitaria con las que se asocian tienen más control sobre cómo usan su información. Además, la información disponible a través de Topics es mucho más general que los indicadores existentes.
Servidores de anuncios del publicador	Es posible que los servidores de anuncios del publicador que usan servidores de anuncios dedicados no puedan observar directamente la API de Topics.	Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Certificación	Expande el requisito de certificación para abordar las consecuencias no deseadas conocidas de la transferencia de información entre contextos.	En este momento, la certificación no tiene como objetivo cubrir esta amplia categoría de riesgo, sino abordar el abuso de la API.
Volumen de tráfico de Topics	El volumen actual de impresiones recibidas no es suficiente para realizar pruebas.	Chrome está al tanto de los comentarios relacionados con el volumen de Topics disponibles en el ecosistema programático. Estamos investigando las posibles razones, tanto dentro del navegador como entre los verificadores pertinentes. Si se considera necesario, Chrome evaluará qué posibles cambios en el diseño de la API estarán disponibles para aumentar la tasa de cobertura y realizar pruebas a una escala suficiente, mientras se preserva la privacidad del usuario.
Uso de la API	¿Existe una limitación de frecuencia de la API de Topics?	Existen algunos límites de frecuencia de Topics para evitar abusos y proteger la experiencia de los usuarios en la Web. Puedes obtener más detalles aquí.
Taxonomía de V2	¿Cuáles son los lineamientos de IAB para que los detalles del tema se incluyan en el protocolo de RTB abierto?	Sí, puede encontrar los lineamientos de la IAB para incluir temas en el protocolo Open RTB aquí.
Impacto en los indicadores propios	La versión 2 de la taxonomía detallada de Topics, junto con un proceso para mostrar el valor más alto de esta segmentación detallada (temas principales), distorsionarán el mercado de los datos en publicidad.	Nuestra respuesta no cambió desde el tercer trimestre: "Si bien una taxonomía de Topics más detallada puede disminuir indirectamente el atractivo de otras soluciones, como las basadas en datos de origen de los publicadores o las que dependen de las ofertas directas, a medida que desarrollamos la API de Topics, nuestro objetivo principal es garantizar que admita los casos de uso de publicidad basada en intereses después de 3PCD de la forma más eficaz posible para todas las partes interesadas. Creemos que una mayor utilidad de Topics mejorará la competencia en general y beneficiará al ecosistema en su conjunto".
Lista de verificadores	¿Cuál es la adopción de la API de Topics y PA entre tus publicadores?	No podemos compartir esa información. Puedes consultar la lista de verificadores, en la que los publicadores pueden aceptar compartir su estado de pruebas.
Selección de temas	¿Quieres permitir que los usuarios seleccionen temas de interés de forma proactiva?	Consideramos permitir que los usuarios agreguen temas de manera proactiva. No planeamos abordar este problema a corto plazo, pero estamos dispuestos a explorarlo a largo plazo.
Selección de temas	Si una tecnología publicitaria tiene código en un sitio para observar temas, ¿puede saber cuáles son los temas que se podrían observar?	Una empresa de tecnología publicitaria puede determinar los temas asociados con un sitio. La API no comparte esta información en tiempo real porque puede generar costos de latencia.
Taxonomía de V2	Dado que Topics puede mostrar hasta 3 temas, ¿cuál es el comportamiento esperado cuando se lance Taxonomy v2?	La API aún mostrará hasta 3 temas y, además, incluirá la versión de taxonomía relevante de cada tema en la respuesta.
(También se informó en trimestres anteriores) Observación de temas	Permite que los publicadores otorguen permisos a Chrome para categorizar temas en función del contenido de la página (por ejemplo, encabezado o cuerpo).	Nuestra respuesta no cambió a partir del tercer trimestre: "Anteriormente, consideramos ofrecer funciones para clasificar sitios en temas según su contenido, y tomamos la decisión de no avanzar en función de inquietudes sobre la privacidad y la 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 de 3PCD. Aquí recibimos más comentarios”.
Selección de temas	¿Cómo se clasifican los dominios con Topics dado que son generales?	Solo usamos el nombre de host para clasificar sitios en Topics. Los sitios que se clasifican de forma amplia no se ven perjudicados por ello. Esto se debe a que la información contextual de un sitio siempre estará disponible para subastas en su sitio, lo que proporcionaría información más específica para el tema amplio.
Taxonomía de V2	Desean una mejor alineación de los temas con otros estándares (p.ej., la IAB).	Nos gustaría obtener más información sobre por qué esperaban una alineación más estrecha entre las taxonomías de IAB y Topics. ¿Qué pasos deben seguir para adoptar la API de Topics y cómo afecta una taxonomía más distintiva en esos pasos? Estamos considerando lanzar una asignación entre la taxonomía de Topics y la de contenido de IAB. Sería útil saber si esta acción abordaría los desafíos a los que se enfrentan los publicadores.
Almacenamiento y uso de datos	¿Tiene más información sobre cómo se almacenan los datos y dónde se transfieren?	La información de temas se genera y se almacena de forma local en el dispositivo de un usuario. A pedido, la API muestra hasta 3 temas a los emisores. Según Google, los emisores son responsables de cumplir con las reglamentaciones locales cuando manejen y almacenen la información de Topics. Además, todos los emisores deben certificar que no usan Topics para volver a identificar a los usuarios en los sitios. Para obtener más detalles, consulta las Preguntas frecuentes sobre el cumplimiento relacionado con la privacidad.
Taxonomía de V2	Efecto de la actualización de la taxonomía de Topics y el estado del navegador durante la transición de la v1 a la v2.	Los temas inferidos con la taxonomía anterior aún están disponibles y, con el tiempo, la tecnología publicitaria puede recuperarlos hasta que vencen (4 semanas de antigüedad).
Descripción de la API	La experiencia del usuario de la API de Topics es engañosa.	Compartimos estos comentarios con el equipo de UX.
Pregunta sobre la API	¿Cómo se clasifican los dominios de Yahoo en Topics si se consideran generales?	Solo usamos el nombre de host para clasificar sitios en Topics. Es importante comprender que un sitio que se clasifica de forma amplia no se ve perjudicado por ello.
La tasa de disponibilidad de temas es baja	Los verificadores reciben un volumen bajo de temas de Google Ad Manager.	Google Ad Manager implementó varias optimizaciones para mejorar la cobertura: los compradores deberían haber visto un aumento en la cobertura. Existen algunos factores esperados que pueden limitar la cobertura (p.ej., preferencias del usuario, requisitos de observación por parte del emisor, y potencialmente algo de latencia o tiempos de espera).

API de Protected Audience (anteriormente FLEDGE)

Tema de los comentarios	Resumen	Respuesta de Chrome
Diferenciación	Falta de claridad sobre cómo las SSP aportan diferenciación a la nueva subasta	Sabemos que hay varios planes estratégicos en los que Protected Audience y otras APIs de Privacy Sandbox se destacan. En términos más generales, los especialistas en venta del ecosistema suelen considerar la reducción de identificadores entre sitios como un paso positivo no solo en cuanto a la privacidad, sino también comercial. Es probable que las empresas grandes y pequeñas que adopten este cambio encuentren oportunidades.
Renderización de anuncios	Chrome, como la única ruta para renderizar anuncios, frena la innovación. La renderización de Protected Audience reduce la viabilidad de los estándares actuales en torno a la publicidad nativa.	Los anuncios que se renderizan en navegadores siempre usaron tecnologías de navegador para su renderización. Eso no cambia. Quizás esta preocupación sea específica para los planes que requerirán el uso de Marcos vallados en conjunto con Protected Audience en el futuro. Parte de la razón por la que estos planes son "en el futuro" es exactamente porque queremos que la tecnología de Fenced Frames respalde la innovación y la diferenciación del ecosistema cuando se trata de la renderización de anuncios. Hay tiempo para que los desarrolladores y las empresas interesados analicen la dirección de los marcos vallados, lo que incluye cómo respaldar los enfoques de anuncios nativos.
Entrada	La API de Protected Audience (API de PA) de Concern se entregó como más o menos completa cuando muchas tecnologías publicitarias comenzaron a explorar las APIs de Privacy Sandbox.	Las APIs seguirán evolucionando en función de lo que aprendamos del uso y de las nuevas ideas que surjan tanto dentro como fuera de Chrome. En la actualidad, las APIs de relevancia y medición que están disponibles de manera general son estables, pero eso no significa que se detuvo el desarrollo, por lo que agradecemos que nos envíes comentarios adicionales.
Diseño de subastas	El diseño de Protected Audience coloca toda la lógica de creación de públicos y selección de anuncios en manos de la plataforma orientada a la compra, lo que elimina la capacidad de una SSP de ofrecer creación de públicos y lógica de selección de anuncios para las campañas ejecutadas en su plataforma.	Protected Audience es independiente de quién crea públicos y quién realiza ofertas para ellos. Es posible que una SSP cree un grupo de interés (IG) que pone a disposición para realizar ofertas. También es posible que una SSP proporcione una lógica de ofertas, que parece alinearse con la dirección que muchas SSP siguen para llegar directamente a las agencias. Si bien siempre hay espacio para casos de uso adicionales, las bases de Protected Audience son lo suficientemente flexibles como para admitir muchos enfoques diferentes para la creación y activación de públicos. Las características de privacidad de esas bases también implican que los datos sin procesar a nivel del usuario no se comparten entre sitios.
Diseño de subastas	¿La subasta de Protected Audience es contraria a las iniciativas de optimización de la ruta de suministro (SPO) del ecosistema para reducir la cantidad total de intermediarios entre un anunciante y un publicador, o bien la duplicación de una oportunidad de anuncio determinada?	No. Un anuncio ganador en Protected Audience pasará como máximo dos entidades del vendedor (p.ej., una SSP y un servidor de anuncios del publicador) y tan pocas como ninguna, si el comprador crea una integración directa con el publicador. La duplicación de la misma solicitud a través de varios intermediarios sigue siendo la elección del publicador. Protected Audience no debería afectar de ninguna manera. Las subastas de Protected Audience ocurren fuera del sistema actual en tiempo real de servidor a servidor para no filtrar datos del usuario entre sitios. Algunas personas podrían decir que esto duplica una solicitud de anuncio. Para lograr una privacidad técnicamente demostrable, se requieren algunas compensaciones. Sin embargo, es posible que a largo plazo el ecosistema decida usar Protected Audience sin las subastas tradicionales del servidor. Esta elección podría optimizar aún más las rutas de suministro.
Diseño de subastas	Protected Audience cambia a un modelo en el que las SSP rara vez son la "última" subasta que se ejecuta en la página, pero el diseño de la API obliga a utilizar este modelo.	No estamos de acuerdo. Las implementaciones de usuarios pioneros que observamos realmente facilitan que las SSP que participan en subastas de componentes puedan superar el resultado de la subasta contextual, que se produce antes de que se ejecute la subasta de Protected Audience. Los resultados de la subasta del componente de SSP en Protected Audience se consideran los últimos, después de que se ejecuta una subasta contextual completa.
Diseño de subastas	Es posible que la subasta contextual solo sea relevante para proporcionar indicadores de datos sobre la oportunidad de subasta para fundamentar la subasta de Protected Audience.	Esperamos que las subastas contextuales sigan siendo relevantes por infinidad de motivos, como ofertas, campañas segmentadas por público no propio y muchas situaciones contextuales. También es valioso cuando no hay IG presentes o las ofertas de Protected Audience no alcanzan los precios mínimos o no cumplen con las reglas de calidad de los anuncios.
Determinación del tráfico	Las DSP operan a QPS fijas. La adaptación de las subastas de Protected Audience reducirá la utilidad de la infraestructura heredada.	Según lo que entendemos, lo que está cambiando con respecto a las consultas por segundo es que muchas SSP usan IDs entre sitios como función para determinar si enviar o no una solicitud de DSP. Esto sería así independientemente de si el publicador desea ejecutar o no una subasta de Protected Audience. Exploramos la determinación por tráfico con muchas SSP y encontramos soluciones como el almacenamiento en caché y el filtrado basado en el contexto. Con el tiempo, esperamos que los desarrolladores aprovechen Private Aggregation para facilitar aún más la comprensión de las preferencias de ofertas de la DSP y para aplicar los filtros correspondientes. En última instancia, parte de la infraestructura heredada creada en torno a identificadores entre sitios ya no será útil.
Indicadores disponibles	Falta de claridad sobre la gama completa de indicadores disponibles cuando ocurren las subastas y cómo la secuenciación con la subasta contextual tiene una desventaja.	En términos generales, para los ofertantes, se puede proporcionar información cuando se crea una IG, desde la subasta contextual y desde una búsqueda de par clave-valor en tiempo real. Para los evaluadores, se puede proporcionar información cuando se configura la subasta, incluida la información contextual sobre la página y la subasta contextual, así como desde una búsqueda de par clave-valor en tiempo real en las URLs de renderización de anuncios.
(Se registraron en trimestres anteriores) Renderización de videos	Compatibilidad con la renderización de videos mediante Protected Audience y Frames vallados.	Nuestra respuesta no cambió en comparación con los trimestres anteriores: "La API de Protected Audience admite la renderización de videos a través de un mecanismo que se basa en iframes. Sin embargo, aún no diseñamos una solución que sea compatible con marcos cercados, y esta es una de las razones por las que decidimos rechazar la aplicación de los marcos vallados para 2026. Eso significa que, si un socio decide aplicar de manera forzosa los Fotogramas cercados ahora, el socio no podrá admitir videos".
Renderización de videos	La compatibilidad de la API de PA para videos en iframes se limita a videos HTML5 y no es compatible con el estándar VAST de uso general.	Es posible implementar anuncios basados en VAST con el mecanismo de renderización de iframes disponible actualmente en Protected Audience. Google reconoce que hacerlo requiere nuevas ingenierías por parte de las plataformas de anuncios de los publicadores, compradores y vendedores, y seguiremos trabajando para facilitar la transición desde el modo en que VAST antes funcionaba.
(registrados en trimestres anteriores) Subastas de nivel superior	Capacidad de usar el servidor de anuncios del publicador de Google sin otorgar también a Google Ad Manager el control de la subasta de la API de PA de nivel superior.	Nuestra respuesta no cambió en comparación con trimestres anteriores: "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 ofrecer un servicio adecuado a nuestros clientes en el mercado de publicación de anuncios de los publicadores, el servidor de anuncios del publicador de Google debe conservar el control de la subasta de Protected Audience de nivel superior. Como servidor de anuncios de los publicadores, nuestra función es brindarles previsiones a los publicadores para que puedan negociar las campañas de venta directa sin sobrevender y para definir el ritmo de las reservas directas y publicarlas de forma óptima. Para ello, es necesario ejecutar la subasta final para comparar toda la demanda directa e indirecta apta. La previsión y el ritmo son funciones principales que los publicadores esperan de un servidor de anuncios. Sin una previsión precisa, los publicadores podrían terminar sobrevendiendo su inventario, lo que pone en riesgo la reputación de su empresa. El ritmo también es fundamental, ya que no poder cumplir con los contratos de reservación con los anunciantes también puede generar un daño en la relación directa entre el publicador y el anunciante, lo que podría generar un impacto significativo en el negocio de los publicadores. En resumen, por lo tanto, no vemos la actividad de un servidor de anuncios del publicador de ejecutar la subasta de Protected Audience de nivel superior como distinta de las demás actividades del servidor de anuncios del publicador".
(Se informó en trimestres anteriores) directFrom SellerSignals	directFromSellerSignals permite que Google Ad Manager evite que el publicador vea el precio de su subasta contextual.	Nuestra respuesta no cambió desde los trimestres anteriores: "Respuesta de Chrome: No se sabe que la información que se pasó a runAdSubasta() provenga del vendedor, a menos que este llame a runAdSubasta() desde su propio iframe. En una subasta de varios vendedores, es imposible que todos los vendedores creen el marco llamando a runAdSubasta(). directFromSellerSignals solucionó 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 las subastas del vendedor. Si los publicadores quieren 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 pedirles esta función. Respuesta de Google Ad Manager: Durante años, mantuvimos un enfoque firme en la equidad de las subastas, incluida nuestra promesa 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 oferte en la subasta, lo que luego reafirmamos en nuestros compromisos con la Autoridad de Competencia de Francia. Para las subastas de Protected Audience, tenemos la intención de cumplir con nuestra promesa mediante el uso de directFromSellerSignals y de no compartir la oferta de ningún participante con ningún otro participante antes de que se complete la subasta en subastas de varios vendedores. Para ser claros, tampoco compartiremos el precio de la subasta contextual con nuestra propia subasta de componentes, como se explica en esta actualización".
(Se registraron en trimestres anteriores) Valor de k‐anonimato	¿Cómo se decidirá el valor “K” a “k-anon” y cuándo se publicará?	Publicamos el valor del k-anonimato en diciembre de 2023. Después de que comience el proceso de 3PCD, aumentaremos el umbral de k-anonimato al valor final de 50 (k=50) y estableceremos el período de actualización en 1 hora (p=1). Se evaluó el valor de K-anonimato de 50 como el que proporciona el equilibrio óptimo entre utilidad y privacidad. Este valor es suficiente para impedir ataques básicos de bots y mantener la privacidad diferencial, y es lo suficientemente bajo como para que la API siga siendo útil para los casos de uso previstos.
(Se registraron en trimestres anteriores) forDebuggingOnly	Posibilidad de que se haga un uso inadecuado de forDebuggingOnly.reportAdSubastaWin si el contenido sigue siendo posterior a 3PCD.	Compartimos nuestra propuesta sobre cómo seguir admitiendo los casos de uso de depuración a largo plazo aquí. Agradecemos que nos envíes comentarios adicionales sobre la propuesta.
(Se informó en trimestres anteriores) Política del mismo origen	Solicitud para relajar la política del mismo origen a fin de permitir subdominios.	Se está estudiando esta solicitud, y lo analizamos aquí.
(Se informó en trimestres anteriores) Tamaño del componente del anuncio	Aumentar la cantidad de componentes del anuncio de 20 a 40	Analizamos esta solicitud durante la llamada de WICG del 4 de octubre y en este problema de GitHub, y planeamos abordarla a fines del 1er trim. de 2024.
(Se informó en trimestres anteriores) Vencimiento de la clave del servidor de par clave-valor	Debate sobre la eliminación de claves del servidor una vez que caducan los IG correspondientes.	La administración del TTL se realiza mejor fuera del TEE para reducir la complejidad, aunque aceptamos comentarios adicionales aquí.
Activadores de grupos de interés	¿Puede un solo IG activar múltiples generateBids en una sola subasta (de componente)?	Cada vez que el navegador llama a la función generateBid() de una IG, esa IG puede mostrar un valor de oferta. Es posible que, p.ej., en una subasta de varios vendedores, se llame a un IG varias veces, cada vez en una de las subastas de componentes. El propietario de la IG no tiene que hacer nada explícitamente para activar o admitir este comportamiento.
Preguntas sobre el cumplimiento	¿Cuál es el alcance del consentimiento que se recopila a través del navegador Chrome de un usuario?	Para obtener más información, consulta "¿Cómo se aborda Privacy Sandbox en cuanto al cumplimiento relacionado con la privacidad en Chrome?" en las Preguntas frecuentes sobre el cumplimiento relacionado con la privacidad.
Subastas de varias etiquetas	¿Cómo adaptar las subastas con varias etiquetas?	Estamos evaluando esta solicitud y agradecemos que nos envíes comentarios aquí.
Disponibilidad de protección de IP	¿Cuál es el impacto en los cronogramas de las funciones de Protected Audience, como la aplicación de Fence Frame y la eliminación o eliminación de los Informes a nivel del evento si la protección de IP no está lista para las fechas anunciadas?	Como se mencionó aquí, creemos que los cronogramas de Protected Audience deben vincularse con los cronogramas de lanzamiento de otras funciones de protección de la privacidad.
modelingSignals	Solicitud de un campo nuevo además de modelSignals que solo pueden codificar información de anuncios y clics	Comprendemos las ganancias que ofrece esta información y estamos evaluando la solicitud y agradecemos los comentarios adicionales que nos envíes aquí.
IG negativo	¿Sería posible permitir que los IG normales especifiquen un nombre de IG negativo?	Actualmente, esto no es posible conforme a la explicación, pero aceptamos comentarios adicionales del ecosistema sobre el motivo de este requisito.
Uso de la API	Generar un informe agregado a nivel de generateBid()	La agregación privada se puede invocar dentro de generateBid.
Macros	Enruta los indicadores de perBuyerSignals a través de macros en IFrames a terceros.	Estamos analizando este caso de uso aquí y agradecemos que nos envíes comentarios adicionales.
Uso de la API	Si la recuperación de indicadores de puntuación de confianza muestra un error, ¿se seguirá llamando a scoreAd()?	ScoreAd() aún debe ejecutarse si la llamada de recuperación no funciona correctamente.
Uso de la API	Se escriben metadata.shard_num en archivos riegeli para archivos delta/instantáneas.	Ahora mismo, agregamos compatibilidad con shard_num para desbloquearla. Riegeli no se adoptó tan bien como, por ejemplo, Avro, pero no se abandona. Como TEE tiene muchas más restricciones y sobrecarga, decidimos priorizar el rendimiento sobre la experiencia del usuario. Estamos considerando proporcionar un servicio de gRPC para crear archivos a partir de solicitudes. También es posible que evalúemos el impacto en el rendimiento de otros formatos, como Avro.
Pruebas de la API	¿Cómo admitirán las APIs de PA y de Measurement las pruebas de incrementalidad?	Privacy Sandbox no tiene una forma de medir la incrementalidad con una presubasta contrafáctica. Puedes usar el almacenamiento compartido y la agregación privada, pero el contrafáctico solo sería después de la subasta.
Uso de la API	¿El uso de biddingWasmHelperURL para actualizaciones diarias afecta el umbral de k-anonimato?	Dado que ya no se considera el k-anonimato para las actualizaciones de IG, se puede actualizar biddingWasmHelperURL sin afectar el umbral.
Uso de la API	¿Podemos recibir notificaciones de error de la API de PA?	Agradecemos los comentarios del ecosistema sobre qué tipo de notificación de error necesitarían para solucionar los problemas de la API de PA.
Tamaños de anuncios	Los tamaños de los anuncios no se ven en la subasta ni se pueden generar informes.	Estamos abordando el problema con esta solicitud de extracción.
Uso de la API	¿Se llama al extremo de actualización del IG para el IG si no participa en esta subasta?	Sí. La URL de actualización se llama para todos los IG de un propietario determinado, incluso si no ofertó en esa subasta en particular. Los únicos requisitos son los siguientes: - Se debe incluir al propietario en una subasta determinada (es decir, debe incluirse como comprador en AuctionConfig). - El interestGroup del propietario determinado no debe haberse actualizado en las últimas 24 horas.
Prebid en la API de PA	¿Qué versión de Prebid.js se requerirá para la fase de prueba?	Según nuestra documentación técnica, la versión debe ser >= 8.9.0.
Activación de datos de origen en la API de PA	¿Cómo pueden activar sus propios datos de origen para la definición y el uso de las IG?	Para esta tarea, puede utilizar "Delegación de permisos" y "grupos de interés negativos".
API de PA y etiquetado del servidor	¿Cómo funciona la API de PA con el etiquetado del servidor?	La etiqueta base del navegador del usuario deberá redireccionar la llamada a la API al resto de las etiquetas del servidor, lo que le permitiría registrar la llamada.
Prueba de Chrome (modo a/b)	¿Se espera que las SSP también pasen estas etiquetas en las solicitudes de ofertas de RTB? ¿De qué manera?	Sí, se espera que las etiquetas se pasen de la SSP a la DSP. Se recomienda que las entidades accedan a la etiqueta y compartan el valor sin modificar con los socios a través de esta extensión de dispositivo.
Almacenamiento y uso de datos	¿Tiene más información sobre cómo se almacenan los datos y dónde se transfieren?	No proporcionaremos orientación legal, sino más bien nuestro enfoque o pensamiento general sobre el almacenamiento de datos, la retención y otros problemas de privacidad. Consulta aquí las preguntas frecuentes sobre el cumplimiento en relación con la privacidad que podrían resultarte útiles.
Seguridad de las APIs	Inquietudes sobre código malicioso del cliente que manipula el valor de retorno de la función generateBid().	Analizamos el problema aquí y se incorporaron algunos de los comentarios a la propuesta de agregación privada.
Destino personalizado	Cuando usas llamadas de destino personalizado de reportEvent, ¿sabes si un origen de informes personalizado (no al comprador ni al vendedor) se prerregistró como parte de un IG en allowedReportingOrigins requiere que la DSP lo declare en reportWin utilizando registerAdBeacon?	No, no es necesario que se vuelva a registrar en reportWin y se puede usar directamente en reportEvent como se documenta aquí.
Restricciones de APIs	Tamaño de IG durante la creación y la actualización.	El tamaño de la actualización se actualizó a 1 MB, lo que coincide con el nuevo límite de 1 MB (desde 50 KB) para la creación de IG.
Restricciones de K-anon	K-anon para anuncios que contienen diferentes tamaños.	En diciembre de 2023, publicamos el valor del k-anonimato que indica que este proceso comenzará a verificar el tamaño del anuncio "en algún momento después de 2025". No existe una forma de excluir el tamaño porque puede ser un vector de seguimiento entre sitios, como se describe en la llamada de WICG del 11 de octubre.
Seguridad de las APIs	¿Puede un jugador malicioso falsificar el "nombre de host" de una página?	La API admite una subclave establecida para el nombre de host del editor. Dado que el navegador está estableciendo la clave, parece difícil eludir este mecanismo.
Uso de la API	No se deben recomendar las funciones ForDebuggingOnly para la producción.	Estamos a punto de confirmar al ecosistema que las funciones forDebuggingOnly no son adecuadas para nada más que la solución de problemas posteriores a 3PCD.
Se necesitan más herramientas de depuración	ForDebuggingOnly no es suficiente para comprender los problemas que pueden ocurrir antes de scoreAd().	Estamos recopilando más comentarios sobre esta brecha y agradecemos que nos envíes más comentarios aquí.
Grupos de interés permanentes con los que no se puede participar	Solicitud para permitir a los usuarios inhabilitar permanentemente la creación de IG especiales.	Nuestra estrategia ha sido no permitir que los usuarios inhabiliten la opción a nivel de IG, ya que la semántica no es comprensible para los usuarios como están las cosas.
Mejora la documentación	Usa el mismo uso de mayúsculas para el parámetro renderUrls en las especificaciones y en la explicación.	Agradecemos tus comentarios. Realizaremos un seguimiento para actualizar la documentación.
Compatibilidad con el acuerdo de Protected Audience	Solicitud de opciones adicionales para la Asistencia para acuerdos de Protected Audience.	Actualmente, el equipo de Chrome está evaluando qué podemos hacer para brindar asistencia a 3PCD.
Macros	Se necesita compatibilidad con macros para mantener el tamaño de los IG por debajo del tamaño máximo de IG.	Una actualización reciente de la explicación abordó esta solicitud de forma parcial.
API de ReportLoss a nivel del evento	Solicitud de la API de ReportLoss a nivel del evento.	Si bien los informes de pérdida a nivel del evento representan un riesgo de privacidad grave, creemos que los objetivos subyacentes de esta solicitud se pueden cumplir con las modificaciones adecuadas en la API de Private Aggregation. Enviaremos comentarios adicionales aquí.
Uso de la API	¿Cómo se comportan los métodos forDebuggingOnly si ninguna puntuación de las ofertas es mayor que 0?	Si la puntuación <= 0, entonces es una pérdida automática. Por lo tanto, se invocará reportAdSubastaloss.
Estandarización	No hay alineación entre los usuarios del valor de entrada/salida de la función generateBid() de la API de PA.	Recomendamos a todos los socios que plantean este problema (o uno similar) a IAB Tech Lab. Este grupo está trabajando específicamente en los estándares de la industria para APIs como Protected Audience.
Seguridad de las APIs	¿Qué datos de nuestros IG puede ver Google?	K-anonimaity se basa en sólidas protecciones de la privacidad para evitar que se filtren datos sensibles de los usuarios a alguna parte, incluido Google. Google también está desarrollando una implementación de terceros (Fastly) de esta capa para minimizar este riesgo.
Prueba de Chrome (modo a/b)	¿Se pueden excluir a los usuarios restringidos de “k-anon” de las pruebas?	Además, exponemos el estado del k-anonimato en los informes, como se explica aquí.
Seguridad de la marca	Respalda los casos de uso de seguridad de la marca en los que no se publican anuncios según la lista de palabras clave o sitios bloqueados.	Esos casos de uso de seguridad de la marca ya deberían ser posibles con la API de PA. Para que una campaña publicitaria se segmente de forma negativa para un conjunto de dominios, puede almacenar la lista de dominios bloqueados en el propio IG. Por ejemplo, puede usar un filtro Bloom si enumerar cada uno de ellos ocupa demasiado espacio. También pueden mostrar la decisión de permitir o rechazar desde su servidor de par clave-valor mediante una UDF que busque la respuesta según la combinación de la clave que identifica la campaña publicitaria y el nombre de dominio que se incluye en la solicitud de par clave-valor. La API de Protected Audience también permite que la SSP y la DSP pasen a la subasta cualquier información sobre el contexto de la página. Esto puede incluir, por ejemplo, una lista de palabras clave o temas sensibles en la página. La lógica de ofertas de la DSP puede comparar esta información con cualquier información almacenada sobre dónde no debería aparecer el anuncio y elegir no ofertar cuando corresponda. Agradecemos los comentarios del ecosistema sobre cualquier caso de uso específico que considere que no es posible.
Delegación de permisos	¿Cómo funciona la delegación de permisos?	Puedes encontrar documentación sobre la delegación de permisos aquí.
Solicitudes en lotes	Usa la solicitud POST para algunas URLs de la API de PA para admitir las solicitudes por lotes.	Apreciamos la propuesta y agradecemos los comentarios adicionales aquí.
Mejora la API	Campos que probablemente no se deberían utilizar (como X-fledge- bidding-signals-format-version).	Estamos analizando el problema y agradecemos que nos envíes comentarios aquí.
Mejora la API	Solicitud para transmitir el consentimiento del RGPD al proveedor externo de medición y publicación de anuncios.	Esta función es compatible con la API de reemplazo de macros obsoletaReplaceInURN, como se explica aquí.
Optimización de las creatividades dinámicas	¿Cómo Protected Audience admite la optimización de creatividades dinámicas?	Estamos analizando este caso de uso y compartimos las posibles soluciones aquí.
Mejora la API	Solicitud de URL de publicación de anuncios mediante servidor de terceros capaz de obtener el contexto de IG, principalmente, con el nombre de la IG correspondiente al IG que ganó la subasta.	Estas solicitudes pueden aumentar el riesgo de seguimiento para los usuarios. Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Seguridad de las APIs	Preocupación por que el tamaño de “IG blob” filtrará información sobre los IG que se seleccionaron.	Como se mencionó en la sección de consideraciones de privacidad de la explicación de la API de Chrome B&A, el tamaño del BLOB no depende de ninguna de las entradas a navigator.getInterestGroupAdSubastaData(). Solo empaqueta todos los IG en el dispositivo. Esto garantiza que el tamaño del BLOB sea relativamente coherente en una página y limita la capacidad de filtrar información entre sitios. Lo diseñamos de esta manera exactamente por esta razón.
Prueba de Chrome (modo a/b)	¿Cuál es la postura de las otras SSP con respecto a perder la primera carga con respecto a la configuración de cookies y pruebas facilitadas por Chrome?	No recibimos inquietudes significativas (aunque otros aceptaron esta situación), pero agradecemos los comentarios del ecosistema si se trata de un problema importante.
Compatibilidad con A/B Testing	Solicita asistencia para las pruebas A/B de la API de PA.	Analizamos esta solicitud en la reunión de WICG de noviembre y recibimos más comentarios aquí.
Tamaños de anuncios	¿Quién elige el tamaño para una subasta de Protected Audience?	Esta pregunta está respondida en estas Preguntas frecuentes.
Mejora la API	Solicita configurar el servicio de par clave-valor para aceptar la ruta /bidding-signals/v1/getvalues.	Agregamos prefijos de ruta de acceso de asistencia en esta solicitud de extracción.
Uso de la API	¿Cómo puede un publicador crear el IG con su código si se supone que está en la base del anunciante, de modo que este pueda ofertar por él?	Las respuestas deben provenir de algún socio de tecnología publicitaria, una DSP o SSP que desea participar en subastas de Protected Audience y crea una manera para que esos públicos provengan de una fuente externa. Analizamos esto con más detalle en este problema de GitHub.
Mejora la API	Solicitud de posibilidad de vincular IG negativo con anuncios de "Grupos de interés positivo".	Estamos considerando esta solicitud y compartimos una posible propuesta aquí sobre cómo respaldarla.
Cantidad de fragmentos	Solicita asistencia para pasar "shard_num support" en los metadatos.	A partir de estos comentarios, agregamos compatibilidad con shard_num.
Uso de la API	Solicitud de estimación de la sobrecarga de las claves en el servidor K/V.	Compartimos nuestras opiniones y agradecemos los comentarios adicionales aquí.
K‐anonimato	Solicitud de aclaración y mejora del nivel de detalle del contador de K-Anonimato.	Aquí encontrarás aclaraciones sobre el nivel de detalle del contador de K-Anonimato.
Depuración	Solicita mejorar las capacidades de depuración de la API de PA después de los cambios propuestos recientes a forDebuggingOnly.	Estamos analizando la solicitud y recibimos comentarios adicionales aquí.
Tamaño del anuncio	Solicita el tamaño del espacio publicitario como un indicador adicional de BTS.	Compartimos una propuesta para respaldar esta solicitud y recibimos más comentarios aquí.
Seguridad de las APIs	¿Es posible restringir el uso de "runAdAuction()" según un origen?	Compartimos una respuesta detallada aquí.
Duración de IG	Solicitud para extender la vida útil de los IG de 30 a 90 días.	Estamos considerando tu solicitud y agradecemos que nos envíes comentarios aquí.
Uso de la API	¿Es posible ejecutar una subasta de Protected Audience en paralelo con la oferta de encabezado y la llamada al servidor de anuncios del publicador?	Estamos analizando esta solicitud y agradecemos que nos envíes comentarios aquí.
Depuración	Solicitud de mejor asistencia para las extensiones de depuración de la API de Chrome PA que se comunican con Herramientas para desarrolladores.	Ayudamos a proporcionar más herramientas de depuración y agradecemos las sugerencias adicionales aquí.
Uso de la API	Las notificaciones de pérdidas no se activan si ninguna oferta de los vendedores de componentes llega al más vendido.	Aquí explicamos los motivos de este proceso.
Mejora la API	Solicitud de compatibilidad de TextEncoder en el trabajo de ofertas de Protected Audience.	Estamos considerando esta solicitud y agradecemos que nos envíes comentarios adicionales aquí.
Uso de la API	Las llamadas de red y la lógica de ejecución en el cliente pueden bloquear el subproceso principal y causar desafíos de ejecución de JS que pueden afectar la SEO.	Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Uso de la API	¿Es posible que las DSP usen su embudo actual de ofertas del servidor para evaluar y enviar a los candidatos de anuncios como parte de perBuyerSignal para que se utilicen en las subastas integradas en el dispositivo?	Estamos debatiendo esta pregunta y agradecemos que nos envíes comentarios aquí.
Amplíe los datos de oportunidades de oferta	Solicitud para extender los datos de la oportunidad de oferta pasados por el navegador a la SSP con una lista de dominios de origen únicos de los IG activos en el navegador.	Estamos analizando esta solicitud y agradecemos que nos envíes comentarios aquí.
OTB	Se solicitaron dos hooks nuevos para AuctionConfig y la adaptación de respuesta generateBid en ORTB.	Estamos revisando el problema y nos gustaría recibir más comentarios aquí.
Victoria anterior	La solicitud de IG define un prevWinsTransformer, que toma las victorias anteriores de IG y genera un resultado serializable.	Estamos revisando el problema y nos gustaría recibir más comentarios aquí.
Tipos de contenido	Estrategia para la evolución de los tipos de contenido; p.ej., de JSON a algo como CBOR.	Estamos revisando el problema y nos gustaría recibir más comentarios aquí.
Prebid en la API de Protected Audience	Solicitud de una página del publicador de muestra que use Prebid para ejecutar un flujo de extremo a extremo en la subasta de Protected Audience.	Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema sobre los motivos por los que se debería priorizar esta opción. También observamos a participantes del ecosistema que producen páginas de publicadores de muestra que están disponibles para que otros miembros del ecosistema puedan realizar demostraciones.

Servicios de subasta protegidos

Tema de los comentarios	Resumen	Respuesta de Chrome
Entornos de ejecución confiables (TEE)	¿Es más costoso ejecutar entornos de ejecución confiables en nubes públicas que en los centros de datos de tecnología publicitaria locales?	Nuestro modelo de seguridad TEE actual se beneficia de las prácticas de las implementaciones de nubes públicas. En particular, los TEE actuales basados en hardware no defienden todos los ataques físicos. Nuestros proveedores de servicios en la nube pública admitidos, AWS y GCP, diseñaron e implementaron mitigaciones para los riesgos de acceso físico, incluidos los de los empleados. Consulta más detalles a continuación sobre la asistencia local. Las tecnologías publicitarias nos mencionaron que ejecutar servicios en la nube es más costoso que los centros de datos de tecnología publicitaria locales. Si bien no podemos evaluar estas afirmaciones, agradecemos que nos envíes comentarios adicionales sobre los costos y seguimos evaluando opciones para ampliar nuestra asistencia a los equipos de TEE.
(Se informaron en trimestres anteriores) TEE local	¿Cuáles son los requisitos para que alguien se convierta en un proveedor de TEE?	Nuestra respuesta es similar a la de los trimestres anteriores: “Si bien seguimos explorando la compatibilidad con otras opciones más allá de las soluciones basadas en la nube pública, incluida la consideración de qué implementaciones serían aceptables desde una perspectiva de seguridad, actualmente no tenemos planes de admitir TEE locales. En esta etapa, dados los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que seguir expandiendo y mejorando las implementaciones basadas en la nube es lo más beneficioso para el ecosistema. Sin embargo, recibiremos comentarios adicionales sobre por qué un requisito de este tipo es necesario y factible dadas las restricciones de privacidad y seguridad".
Límites del servidor de par clave-valor	Límites de claves por subasta por servidor	Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Restricciones de K-anon	Confirmación de que no se aplicará de manera forzosa el K-anonimato en las claves K/V en el futuro.	Actualmente, no tenemos planes de aplicar k-anon en las claves de las solicitudes del servidor K/V, ya que nuestro objetivo es trasladar los servidores de K/V a TEE en el futuro.
Creación de un servicio de audio y video	¿Google tiene disponibles artefactos compilados previamente para el servicio de audio y video?	Por el momento, no tenemos artefactos compilados previamente para el servidor de par clave-valor de Protected Audience, aunque podríamos considerar proporcionarlos si observamos una alta demanda del ecosistema sobre ellos.
Compatibilidad de EgId en B&A	Solicitud para admitir el campo experimentGroupId en el código de ofertas y subastas y en la solicitud al servicio KeyValue de BuyerFrontEnd	Por el momento, B&A no es compatible con experimentGroupId, pero pretende lanzarlo en la versión beta 2 (actualmente programado para febrero de 2024). Compartimos información adicional aquí.
Uso de la API	La fusión de solicitudes en HTTP puede ayudar a brindar protección contra atacantes en la ruta, pero el operador del TEE aprenderá sobre los tamaños.	Estamos analizando esta solicitud y agradecemos que nos envíes comentarios aquí.
Mejora la documentación	La especificación no es clara como se abordará el servidor k-v.	Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Uso de la API	¿Cuál es el propósito de "Ad-Auction-Result" y adAuctionHeaders?	Estamos analizando este problema aquí y agradecemos que nos envíes comentarios adicionales.
Mejora la documentación	No está claro si el diseño de la v2 se propaga en FLEDGE.md.	FLEDGE.md habla sobre cómo Chrome envía solicitudes a BYOS-KV. El diseño del protocolo v2 se limita solo a TEE-KV y, por el momento, no es compatible con Chrome.

Medición de anuncios digitales

Attribution Reporting (y otras APIs)

Tema de los comentarios	Resumen	Respuesta de Chrome
Medición multientorno	¿Cómo planea Chrome admitir la medición multientorno en la fase provisional, en la que se quitaron las 3PC de Chrome para dispositivos móviles, pero Privacy Sandbox para Android aún no está disponible?	En el caso de Android, estamos trabajando para expandir la cobertura de PSB/ARA. La API de Attribution Reporting (ARA) está disponible en Android 13 y 14, y planeamos expandir la cobertura a Android 11 y 12 más adelante este año, aunque esto está sujeto a cambios. No podremos expandirnos a Android 10 ni versiones anteriores, pero esperamos que el porcentaje de dispositivos con Android 10 o versiones anteriores sea menor con 3PCD y que disminuya naturalmente con el tiempo a medida que los usuarios se actualicen. Recibirás comentarios adicionales del ecosistema sobre esta solicitud.
Filtros	Filtrado de "conversiones" del análisis de creatividades.	Nos comunicamos con esta parte interesada para comprender mejor su solicitud y recibimos con gusto comentarios adicionales del ecosistema sobre este tema.
Servidores de publicidad de terceros	¿Cómo funcionarán la API de PA y la ARA con las etiquetas del servidor de anuncios de terceros?	De manera similar a cómo funcionan los píxeles con las etiquetas de impresión y clic en la actualidad, un servidor de anuncios puede establecer registros fuente y activadores para la ARA por su cuenta (incluidas las subastas de Protected Audience), o bien configurar redireccionamientos para pasar y aceptar registros de fuentes y activadores de la ARA.
DCM	Es compatible con la Attributionsrc de DCM y otros servidores de anuncios de terceros.	Este es un problema relacionado con DCM y el equipo de DCM lo solucionó en este problema de GitHub.
Clave de agregación jerárquica	¿Es necesario dividir todo el presupuesto de contribuciones en todas estas claves jerárquicas?	Hemos discutido y dado una respuesta a este interesado. Cuando se usa una estructura de claves jerárquica, la tecnología publicitaria debe tener en cuenta que el presupuesto de contribución se comparte entre todos los resultados clave de una impresión.
Utilizar distintos subdominios	¿Deseas hacer que los informes de atribución funcionen con fuentes y activadores registrados en diferentes subdominios, pero el mismo eTLD+1?	Analizamos esta pregunta con la parte interesada y propusimos las siguientes soluciones. Pueden cambiar la configuración de su URL para que tenga el mismo origen de informes en la fuente y el activador, o bien redireccionar de su URL actual a una común antes de realizar el registro. Estamos dispuestos a recibir comentarios adicionales sobre el ecosistema si las soluciones propuestas no funcionan para su caso de uso.
(También se informó en trimestres anteriores) Asistencia de producción	¿Qué niveles de servicio están disponibles para ayudar a los socios que usan la ARA?	Nuestra respuesta no cambió en comparación con trimestres anteriores: "Google ofrece una variedad de canales para que las tecnologías publicitarias informen problemas técnicos y permitan las derivaciones necesarias para resolverlos. Además, Chrome espera desarrollar y escalar más un proceso para resolver problemas técnicos y derivaciones que afecten el estado del ecosistema. Chrome tiene el compromiso de garantizar recursos para este esfuerzo. Consulta nuestra publicación para desarrolladores a fin de obtener más información sobre los foros públicos y privados para obtener comentarios y derivaciones”.
(También se informó en trimestres anteriores) Cronograma	¿Google tendrá lista la "Fase 2, completamente flexible y a nivel del evento" al comienzo de las pruebas cuantitativas de la CMA?	Se espera que la Fase 2 completamente flexible a nivel del evento esté disponible en Chrome durante el primer trimestre de 2024. Puedes hacer un seguimiento del estado aquí.
(También se informó en trimestres anteriores) Embudo de conversión	Informa sobre varios dominios que se usaron en las conversiones.	Este caso de uso es posible porque se agregaron varios destinos. Agradecemos que nos envíes comentarios adicionales.
Informes de etiquetas de prueba	¿Las capacidades de generación de informes permitirán a los verificadores informar de qué grupo forma parte el usuario (navegador Chrome) (modo A/B)?	Estamos trabajando para publicar una guía de prueba para capturar etiquetas de prueba de Chrome en ARA.
Documentación	En la documentación de Attribution-Reporting-Register-Source, se indica que el vencimiento se redondeará al día más cercano. ¿Cómo se redondeará?	Si se redondea al día más cercano, 1.5 días se redondearán a 2 días.
Utilizar distintos subdominios	Solicita recibir informes de la API de Attribution Reporting en un subdominio diferente como registro de la fuente y del activador.	No es posible. Se pueden aplicar redireccionamientos HTTP, pero no hay configuración para esto. Agradecemos los comentarios adicionales del ecosistema sobre los motivos por los que es útil esta solicitud.
Retraso de los informes a nivel del evento	La atribución y la ventana de informes de 7 días, pero, debido a una demora en los informes a nivel del evento, es posible que la generación de todos los informes demore más de 8 días.	Aceptamos los comentarios y agradecemos los comentarios adicionales del ecosistema sobre si esta demora en los informes a nivel de evento es un problema o no, en especial con el cambio de las ventanas de informes de eventos fijas a las flexibles.
Activadores de conversiones	Los activadores de conversiones que ocurran entre el final del primer event_report_window (1 h) y la hora de vencimiento (1 día) no generarán informes.	Presentamos una configuración flexible a nivel del evento que pasa de ventanas fijas a flexibles de informes de eventos.
Ruido	¿Los informes a nivel del evento son una conversión falsa con ruido, como se describe en la explicación de GitHub?	Sí, el ruido se aplica a los informes a nivel del evento y representa todos los estados de salida posibles, incluidos los diferentes datos del activador, no informa nada cuando ocurrió un activador o informa potencialmente varios informes falsos para el evento. El porcentaje de ruido es de código abierto y puede ser flexible a través de configuraciones flexibles a nivel del evento.
Filtros	Si usas el filtrado con la API de Attribution Reporting, se consumiría el presupuesto de contribución aunque no se registre la clave de agregación.	Esto funciona según lo previsto, ya que aggregatable_trigger_data solo admite el filtrado en las partes de la clave del activador, no en los valores o las claves. Los filtros de nivel superior pueden admitir el filtrado de las claves en sí, pero esto se comparte por evento y por agregado, por lo que no es aplicable aquí. Si es necesario filtrar las claves, agradecemos que envíes comentarios adicionales del ecosistema aquí.
Límite de almacenamiento	Solicitud para ingresar un límite de almacenamiento que también tenga en cuenta el origen de los informes.	A partir de la versión M120, entrará en vigencia un aumento de 1,024 a 4,096 de este límite. Aquí recibimos comentarios adicionales del ecosistema.
Atribución directa	¿Cómo obtener métricas para situaciones en las que un usuario visita a un anunciante directamente sin pasar por un publicador, ya que el proceso estándar de generación de informes de atribución no abarca esta situación?	La ARA solo está diseñada para recuperar información entre sitios (es decir, la unión de información en sitios de publicadores o anunciantes). Si no se requiere información entre sitios, la ARA no te ayudará. Estamos analizando el problema y nos gustaría recibir más comentarios aquí.
Hora del informe	Obtén scheduled_report_time la hora de un servidor de tiempo en lugar de usar la hora de la máquina local.	Actualmente, no tenemos planes de usar un servidor de tiempo y no hemos recibido mucha demanda por parte de la tecnología publicitaria. Nos interesaría recibir comentarios adicionales del ecosistema sobre si esta sería una función útil.

Servicio de agregación

Tema de los comentarios	Resumen	Respuesta de Chrome
(También se informó en trimestres anteriores) Solución local	¿Puede implementarse el servicio de agregación en centros de datos locales?	Si bien estamos explorando opciones potencialmente de respaldo más allá de las soluciones basadas en la nube, actualmente no es factible admitir TEE locales dadas las limitaciones de seguridad locales que requerirían una evaluación lenta para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que seguir expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, puedes recibir comentarios adicionales aquí sobre los motivos por los que ese requisito es necesario.
Enclave	Si el enclave no está activo o recibe un error de repente, ¿cómo lo maneja la API de Aggregation Service?	Usaremos reintentos si el enclave falla durante el inicio y ajuste de escala automático para mostrar nuevas instancias si una instancia se considera en mal estado. Las AdTech también pueden investigar fallas mediante registros. Para depurar fallas de enclaves en AWS, las tecnologías publicitarias pueden verificar el estado de su instancia de EC2 accediendo a su AWS Console Manager. Las tecnologías publicitarias también pueden acceder a la instancia de host de Nitro Enclave y verificar su estado con la herramienta nitro-cli. Si hay algún error o falla, puede usar la interfaz de línea de comandos de AWS para ver los registros e investigar más. Para depurar fallas de enclaves en GCP, las AdTech pueden verificar el estado de sus instancias a través de Cloud Console. También pueden verificar si hay errores con el list-errors-command.
Utilizar distintos subdominios	Solicitud de registro de varios (sub)dominios para usar varias instancias de servicios de agregación, tanto en entornos de desarrollo como de producción.	Se lanzó la inscripción del sitio para que las plataformas de tecnología publicitaria puedan registrar varios subdominios del mismo sitio en una cuenta de AWS o un proyecto de GCP. También podrán registrar el mismo dominio en varias cuentas de AWS o proyectos de GCP. Agradecemos los comentarios del ecosistema.
Presupuesto de privacidad	¿Cómo depurar mejor los problemas relacionados con el agotamiento del presupuesto de privacidad?	Actualmente, estamos buscando soluciones para brindar más detalles sobre el presupuesto agotado y, además, mejorar nuestra documentación para describir las estrategias que las AdTech pueden usar a fin de minimizar los casos de este error. Actualizaremos la página de GitHub del servicio de agregación cuando tengamos una propuesta.
Valor de Épsilon	Solicitud para aumentar el valor de épsilon.	El valor de épsilon del servicio de agregación se mantendrá como un rango de hasta 64 para facilitar la experimentación y los comentarios sobre diferentes parámetros durante 3PCD. Proporcionaremos un aviso anticipado al ecosistema antes de que se actualicen los valores del rango de épsilon.
Objetos binarios	Publica un conjunto más completo de objetos binarios para las versiones del servicio de agregación.	Estamos revisando esta solicitud y te damos la bienvenida a los comentarios adicionales.
Uso de la API	Compartir datos con los coordinadores, según las Condiciones del servicio del coordinador.	Necesitamos aclaraciones sobre este tema y te agradecemos que nos envíes comentarios adicionales.

API de Private Aggregation

Tema de los comentarios	Resumen	Respuesta de Chrome
Depuración	Habilita opciones adicionales para la depuración durante la prueba del modo B.	Como se indica en este problema de GitHub, avanzaremos en la habilitación del modo de depuración en el modo B. Esta elegibilidad cambiará en la versión beta M121 con el 50% del tráfico del modo B a partir del 31/1. Te avisaremos antes de pasar a la versión estable.

Limita el seguimiento encubierto

Reducción de usuario-agente/Sugerencias de clientes de usuario-agente

Tema de los comentarios	Resumen	Respuesta de Chrome
ChromeOS	Se agregó compatibilidad con User-Agent Client Hints para la cantidad de bits de ChromeOS.	Compartimos la respuesta a esta solicitud aquí.

Protección de IP (anteriormente Gnatcatcher)

Tema de los comentarios	Resumen	Respuesta de Chrome
Abuso	Es posible que Google pueda ver los datos de navegación del usuario mediante la protección de IP.	La protección de IP envía el tráfico a través de dos proxies (uno ejecutado por Google y otro por otra empresa). Esto garantiza que Google no pueda ver los datos de navegación. Todo el tráfico se encripta entre Chrome y los proxies, por lo que el proxy de Google no tiene información sobre los sitios web que se exploran. Además, el sistema utiliza tokens de autenticación cegados para minimizar el acceso a los identificadores de usuario en los proxies. Todo lo que el proxy de Google verá es que un cliente desconocido en una IP específica está usando el sistema proxy. No hay información disponible sobre los sitios web visitados ni sobre los anuncios cargados.
Compatibilidad con el modo sin interfaz gráfica	¿Cómo se administrarán los bots que usan complementos y el modo sin interfaz gráfica?	Mitigar el abuso de la protección de IP es una prioridad clave para el equipo. Consideramos cuidadosamente estas situaciones (entre muchas otras posibles amenazas también) y estamos trabajando en opciones que ayudarán a reducir la probabilidad de abuso o fraude. Si bien por el momento no podemos brindar más detalles, esperamos hacerlo próximamente, así como continuar la conversación.
Proxies existentes	¿Cómo funcionará la protección de IP con la configuración de proxy existente en Chrome?	Las configuraciones de proxy existentes seguirán siendo compatibles. Los usuarios podrán configurar sus propios proxies personalizados como antes.
Denuncia de abusos	¿Cómo se abordarán las denuncias de abuso?	Tendremos más detalles próximamente, pero planeamos tener un mecanismo para que las organizaciones y los usuarios compartan denuncias y pruebas de abuso.
Reglamentaciones	¿Cómo cumplirá la protección de IP las leyes y reglamentaciones locales?	Google se compromete a satisfacer las leyes y reglamentaciones locales, y no se permite eludir estos bloqueos a nivel de país. Esta función no está diseñada para eludir.
Limitación de capacidades	¿La protección de IP bloqueará nuestra respuesta cibernética?	Nos esforzamos por lograr un equilibrio entre proteger a los usuarios contra el rastreo en toda la Web en función de sus direcciones IP y, al mismo tiempo, minimizar las interrupciones en el funcionamiento normal de los servidores, incluido el uso de direcciones IP para combatir el abuso. Si bien por el momento no podemos brindar más detalles, esperamos hacerlo próximamente, así como continuar la conversación.
Cronograma	Si esto se va a aplicar antes de finales de 2024, será casi imposible prepararse para ello.	Inicialmente, Chrome lanzará la protección de IP como un parámetro de configuración opcional para los usuarios de regiones específicas, entendiendo que esto podría representar un cambio significativo en la manera en que algunas empresas dependen de las direcciones IP, y buscará minimizar las interrupciones a medida que se ajuste el ecosistema. La protección de IP pasará al valor predeterminado no antes de 2025.
Uso de la API	¿El usuario tendrá la opción de activar o desactivar la protección de IP la primera vez que abra Chrome?	Planeamos ofrecer a los usuarios la opción de elegir si desean usar o no la protección de IP. La mecánica para presentar esta opción a los usuarios aún se está desarrollando.
Uso de la API	¿Cuántos datos se registran y por cuánto tiempo se retienen?	Tendremos más detalles para compartir en el futuro, pero planeamos registrar cantidades mínimas de datos.
Comentarios negativos	Los usuarios pueden utilizar las VPN si prefieren usarlas. No se necesitan APIs de PS.	El objetivo de la protección de IP es evitar el uso de direcciones IP para el seguimiento entre sitios, pero no está pensada para ser un servicio de VPN.
Seguridad de las APIs	¿Cómo impedir que los datos de origen accedan a la dirección IP y reenvíen la información a través del parámetro del encabezado?	Inicialmente, nos estamos enfocando en los terceros porque observamos que son los que tienen el mayor impacto. Seguiremos supervisando el ecosistema para determinar si necesitamos mejorar nuestro enfoque para evitar la elusión a gran escala.
Uso de la API	Se requiere confirmación si la comprensión del uso de la API es correcta.	La protección de IP usa un enfoque basado en listas para identificar qué tráfico de terceros pasa por los proxies. Los orígenes que están en la lista, pero a los que se accede en un contexto propio, no se enviarán a través de este servicio para esas conexiones. Por ejemplo, si una empresa de estadísticas está en la lista de dominios y un usuario navega directamente al sitio, ese sitio podrá seguir observando la dirección IP del usuario en lugar de la dirección IP con proxy. Sin embargo, si el dominio de la lista realiza una solicitud de red en un contexto de terceros, la conexión se enviará al proxy y el sitio no podrá ver la dirección IP original del usuario. Nuestro objetivo final es evitar el seguimiento entre sitios de los usuarios de toda la Web. Estamos trabajando en algunos detalles antes de compartir más información sobre los dominios de terceros en los que planeamos enfocarnos inicialmente.
VPN	Le preocupa que la propuesta de Google pueda ser desfavorable para otros proveedores de VPN.	El objetivo de la protección de IP es evitar el uso de direcciones IP para el seguimiento entre sitios, pero no está pensada para ser un servicio de VPN.
Cronograma	¿Cuál es el cronograma de la protección de IP?	La protección de IP se habilitará inicialmente. Esto ayudará a garantizar que el usuario controle las decisiones de privacidad y que Google pueda supervisar los comportamientos en volúmenes más bajos. La protección de IP se lanzará en etapas y pasará a la configuración predeterminada a partir de 2025. Al igual que con todas nuestras propuestas de privacidad, queremos asegurarnos de aprender sobre la marcha y reconocer que también puede haber consideraciones regionales para evaluar. Utilizamos un enfoque basado en listas y solo se verán afectados los dominios que figuran en la lista en un contexto de terceros. Sabemos que estas propuestas pueden causar interrupciones no deseadas en casos de uso legítimos, por lo que solo nos enfocamos en las secuencias de comandos y los dominios que se considera que realizan un seguimiento de los usuarios.
Limitación de capacidades	Ya no se pueden buscar las direcciones IP de los usuarios en WHOIS.	Nuestra posición es que la dirección IP es un identificador estable cuyo uso puede afectar la privacidad de los usuarios, lo que incluye el uso de metadatos asociados con ella, como ASN. Con la protección de IP, estamos tratando de lograr el equilibrio adecuado entre la privacidad y ofrecer una experiencia del usuario útil en la Web, por ejemplo, con nuestro enfoque sobre la ubicación geográfica de IP. Si estos metadatos no son suficientes para tu caso de uso, podemos tratar ese tema en más detalle.
URL de referencia HTTP	¿Se conservará el URL de referencia HTTP original?	No hay planes para modificar el encabezado de referencia como parte de la protección de IP, como se explica aquí.
Código abierto	¿Los códigos fuente de protección de IP serán de código abierto?	La mayor parte de este software es de código abierto como parte de los proyectos de Chromium y Envoy Proxy, pero algunos componentes son de código cerrado, como se explica aquí.

Mitigación del seguimiento por rebote

Tema de los comentarios	Resumen	Respuesta de Chrome
Eliminación de almacenamiento	¿La mitigación del seguimiento por rebote (BTM) borra el almacenamiento compartido y el de Attribution Reporting?	No teníamos la intención de que BTM borrara el almacenamiento de la API de Privacy Sandbox (ARA, API de PA, almacenamiento compartido, agregación privada, Topics). BTM solo debe borrar los tipos de almacenamiento que tengan riesgos de privacidad si se accede a ellos en un contexto de terceros. Hay una corrección de errores en curso.
Uso de la API	¿Qué versión de Chrome se activará BTM? ¿El seguimiento de redireccionamiento o rebote después de 10 segundos se considerará como seguimiento por rebote por BTM o no?	En M116, BTM se lanzó para el 100% de los usuarios con las 3PC bloqueadas. Actualmente, un redireccionamiento después de 10 segundos no se considera un rebote.
Caso de uso de acceso	¿Deseas sincronizar y mantener automáticamente el estado de acceso en varios dominios, sin recibir penalizaciones por comportamientos similares a los de seguimiento?	Estamos analizando esta solicitud aquí y agradecemos que nos envíes comentarios adicionales del ecosistema.
Recorrido del usuario	Actualmente, la BTM trae como resultado recorridos del usuario complicados.	Estamos analizando el problema y compartimos nuestras opiniones al respecto aquí.
API de Storage Access	BTM en Chromium respetará los subsidios de 3PC de la API de acceso al almacenamiento (SAA).	Analizamos este problema con los participantes del ecosistema en TPAC 2023 y recibimos más comentarios aquí.
Impacto en los informes de anuncios	La mitigación del seguimiento por rebote puede hacer que las empresas más pequeñas del ecosistema dependan de otras APIs de Privacy Sandbox, como la ARA, para llevar a cabo casos de uso de anuncios.	Las mitigaciones de seguimiento por rebote están diseñadas para evitar la elusión de las políticas de terceros. La ARA es una de las muchas soluciones de medición alternativas que las empresas tendrán disponibles después de 3PCD, pero ninguna empresa está obligada a utilizarla.

Presupuesto de privacidad

No se proporcionaron comentarios para este trimestre.

Fortalece los límites de privacidad entre sitios

Conjuntos de sitios web relacionados (anteriormente, conjuntos propios)

Tema de los comentarios	Resumen	Respuesta de Chrome
(También se informó en trimestres anteriores) Límite de dominios de conjuntos de sitios web relacionados (RWS)	Solicitud para expandir la cantidad de dominios asociados.	En este momento, no esperamos aumentar el límite numérico. El límite se estableció en función de consideraciones de privacidad del usuario, los comentarios de las partes interesadas del ecosistema en el W3C y la consideración de implementaciones comparables en otros navegadores. Para obtener más información, consulta las entradas de nuestro blog (1, 2). Te recomendamos examinar los casos de uso que requieran acceso a cookies entre sitios más allá del límite numérico y que consideres aprovechar nuestra guía para los casos de uso de identidad, las incorporaciones autenticadas y los casos de uso de publicidad.
Alcance del acceso de cookies	Preocupación por que todos los dominios de un RWS tengan acceso de lectura y escritura a todas las cookies de todos los dominios.	La pertenencia a un RWS no implica que los miembros puedan acceder a las cookies de los demás. En su lugar, esto permitiría a los miembros acceder a sus propias cookies cuando se incorporen en otros sitios del mismo tipo RWS (después de una invocación a la API de Storage Access).
(También se informó en trimestres anteriores) Integración de RWS y CHIPS	Solicitud de integración de RWS y CHIPS para admitir casos de uso como pruebas A/B	Seguimos solicitando casos de uso y solicitudes relacionadas con esta función aquí. Por el momento, estamos sopesando la necesidad de esta función con los riesgos de interoperabilidad entre navegadores.
Uso de la API	¿Qué sucede si un usuario quita sitios de forma manual de su configuración de Chrome de forma local?	Actualmente, no tenemos forma de que un usuario borre manualmente un sitio de un grupo. En su lugar, el usuario puede desactivar la función "sitios relacionados" con el botón de activación que se encuentra debajo de "Bloquear cookies de terceros" o "Bloquear todas las cookies de terceros" en el nuevo panel de configuración de Protección contra seguimiento.
Comunicación entre dominios	¿Permitirá RWS la comunicación entre dominios?	En este momento, estamos ejecutando una prueba de origen para ampliar el acceso a algunos tipos de almacenamiento no particionado (incluidos localStorage y el canal de transmisión) a través de la API de Storage Access que habilitará esta comunicación. Esta función está disponible en todas las configuraciones admitidas de la API de Storage Access, en el mismo RWS y también en sitios que no son de RWS. Esta entrada de blog contiene información adicional.
requestStorageAccessFor	¿Puede document.requestStorageAccessFor(origin) mostrar una promesa que se resuelve con las cookies entre sitios del origen?	No es posible. Dado que la invocación ocurre desde el origen de nivel superior (que es diferente del origen que se pasó como argumento), esta acción infringe la Política del mismo origen.

API de Fenced Frames

Tema de los comentarios	Resumen	Respuesta de Chrome
(También se informó en trimestres anteriores) Publicidad nativa	Compatibilidad con marcos cercados para la publicidad nativa.	Anteriormente, compartimos que se requerirán algunas tecnologías de Privacy Sandbox para fortalecer aún más la protección de la privacidad. Por ejemplo, en el caso de Protected Audience, exigiremos el uso de marcos vallados para la renderización de anuncios y dejaremos de lado los informes a nivel del evento a partir de 2026. Proporcionamos fechas “no antes de” para cada uno de estos requisitos futuros, de modo que la industria tiene claridad sobre la evolución prevista de las APIs. Este tiempo adicional nos permite seguir trabajando con la industria para diseñar e implementar la asistencia para una gama más amplia de casos de uso fundamentales. Por ejemplo, mejoraremos la función Fenced Frames antes de su requisito a partir de 2026 a fin de mantener la compatibilidad con los anuncios nativos y de video con la API de Protected Audience. De acuerdo con nuestros Compromisos, se consultará a la CMA sobre esos cambios y seguiremos colaborando con los comentarios del ecosistema antes de implementar esos requisitos “no antes de”.
Diferencia de tamaño entre plataformas	Informa que el tamaño del contenido que se muestra en el Marco cercado tiene un aspecto diferente en computadoras de escritorio y smartphones.	Estamos investigando el problema y agradecemos que nos envíes comentarios aquí.
Cómo renderizar adComponent	¿Quieres proporcionar códigos de muestra para renderizar adComponents en marco cercado?	Buscaremos proporcionar documentación sobre cómo usar navigator.adSubastaComponents(numComponents) dentro del marco vallado para mostrar un anuncio compuesto por varias partes.
Mejora la API	Proporciona más indicadores a FencedFrames (mejora, p.ej., la seguridad de la marca).	Apreciamos la propuesta y agradecemos los comentarios adicionales aquí.

API de Shared Storage

Tema de los comentarios	Resumen	Respuesta de Chrome
Caso de uso de protección contra el abuso y el fraude	Posibilidad de usar el almacenamiento compartido para la detección de fraudes o anomalías.	Analizamos la posibilidad aquí y recibimos más comentarios al respecto.
Limitación de frecuencia	Proporciona un método para la limitación de frecuencia entre sitios fuera de la API de PA.	Agradecemos los comentarios que indican que la limitación de frecuencia entre sitios fuera de la API de PA es un caso de uso valioso. En este momento, Privacy Sandbox sigue enfocado en su conjunto actual de APIs para 3PCD. Sin embargo, aceptamos comentarios adicionales del ecosistema sobre este caso de uso aquí.

CHIP

Tema de los comentarios	Resumen	Respuesta de Chrome
Ventanas emergentes/redireccionamientos	¿Cómo admitirán los CHIP los casos de uso de autenticación incorporada que involucren ventanas emergentes y redireccionamientos?	Recientemente, compartimos orientación sobre cómo comprobar el impacto de la eliminación gradual de las 3PC en el flujo de trabajo de acceso y agradecemos los comentarios adicionales aquí.
Límite de particiones	Reduce el límite general por sitio y por partición a 1 KiB.	Estamos considerando esta solicitud y agradecemos que nos envíes comentarios adicionales aquí. Seguiremos supervisando los comentarios a medida que implementamos 3PCD y los desarrolladores adoptan los CHIP y brindan comentarios.
Migración de cookies	¿Es un proceso recomendado para migrar una aplicación web de modo que emita cookies como particionadas que no interrumpan las cookies o sesiones en curso?	En nuestra respuesta propusimos un posible esquema para la migración, pero el desarrollador pudo formular una solución alternativa que funcionara mejor para su configuración.
Uso de la API	¿Se inhabilita el acceso al almacenamiento particionado cuando un usuario no habilita el parámetro de configuración de las APIs de privacidad en los anuncios?	El almacenamiento particionado y las cookies particionadas (CHIP) se habilitan incluso si un usuario no habilita el parámetro de configuración de las APIs de privacidad en los anuncios, ya que no habilitan ninguna transferencia de información entre sitios. Como principio general, la transferencia de información entre sitios estará sujeta a límites, verificaciones o participación del usuario; pero, por el momento, no se aplican a CHIPS.
Uso de la API	¿Cuál es el motivo por el cual finalmente se bloquean las cookies no particionadas, en lugar de que el navegador las particionara de forma “silenciosa”?	Esto no es posible a corto y mediano plazo, como se explica aquí.

FedCM

Tema de los comentarios	Resumen	Respuesta de Chrome
Uso de la API	No se puede entregar un "archivo conocido" en eTLD+1 dentro del entorno de desarrollo.	Se actualizó Chrome Canary para que no se recupere la versión más conocida, como se explica aquí.
Uso de la API	¿Hay algún requisito específico de interacción del usuario definido para solicitar permisos de acceso de terceros o usar FedCM?	No hay requisitos específicos de interacción del usuario, como se explica aquí.
Seguridad de las APIs	¿Hay algún plan para tener un flujo que permita al cliente iniciar FedCM, pero, básicamente, los tokens se transfieren del IdP a un sistema de backend del RP?	Estamos analizando el problema y agradecemos que nos envíes comentarios adicionales aquí.
Habilitada	Permite que el IdP acepte recibir el ID de cliente del RP para que los usuarios puedan decidir si confían en el IdP o no.	Estamos analizando esta solicitud y agradecemos que nos envíes comentarios aquí.
Uso de la API	Solicitud de más documentación sobre FedCM.	Reconocemos estos comentarios y seguiremos mejorando la documentación a medida que seguimos desarrollando esta API.

Combate el spam y el fraude

API de Private State Token (y otras APIs)

Tema de los comentarios	Resumen	Respuesta de Chrome
Documentación	Solicita una guía detallada para desarrolladores sobre los tokens de estado privado para obtener asistencia con las pruebas.	En el 4o trim. de 2023, publicamos una guía para desarrolladores sobre los tokens de estado privado.
Verificación de edad o género	Es difícil realizar la verificación de "edad y género" de los públicos después de la 3PCD.	Actualmente, los tokens de estado privado no están diseñados para la verificación de edad ni género. Queremos comprender mejor el caso de uso y cómo se logra hoy, por lo que agradecemos que nos envíes comentarios adicionales.