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

Informe de comentarios: cuarto trimestre de 2024

Informe trimestral del cuarto trimestre de 2024 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.

Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.

Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se agrega la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas comunes de los comentarios, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que aparecían en los equipos internos de Google y los formularios públicos.

Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones individuales con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios públicos. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.

Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de preguntas frecuentes publicadas, respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. En función del enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las tecnologías y las APIs de Topics, la API de PA y los informes de atribución.

Es posible que los comentarios recibidos recientemente aún no tengan una respuesta considerada por Chrome.

Glosario de acrónimos

ARA: API de Attribution Reporting
CHIPS: Cookies con estado particionado independiente
DSP: Plataforma orientada a la demanda
FedCM: Administración de credenciales federadas
IAB: Interactive Advertising Bureau
IDP: Proveedor de identidad
IETF: Internet Engineering Task Force
IP: Dirección de protocolo de Internet
openRTB: Licitaciones en tiempo real
TS: Prueba de Origin
API de PA: API de Protected Audience (antes conocida como FLEDGE)
PatCG: Grupo de la comunidad de tecnología publicitaria privada
Acceso al: Usuario de confianza
RWS: Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)
SSP: Plataforma de proveedores
UA: Cadena de usuario-agente
UA-CH: Sugerencias de clientes de usuario-agente
W3C: World Wide Web Consortium
WIPB: Ceguera IP intencional

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

Tema de los comentarios	Resumen	Respuesta de Chrome
Compromisos	La Sección G de los Compromisos es fundamental para la viabilidad de Privacy Sandbox. Sin una garantía de que el negocio de anuncios de Google opere exclusivamente en tecnologías de Sandbox, aumenta el riesgo de que la utilidad disminuya cada vez más, al igual que la posibilidad de que Google desinvierta la tecnología. Una desinversión o reducción de la utilidad sería una amenaza existencial para la direccionabilidad orientada a la privacidad en la Web abierta.	Los Compromisos no garantizan que el negocio de anuncios de Google opere exclusivamente en tecnologías de Privacy Sandbox. Google tiene la intención de usar un enfoque de cartera para la capacidad de direccionamiento, que incluirá las tecnologías de Privacy Sandbox, de la misma manera que los terceros pueden y usan. Sabemos que un enfoque de cartera es común en todo el ecosistema de anuncios. Creemos que sigue siendo importante que los desarrolladores tengan herramientas y tecnologías que preserven la privacidad. Seguiremos poniendo a disposición las APIs de Privacy Sandbox y realizando inversiones en ellas para mejorar aún más la privacidad y la utilidad.
Administración	El modelo de gobernanza propuesto no incluye mecanismos específicos de responsabilidad en los procesos de consulta formal o apelación.	Esta opción no es correcta. Tanto (i) el sistema de toma de decisiones y las publicaciones asociadas como (ii) el proceso de apelación proporcionan mecanismos específicos de responsabilidad. Además, el fideicomisario de supervisión supervisará su funcionamiento en detalle.
Administración	Comentarios que indican que el modelo no contiene disposiciones para la creación y el mantenimiento de un estándar multiplataforma	Ningún modelo de gobernanza puede obligar a otros actores, en este caso, a los navegadores, a adoptar un estándar. Por lo tanto, no propusimos un modelo que requiera la adopción de estándares multiplataforma. Google seguirá participando en foros de estándares en los que hacer propuestas y compartir experiencias de implementación de propuestas es una actividad común en el proceso.
Administración	Se recomienda extender el período de consulta a, al menos, 2 meses. El modelo de gobernanza propuesto no le brinda al ecosistema el tiempo adecuado para analizar los impactos de los cambios propuestos.	El período de tres semanas no es el período completo de comentarios para un cambio determinado, ya que los ciclos de comentarios existentes (que son mucho más largos) continuarán. En cambio, el proceso de consulta ofrece una nueva ventana de comentarios formales dentro del proceso existente para las decisiones estratégicas. Por lo tanto, los terceros podrán seguir proporcionando comentarios a través de varios foros (incluidos GitHub, W3C y organismos de estándares de anuncios como IAB Tech Lab) durante el desarrollo de las funciones. Estructurar los ciclos de comentarios de esta manera le brinda al ecosistema la oportunidad de analizar y compartir sus puntos de vista sobre un cambio propuesto sin demoras importantes en el proceso de desarrollo.
Administración	Solicitar detalles sobre los planes de gobernanza futuros	En el informe del 2º y 3ᵉʳ trimestre de 2024 de la CMA (páginas 3 a 5 aquí), se incluye un resumen del modelo de gobernanza propuesto.
Solicitud de excepción	Solicitar una excepción para acceder a las cookies de terceros (3PC) de los usuarios que dieron su consentimiento	Dar consentimiento para el acceso y el almacenamiento en el dispositivo con fines de procesamiento de datos específicos no indica que el usuario quiera anular su configuración de 3PC en Chrome. Permitir la anulación a nivel del sitio de la configuración de 3PC de un usuario crearía un potencial considerable de uso inadecuado, y sería imposible para Chrome auditar el comportamiento de todos los sitios que podrían generar una solicitud de excepción.
Privacy Sandbox	Solicitud de tarifas de participación de la API de Privacy Sandbox	No tenemos planes de compartir esta información con el ecosistema. Los desarrolladores pueden llamar a las APIs en las que tienen código implementado hoy para estimar la disponibilidad de las APIs de Privacy Sandbox.
Prueba de origen	¿Hay un plan para extender la prueba de origen?	La prueba de origen se extendió hasta el 14 de abril de 2025.
Privacy Sandbox	Solicita una explicación concisa y no técnica de Privacy Sandbox que destaque su valor comercial y garantice la aceptación de los ejecutivos.	Recientemente, agregamos una sección de recursos para empresas a privacysandbox.com aquí, que proporciona esta información.
Modo B	Cuando un navegador está en el "Modo B", ¿se quedará o se borrará el contenedor de cookies actual (1PC, 3PC, almacenamiento local)?	No se borrará el contenedor de cookies actual. Se podrá acceder a los 3PC en su contexto propio.
Enfoque actualizado para 3PC en Chrome	¿Se quitarán por completo las 3PC de Chrome en el futuro?	Proponemos un enfoque actualizado que brinde más control a los usuarios. Como se indica aquí, en lugar de dar de baja las cookies de terceros, presentaremos una nueva experiencia en Chrome que permitirá a las personas tomar una decisión informada que se aplique a toda su navegación web, y podrán ajustar esa decisión en cualquier momento. Estamos analizando esta nueva ruta con los organismos reguladores y nos comunicaremos con la industria antes de lanzarla.
Pruebas de Chrome	Solicitud de disponibilidad continua de las etiquetas de pruebas facilitadas por Chrome	El equipo de Privacy Sandbox comprende que las empresas desean seguir usando las etiquetas de baja de cookies. El proceso para extender la disponibilidad de las etiquetas es similar al de extender una prueba de origen. Como parte de este proceso, el experimento solo se puede extender para tres eventos importantes de Chrome a la vez. Por ejemplo, el Intento de extender el experimento (I2EE) más reciente de Chrome para las etiquetas de baja de cookies se extendió para Chrome M130 a M132 inclusive. Esto habilita la compatibilidad con las etiquetas hasta la versión estable M133 a principios de febrero. Las extensiones adicionales se ejecutarán mediante el mismo proceso, por lo que te recomendamos que sigas el grupo de correo electrónico blink-dev para obtener actualizaciones.

Inscripción y certificación

No se recibieron comentarios este trimestre.

Muestra anuncios y contenido relevantes

Temas

Tema de los comentarios	Resumen	Respuesta de Chrome
Especificaciones	¿El modelo del clasificador se comparte entre Android (por nombre de app) y Chrome (por nombre de host)?	No, son modelos independientes, ya que tienen taxonomías diferentes.
Nivel de detalle de la taxonomía de temas	Los temas son demasiado genéricos para ser útiles cuando se aprovechan con información propia.	La taxonomía de Topics busca equilibrar la utilidad y la privacidad. Si bien evaluamos posibles mecanismos para que los temas sean más específicos, finalmente decidimos no hacerlo debido a consideraciones de seguridad y privacidad, entre otras inquietudes. Las tecnologías publicitarias pueden obtener los mejores resultados combinando todas las herramientas disponibles, como el aprendizaje automático y los indicadores que preservan la privacidad de las APIs que protegen la privacidad, junto con los datos contextuales, los datos de creatividad y los datos de origen. Puedes encontrar más información sobre este tema aquí.
Uso de API	La API de Topics tiene una cobertura baja.	Entre los motivos habituales para que la cobertura sea baja, se incluyen los siguientes: - Controles de usuario o inhabilitación - Controles o inhabilitación del publicador - Elegibilidad del sitio (los siguientes sitios no están aprobados para coincidir con Topics: sitios no seguros, WebView, Chrome en iOS y modo Incógnito) - Limitaciones del usuario (no se pueden observar ni asignar temas a los usuarios de Chrome menores de 18 años o que usan el modo Incógnito) - Reciente implementación (se permiten alrededor de 4 semanas para que la observación del llamador se escale)
Uso de API	Solicitud de información sobre el uso de la API de Topics, ya que la pestaña Networking parece mostrar que hay una llamada enviada y detectada, pero chrome://topics-internals/ no muestra el observador registrado.	Cuando se usa el mecanismo de encabezado HTTP para interactuar con la API de Topics, los temas se envían en el encabezado de solicitud Sec-Browsing-Topics, pero solo se observan si el servidor responde con el encabezado de respuesta Observe-Browsing-Topics: ?1. Esto se explica con más detalle aquí.
Participación de Chromium	En el caso de las computadoras, ¿Chrome compartiría con otros navegadores basados en Chromium el mismo contexto de observación y clasificación? En el caso de los dispositivos móviles, ¿Chrome para Android compartiría con otros navegadores para Android basados en Chromium o Chromium integrado en la app el mismo contexto de observación y clasificación?	Chrome no comparte datos de Topics con otros navegadores en el dispositivo.
Especificaciones	¿Cómo decide la API de Topics si la vista de una página por parte de un usuario se considera una "entrada de historial de temas"?	Para poder realizar el cálculo de temas semanales, una visita a la página debe tener una llamada de "observación" (puede ser de cualquier llamador). Sin una llamada "observar", la visita no se considerará para el historial de temas.
Seguridad	¿Cómo evita la API de Topics que un llamador obtenga los temas de observación de otros llamadores?	Proporcionamos una explicación aquí.
Taxonomía	¿Cómo se usa la taxonomía de estructura de árbol dentro de la API de Topics en la observación de cada época?	Cuando se calculan los 5 temas principales, solo se consideran los temas originales que proporciona el clasificador, y las clasificaciones se determinan según (i) la frecuencia de las visitas a la página y (ii) una puntuación de priorización (consulta las especificaciones). Cuando se calculan los temas observados por los usuarios de cada uno de los 5 temas principales, se incluyen los usuarios que observaron el tema principal o cualquiera de sus temas secundarios.
Especificaciones	Solicitud de información adicional sobre el 5% de ruido aleatorio en la respuesta.	Siempre hay 5 temas principales para cada época. Si el historial de navegación no proporciona 5 temas, los temas se eligen de forma aleatoria hasta que haya 5. Estos se denominan temas rellenos. Los llamadores no recibirán uno de estos temas rellenos de forma aleatoria, a menos que hayan observado (llamado a la API) al usuario en un sitio con el tema en las últimas semanas. Cuando se llama a la API, se calcula un hash por usuario, por sitio y por época. Si ese hash es menor que la probabilidad de mostrar un tema con ruido, se selecciona el tema aleatorio por usuario, por sitio y por época para mostrarlo. Sin embargo, el tema con ruido solo se muestra (p.ej., no se filtra) si el llamador observó el tema correspondiente sin ruido para ese usuario, sitio o época (consulta la explicación). Este filtrado garantiza que los temas con ruido se muestren el 5% del tiempo para el llamador determinado, independientemente de su capacidad de observación.
Especificaciones	¿Cómo funcionan los temas duplicados entre semanas? ¿La API selecciona de forma independiente entre semanas y, luego, las combina?	Los temas de cada semana (ciclo de entrenamiento) se calculan de forma independiente. El tema específico que se elige para mostrarse en cada época depende del sitio en el que se encuentra el llamador. No tenemos en cuenta que el tema puede repetirse en diferentes épocas para un llamador determinado (por lo que se debe considerar seleccionar un tema diferente), pero recibimos con gusto comentarios adicionales sobre este problema aquí.

API de Protected Audience

Tema de los comentarios	Resumen	Respuesta de Chrome
Prueba A/B	La solución de almacenamiento compartido que se describe aquí agrega latencia y tiene una alta tasa de fallas (es decir, una proporción significativa del tráfico termina sin un ID de propagación). Un ID de baja entropía (p.ej., 3 bits) podría ser suficiente para realizar pruebas A/B eficaces sin un impacto significativo en la privacidad.	Creemos que la solución de almacenamiento compartido sigue siendo un enfoque viable, pero estamos considerando esta solicitud y agradecemos los comentarios adicionales del ecosistema si esta función es de alta prioridad.
Informes	Solicitud de bits adicionales en `reportWin()`, en particular, porque se entiende que los nuevos informes de clics y de impresiones en la API de PA usarán de 6 a 8 bits, lo que reducirá de manera efectiva los bits restantes disponibles para otros informes de la API de PA.	Debido a preocupaciones sobre la privacidad, ya no consideramos aumentar los bits de modelingSignals más allá de los 12 bits actuales. Invitamos al ecosistema a que nos envíe comentarios sobre nuestra propuesta de entrenamiento de modelos privados, cuyo objetivo es respaldar las necesidades de entrenamiento de AA en un entorno seguro sin un límite de bits impuesto por Privacy Sandbox.
Grupos de interés	Solicitar ciclos de vida de 90 días para los grupos de intereses (GI), ya que 30 días no es suficiente.	Como mencionamos en nuestra entrada de blog, planeamos extender la vida útil de las IG a 90 días. Aquí encontrarás una explicación. Actualmente, estamos trabajando en la implementación y compartiremos un cronograma de lanzamiento cuando esté disponible.
Grupos de interés	Se solicitan actualizaciones dinámicas para la delegación de IG.	Estamos al tanto de esta solicitud de varias partes interesadas y estamos investigando una solución. Compartiremos actualizaciones en GitHub a medida que se desarrolle y recibiremos con gusto más comentarios del ecosistema.
En el dispositivo	Demostrar más valor para que el ecosistema siga invirtiendo en soluciones de APIs de PA integradas en el dispositivo	El equipo de Privacy Sandbox continúa desarrollando APIs basadas en la tecnología de mejora de la privacidad (PET), incluida la API de PA, para ofrecer a los desarrolladores más opciones que preserven la privacidad en el navegador. Esas tecnologías están disponibles en general en los navegadores Chrome a gran escala (no solo en el 1%, como algunos desarrolladores malinterpretaron). Independientemente de si los usuarios habilitan los 3PC, los desarrolladores pueden optar por incorporar soluciones basadas en PET en sus productos, al igual que muchas empresas están optando por adoptar otras soluciones basadas en PET fuera del navegador. Muchos desarrolladores ya se benefician de invertir en soluciones de API de PA integradas en el dispositivo, ya que extienden su indicador de público propio determinista para mejorar el alcance en todos los sitios. Entendemos que algunos desarrolladores solo optarán por usar las APIs de Privacy Sandbox o alguna otra solución basada en PET si se inhabilitan más 3PC, y estos desarrolladores están esperando información que les permita especular cuántos navegadores retendrán las 3PC. Reconocemos que esos desarrolladores esperarán hasta encontrar la información que buscan para tomar decisiones sobre los productos.
Grupos de interés	Permite que las SSP participen en la creación de los IG y en los roles asociados con ellos. Las SSP consideran que esto es una parte importante de su valor agregado y les gustaría poder ayudar a los publicadores a vender IG a través de sus SSP.	Recibimos la solicitud de varias partes interesadas para admitir delegaciones de IG más avanzadas y vemos el valor agregado de las SSP que contribuyen a este proceso. Estamos investigando para encontrar la mejor solución que permita que diferentes partes participen en el proceso de extensión del público. Compartiremos actualizaciones en GitHub a medida que se desarrolle y recibiremos con gusto más comentarios del ecosistema.
Informes	Discrepancias en la cantidad de informes de "ofertas distintas de cero" entre forDebuggingOnly y la API de Private Aggregation.	Esperamos que exista una discrepancia por dos razones: En primer lugar, el modo de depuración de la API de Private Aggregation solo está disponible cuando hay 3PC permitidas en el dispositivo, mientras que la API de forDebuggingOnly siempre está disponible sin muestrear (este último comportamiento cambiará con el tiempo, como se detalla aquí). En segundo lugar, la API de Private Aggregation tiene límites de contribución, mientras que forDebuggingOnly no. Sin embargo, estos comentarios indican que puede haber algún otro motivo que cause una discrepancia inesperada, por lo que estamos trabajando con una parte externa para resolver este problema.
Capacidad de hacer clic	Como se menciona en la propuesta actualizada del indicador de clicabilidad, las vistas y los clics se registrarían devolviendo un nuevo encabezado de respuesta HTTP a las solicitudes iniciadas por el atributo "attributionsrc" que sean "apto", y este encabezado de respuesta incluiría una lista de orígenes que se pueden usar para indicar qué otras partes pueden incluir estas vistas y clics en sus recuentos agregados. ¿Esto significa que la tecnología publicitaria puede establecer los orígenes de forma arbitraria?	En la explicación sobre la capacidad de generar clics, se especifica que una tecnología publicitaria que proporciona un evento de vista o clic a los recuentos de vistas y clics agregados (un "origen de proveedor") puede incluir un parámetro opcional con el encabezado de respuesta que le permite especificar "uno o más orígenes del propietario de IG para los que se puede incluir este evento en los recuentos de vistas y clics calculados que se proporcionarán a sus invocaciones de `generateBid()` en las subastas de Protected Audience" ("origen apto"). Sin embargo, estas vistas y clics no se incluyen automáticamente en los recuentos de vistas y clics. En cambio, cada tecnología publicitaria debe especificar, en sus IG, el conjunto de "origen de la fuente" desde el que se deben incluir los eventos de vista y clic, y solo los datos de estos orígenes de la fuente contribuyen a los registros de vistas y clics que se presentan a las llamadas `generateBid()` de esa tecnología publicitaria. Este mecanismo requiere un acuerdo de ambas partes y evita que los jugadores maliciosos influyan en los recuentos de vistas y clics de otras tecnologías publicitarias. Esto también significa que una tecnología publicitaria "proveedora" que establezca "origenes aptos" de forma arbitraria no tendrá un impacto en los recuentos de vistas y clics de esos orígenes aptos, a menos que esos orígenes aptos incluyan de forma explícita y deliberada ese origen proveedor en su IG.
Entrenamiento de modelos privados	Hay casos en los que DP-SGD (descenso de gradientes estocástico con privacidad diferencial) haría que el proceso de entrenamiento fuera considerablemente más lento, ya que destruye la dispersión de los gradientes calculados durante la propagación hacia atrás. ¿Hay alguna técnica que se esté considerando para abordar esta inquietud?	Conocemos algunas técnicas para preservar la dispersión en el DP-SGD (p.ej., esta) y estamos explorando la compatibilidad con este tipo de técnicas en la infraestructura de entrenamiento de modelos privados. Compartiremos actualizaciones a medida que se desarrolle el proceso y recibimos comentarios adicionales aquí.
Segmentación negativa	Solicita actualizaciones sobre el lanzamiento de la función de filtrado negativo de IG que se describe aquí.	Como se indica en nuestra respuesta aquí, planeamos admitir IG negativos en las ofertas de la API de PA. Compartiremos un cronograma de lanzamiento cuando esté disponible. Aceptamos comentarios adicionales aquí.
Ofertas	¿Es posible combinar varios IG cuando se oferta?	Por el momento, esto no es posible con la API de PA. La API de PA se basa en el diseño que el IG relaciona con la información que un solo sitio conoce sobre el usuario, lo que ha sido fundamental en las discusiones con el ecosistema en general. Este enfoque permite que las tecnologías publicitarias desarrollen una variedad de soluciones que ayudan a los anunciantes a ampliar sus públicos propios en la Web. Sabemos que la propuesta de la API de Ads Selection de Microsoft propone un diseño diferente en el que los públicos se basan en la información de todos los sitios. Si bien seguiremos supervisando su enfoque, nos gustaría ver más debates en el ecosistema, incluida la comunidad de privacidad, antes de considerar cambios similares en Chrome.
Anuncios nativos	Preocupaciones sobre si la API de PA puede admitir de forma adecuada los diversos formatos y requisitos de renderización de los anuncios nativos, y si la API de PA permite la flexibilidad y optimización de las creatividades necesarias para una publicidad nativa eficaz.	Estamos investigando activamente cómo brindar más asistencia para los anuncios nativos y recibimos con gusto los comentarios adicionales del ecosistema.
Informes	Solicitud para mejorar la solidez de las secuencias de comandos de informes que compiten por recursos con secuencias de comandos de ofertas y que podrían perderse cuando se salga del marco de subasta en ejecución.	Esperamos publicar una respuesta en GitHub pronto, pero no creemos que estas inquietudes afecten de manera significativa los informes válidos en la práctica.
Reemplazo de macros	Los reemplazos de macro que se pasaron en la configuración de subasta no funcionan con algunas configuraciones de terceros.	La causa raíz fue que no todo el tráfico etiquetado del modo A/B tenía esta función activada. Recientemente, decidimos activar esta función (y otras funciones en la misma situación) en todo el tráfico etiquetado como modo A/B. Prevemos realizar este cambio durante el 1ᵉʳ trimestre de 2025. Te invitamos a que envíes más comentarios aquí.
Documentación	Solicitamos una aclaración, ya que parece haber una discrepancia en la documentación con respecto a la unidad de medida del valor de recency en el objeto browserSignals dentro de `generateBid()`.	Respondimos a esta inquietud con más detalle aquí y actualizamos nuestra documentación de acuerdo con ello. La respuesta correcta es que la unidad de medida es milisegundos.
Informes	Solicitud de informes de terceros: mientras que las DSP y las SSP reciben notificaciones de impresiones de Chrome, los proveedores técnicos de la capa intermedia no lo hacen de forma predeterminada.	Actualmente, estamos analizando esta solicitud de función aquí y recibimos con gusto más comentarios.
Grupos de interés	Solicitud de orientación para excluir interestGroupBuyers de forma dinámica cuando se usan flujos de trabajo de subasta de IG en paralelo.	Aquí encontrarás información sobre este tema.
Anuncios nativos	Las subastas independientes de la API de PA para una carga de página determinada evitan el filtrado de anuncios en la misma página.	La compatibilidad con más anuncios nativos, incluidos los widgets de recomendación conocidos como "nativos" y que tienen varios anuncios en una unidad, es un área de investigación activa y reconocemos que el diseño actual puede no admitir el filtrado de anuncios en la misma página, y otras protecciones, como los marcos delimitados, también pueden impedir que esto suceda.
Anuncios nativos	Es posible que las funciones existentes de la API de PA, como el análisis de creatividades, los informes, etc., que dependen de indicadores basados en URLs, deban adaptarse para controlar los objetos JSON que se usan en las creatividades de anuncios nativos.	La compatibilidad con más anuncios nativos es un área de investigación activa, y estamos evaluando la viabilidad de adaptar la API de PA para ayudar a renderizar anuncios nativos.
Verificación de anuncios	La seguridad de la marca de terceros en la API de PA se ve afectada debido a las limitaciones de latencia y almacenamiento en caché de perBuyerSignals, lo que es un problema para el contenido dinámico.	Reconocemos que las SSP y las DSP deben determinar un TTL óptimo para la caché que equilibre los objetivos de modelado de tráfico y los TTL máximos de seguridad de la marca para garantizar que los datos almacenados en caché sigan siendo relevantes para la seguridad de la marca. Estamos investigando este problema y compartiremos actualizaciones a medida que se desarrolle.
Verificación de anuncios	Es necesario que las SSP reemplacen la macro FullpageURL para realizar la medición de seguridad de la marca posterior a la oferta.	deprecatedReplaceInURN es la sugerencia actual para que las SSP proporcionen este indicador.
Verificación de anuncios	La falta de estandarización en los formatos de macro que usan las SSP para la verificación posterior a la oferta puede causar incoherencias y errores en el procesamiento y el análisis de datos.	Las SSP y los verificadores de anuncios deben colaborar directamente para definir lineamientos y especificaciones claros sobre el uso de macros que impulsen la estandarización de los formatos de macros en todas las SSP para garantizar la coherencia y evitar errores en el procesamiento y el análisis de datos. Esta es una actividad para la que las organizaciones de estándares de anuncios como IAB Tech Lab son adecuadas.
Verificación de anuncios	Los anunciantes y los verificadores de anuncios requieren un mecanismo para vincular las verificaciones previas a la oferta y posteriores a la oferta para el mismo contexto del publicador para depurar y solucionar problemas.	Una opción para la verificación posterior a la oferta es a través de indicadores basados en subastas y campañas que se incorporan en los informes a nivel del evento. Esto puede habilitar las uniones con registros de decisiones previas a la oferta. Estamos explorando posibles patrones para lograrlo y compartiremos actualizaciones a medida que se desarrolle.
Verificación de anuncios	Solicitud para explorar soluciones de servidores de pares clave-valor de confianza (TKV) (propiedad de la DSP y del verificador de anuncios) para la oferta previa y abordar las limitaciones de los marcos delimitados para la oferta posterior.	Estamos evaluando esta solicitud y recibimos con gusto comentarios adicionales del ecosistema aquí para encontrar una solución que pueda respaldar la seguridad de la marca antes de la oferta y facilitar los requisitos de coordinación entre las partes.
Anuncios nativos	Solicitud de auditoría de renderización posterior a la oferta orientada a la venta para anuncios nativos	La compatibilidad adicional con los anuncios nativos es un área de investigación activa, y estamos considerando adaptar funciones existentes como esta para ayudar a la renderización de anuncios nativos.

Subasta protegida (servicios de ofertas y subastas)

Tema de los comentarios	Resumen	Respuesta de Chrome
Latencia	No se realizaron mitigaciones adecuadas para la latencia. Si bien los servicios de B&A pueden mitigar este problema a largo plazo, Google no se comprometió a que estén disponibles de forma generalizada antes de los cambios en los 3PC en Chrome.	Realizamos varias mejoras en la latencia en el dispositivo en los últimos trimestres. También estamos creando y escalando servicios de B&A según sea necesario. Recientemente, actualizamos nuestra guía de prácticas recomendadas sobre latencia, que incluye más información para aprovechar estas funciones. También seguimos desarrollando nuevas mejoras de latencia, algunas de las cuales se pueden ver aquí.
(También se informó en trimestres anteriores) Seguridad de subastas	Solicitación de más aclaraciones sobre los enfoques para evitar o mitigar los intentos de manipular la subasta integrada en el dispositivo (p. ej., si Google considera que esto es un riesgo significativo)	Nuestra respuesta no ha cambiado desde los trimestres anteriores: "Los mecanismos de informes de los anuncios de la API de PA retienen la información que se usa actualmente para distinguir el tráfico humano del tráfico de bots. Además, las técnicas actuales basadas en dominios para incluir o excluir dominios se pueden usar en la API de PA. Esto se describe con más detalle en nuestra respuesta al informe de IAB Tech Lab sobre Privacy Sandbox".
Soluciones locales	Inquietudes sobre la posibilidad de que los proveedores más grandes no adopten Privacy Sandbox o B&A debido a la falta de compatibilidad con la nube privada y el cronograma largo y poco claro para admitirla.	Nos comprometemos a expandir las infraestructuras en las que se ejecutan los servicios de Privacy Sandbox. Recientemente, anunciamos la compatibilidad con la nube de Azure y seguimos investigando posibles soluciones para proporcionar protecciones de privacidad y seguridad similares para las nubes privadas. Desde nuestra comunicación de octubre, hemos avanzado mientras seguimos investigando posibles enfoques para proteger la privacidad de los usuarios de Chrome en un entorno de ejecución confiable (TEE) de las instalaciones. Ahora nos encontramos en un punto de nuestra investigación en el que queremos validar diferentes enfoques con las partes interesadas del ecosistema y planeamos comenzar a recopilar comentarios en el 1ᵉʳ trimestre. Los comentarios y la colaboración del ecosistema ayudarán a definir mejor las posibles soluciones.
Prueba	¿Es posible crear TEE para probar soluciones de informes de la API de PA (informes en tiempo real y agregación privada)?	Para las pruebas del servicio de agregación, las tecnologías publicitarias pueden usar datos de prueba y herramientas de pruebas locales para generar informes de resumen para las pruebas funcionales. Consulta el Codelab de pruebas locales aquí. Para probar la agregación en TEE, las tecnologías publicitarias deberán completar el proceso de inscripción como se mencionó en los requisitos previos del codelab anterior. Te invitamos a que nos envíes comentarios adicionales sobre esta solicitud aquí.
Integración de K/V de acuerdos	Solicita la capacidad de extraer información basada en la oferta de KV para casos de uso comerciales.	Estamos evaluando esta solicitud de función y te enviaremos una actualización en GitHub.
Medición de acuerdos sin ganancias	Solicitar indicadores o la capacidad de comprender cuándo una SSP no ganó y por qué.	Estamos evaluando esta solicitud y te enviaremos una actualización en GitHub.
Solicitud de función	Solicita que Privacy Sandbox proporcione una estructura de diccionario para ayudar a hacer coincidir un grupo de anuncios con el conjunto correspondiente de IDs de oferta.	Estamos evaluando esta solicitud, junto con otras formas de reducir el tamaño de IG en relación con el almacenamiento de IDs de ofertas. Proporcionaremos una actualización en GitHub.
Rendimiento	Soluciones para medir las posibles oportunidades de subasta de anuncios perdidas, posiblemente debido al tamaño de la secuencia de comandos de ofertas.	Estamos evaluando esta solicitud y aceptamos comentarios adicionales aquí.
Especificaciones	Actualmente, B&A solo lee el campo prevWins en lugar del campo más reciente prevWinMs que reemplazó a prevWins en la especificación.	Es correcto que B&A no pase la duración en milisegundos en prevWins a `generatebid()`. Chrome envía la duración en segundos para garantizar menos sobrecarga en la carga útil. La solución aquí es que B&A realice la conversión de segundos a milisegundos. B&A proporcionaría prevWins y prevWinsMs en browserSignals para que esto sea compatible con las subastas integradas en el dispositivo. Ten en cuenta que, incluso para las subastas integradas en el dispositivo para la Web, prevWins y prevWinsMs corresponden al mismo valor y prevWinsMs = prevWins × 1000. Estamos priorizando una solución.
Documentación	La documentación no es clara sobre cómo probar el frontend del vendedor (SFE). Sería útil tener una guía de pruebas adicional justo después de completar la implementación, así como información sobre cómo usar Bazel para compilaciones.	Este codelab se publicó como guía para que el ecosistema más amplio pueda probar sus SFE con mayor facilidad.
Implementación	¿Hay planes para proporcionar objetos binarios precompilados para B&A?	Estamos considerando proporcionar objetos binarios compilados previamente para B&A, pero no tenemos cronogramas concretos para esto. Hasta entonces, las tecnologías publicitarias pueden compilar los objetos binarios por su cuenta y validarlos con los valores hash proporcionados.
Implementación	¿Se deben admitir todos los tipos de orquestación (servidor, cliente, mixto) o hay uno que se debe priorizar sobre los demás?	No tenemos recomendaciones específicas sobre los modos que implementa la tecnología publicitaria. La elección depende de varios factores, pero, en última instancia, se reduce a lo que es más conveniente para tus clientes.
Prueba	Se solicita aclaración sobre las pruebas fallidas durante la compilación de B&A.	Esto puede deberse a una prueba inestable. Le recomendamos a la tecnología publicitaria que use la marca `--no-tests` en todos los comandos de compilación `build_and_test_all_in_docker` para omitir la ejecución de las pruebas.
Registros	Necesitamos una aclaración sobre por qué los registros del explorador de registros en GCP se etiquetan a la instancia de VM que ejecuta SFE cuando está en modo de prueba, pero en el modo de producción los registros no se etiquetan a la instancia de VM.	Es difícil generalizar, ya que depende de lo que se vio exactamente, pero en general: - Es probable que los registros de non_prod sean los registros de stderr redireccionados por el proveedor de servicios en la nube (en este caso, GCP) y que GCP haya agregado la etiqueta. - Los registros que produce la VM suelen etiquetarse con la instancia de VM, mientras que GCP no etiqueta los registros que produce el binario. : Open Telemetry exporta los registros de producción en TEE, que tienen etiquetas diferentes. Aquí tienes algunos detalles de lo que está disponible en non_prod y prod.
B&A	Se produce un error 403 en los secretos faltantes cuando se inhabilita el registro de OTEL.	Este problema se corrigió a partir de la actualización 4.1, y la documentación se editó según corresponda.
B&A	Si falta el archivo outputs.tf para la configuración de Terraform de GCP, se produce un error.	Ya se corrigió ese error.
Prueba	Se produjo un error cuando se recuperaba la clave privada en modo de prueba.	En estos casos, asegúrate de que los servidores se ejecuten con TEST_MODE=true. Consulta la explicación aquí.
Hoja de ruta	¿Hay planes para que getInterestGroupAdAuctionData acepte más de un origen del vendedor y devuelva un mapa del origen del vendedor al texto cifrado de la carga útil de B&A?	Sí, se planea agregar compatibilidad para permitir que navigator.getInterestGroupAdAuctionData() acepte varios vendedores.
Especificaciones de KV	¿Se puede entregar la URL de KV (trustedScoringSignalsURL) como una promesa?	Consulta la explicación que se proporciona aquí.
B&A	Solicita la creación de un nuevo encabezado de plataforma para indicarle al vendedor de B&A qué capacidades requiere el cliente (navegador) para que se realice una subasta privada.	Actualmente, estamos analizando esta solicitud de función aquí y recibimos con gusto más comentarios.
Determinación por tráfico	Propuesta para reducir los costos incrementales de alojar servidores de B&A, en especial para las DSP.	Actualmente, estamos analizando esta propuesta aquí y recibimos con gusto más comentarios.
Usa tu propio código binario	Considera actualizar la explicación para indicar de forma explícita que se admiten todos los objetos binarios.	Ya se actualizó. Consulta la explicación aquí.
Llamadas a KV	¿`generateBid()` espera a que finalicen todas las llamadas a la tienda de par clave-valor (KV) o se ejecuta de forma independiente? ¿Cómo afecta el procesamiento por lotes de KV a su tiempo de ejecución?	Consulta la explicación que se proporciona aquí.
Rendimiento	Solicita documentación adicional sobre el uso de secuencias de comandos de ofertas y recomienda configurar encabezados de control de caché en las secuencias de comandos.	La documentación se agregó aquí.
Rendimiento	Solicita que se considere y explore la capacidad de cargar recursos (p.ej., secuencias de comandos de ofertas) de forma asíncrona para reducir la latencia de la subasta en el dispositivo.	Actualmente, estamos analizando esta solicitud de función aquí y recibimos con gusto más comentarios.
Registro de consentimiento	Se necesita una aclaración sobre el error que se ve cuando se intenta usar el registro de consentimiento configurando CONSENTED_DEBUG_TOKEN.	En estos casos, verifica que CONSENTED_DEBUG_TOKEN esté presente en el administrador de secretos, que ENABLE_OTEL_BASED_LOGGING esté configurado como true y que TELEMETRY_CONFIG esté configurado como mode: PROD. Consulta la explicación aquí, que hace referencia a la fuente aquí.
Registros	¿Los eventos forDebuggingOnly están disponibles a través de B&A?	forDebuggingOnly para B&A está disponible para subastas de un solo vendedor desde abril de 2024. Planeamos habilitarlo para las subastas de varios vendedores muy pronto.
Registros de worklet	Solicitud para que el registro de worklet sea compatible con ChromeDriver.	Estamos evaluando esta solicitud y aceptamos comentarios adicionales aquí.

Medición de anuncios digitales

Attribution Reporting (y otras APIs)

Tema de los comentarios	Resumen	Respuesta de Chrome
Informes de depuración	¿Cómo estarán disponibles los informes de depuración de ARA para las tecnologías publicitarias después del enfoque actualizado de los 3PC en Chrome? ¿Las tecnologías publicitarias deberían seguir teniendo acceso a los informes de depuración de ARA para los usuarios que conservan 3PC y tienen habilitadas las APIs de Privacy Sandbox?	Las tecnologías publicitarias tendrán acceso a soluciones de depuración con y sin cookies para los usuarios que tengan habilitadas las 3PC y la ARA. Cuando las cookies estén desactivadas, solo tendrán acceso a la solución de depuración agregada. Puedes encontrar más detalles sobre las soluciones de depuración aquí y aquí.
Detección de atributos	Solicita orientación para realizar la detección de atributos para ARA en el servidor.	Actualmente, la compatibilidad con las funciones de la ARA se puede identificar en función de la versión de Chrome que se ve en la cadena del usuario-agente. Nos complace recibir comentarios adicionales del ecosistema sobre este tema.
Solicitud de función	Se solicitó que el campo source_registration_time que se usa en shared_info agregado de ARA sea más detallado, p.ej., que se redondee hacia abajo a una hora o un minuto (en lugar de un día) y que se pueda configurar para tener en cuenta la zona horaria (actualmente, solo UTC).	Redondear el campo source_registration_time al día más cercano es un mecanismo de privacidad que se usa para mitigar la capacidad de una tecnología publicitaria de vincular un usuario específico a un registro de fuente específico. Actualmente, source_registration_time se basa en UTC, y una tecnología publicitaria puede ajustar sus informes de anuncios para tener en cuenta esto. Te invitamos a que nos envíes más comentarios sobre el ecosistema en relación con esta solicitud aquí.
Especificaciones	Se solicitó que se aclare la especificación de "trigger_data" y "priority", en especial cuando se usan con el valor de array.	Estos campos no aceptan valores de array. Los corchetes en la explicación no representan un array, sino que indican que el texto no es un valor de ejemplo, sino un marcador de posición con una descripción. Como sugiere el texto entre corchetes: - trigger_data es un int-64 - priority es un int-64 firmado Ninguno de los campos acepta valores de array. También vale la pena considerar usar la herramienta de validación de encabezados para que la ARA experimente con diferentes valores y encuentre errores si la documentación es confusa.
Compatibilidad con anuncios de Accelerated Mobile Pages (AMP)	¿ARA admite anuncios de AMP?	Nuestra propuesta sobre cómo podríamos admitir AMP está disponible aquí y recibimos con gusto comentarios adicionales.
Especificaciones	¿Qué URL se considerará como "sitio de origen" para los anuncios incorporados de varias capas de la ARA?	La URL del sitio de nivel superior.
(También se informa en trimestres anteriores) Solicitud de función	Se solicitó que el valor mínimo de event_report_window se reduzca de 3,600 segundos (1 hora) a 1,800 segundos (30 minutos).	Para determinar el período mínimo de informes, se debe equilibrar la utilidad y las consideraciones de privacidad. La ventana de informes mínima de 1 hora para los informes a nivel del evento es esencial para mantener la privacidad y mitigar ciertos tipos de ataques de reconstrucción de historial. Te invitamos a que nos envíes comentarios adicionales sobre esta solicitud aquí.
Ruido	Buscar una comprensión más profunda de cómo se implementa el ruido en los informes a nivel del evento de la ARA para garantizar una interpretación y utilización precisas de los datos	Puedes encontrar más detalles aquí y aquí.
Informes	shared_info de los informes agregados ya no contiene source_registration_time de forma predeterminada.	Esto se debe a cambios en la API, que se describen con más detalle aquí.
Informes	Falta `filtering_id` en la pestaña "Aggregatable Reports" de la IU de chrome://attribution-internals/.	Actualmente, el `filtering_id` se puede ver en los detalles de la pestaña "Trigger Registrations" cuando haces clic en una fila, lo que te permite confirmar su validez. Reconocemos la utilidad de mostrarlo en la pestaña "Informes agregables" y abordamos este tema aquí.
Fuente de atribución	Solicitud de aclaración sobre el funcionamiento de la fuente de atribución.	Aquí encontrarás una explicación.
Atribución de aplicación a la Web	Solicitud de orientación para implementaciones en las que no se sabe si las fuentes serán del SO o web.	La guía está disponible aquí.

Servicio de agregación

Tema de los comentarios	Resumen	Respuesta de Chrome
Solicitud de función	Solicita un tiempo de espera configurable para AgS o más visibilidad del estado del trabajo para ejecuciones a largo plazo.	Estamos considerando funciones para admitir la supervisión de trabajos de larga duración. Nos complace recibir comentarios adicionales del ecosistema sobre este tema.
Terraform	Terraform intenta modificar la política de IAM de la cuenta, incluso si no se configuró service_account_token_creator_list.	Los desarrolladores pueden agregar sus permisos agregados en el archivo local modules/adtech_setup/main.tf.
Solicitud de documentación	Solicitar documentación o un codelab que explique cómo supervisar el estado del servicio de agregación	Puedes encontrar una descripción de las alarmas existentes que se pueden usar para supervisar el estado del servicio y del trabajo en los archivos de Terraform del operador relevantes (alarms.tf y monitoring.tf) en el repositorio coordinator-services-and-shared-libraries. Publicaremos documentación y orientación adicionales sobre cómo supervisar las tareas del servicio de agregación.
Escalamiento	¿Cómo supervisar los problemas de escalamiento?	Publicamos una versión actualizada de esta guía en la que se documenta la escala más alta del servicio de agregación. Actualmente, no hay indicadores directos que indiquen que se produjo una falla porque la máquina no puede admitir la escala del trabajo. Los indicadores indirectos incluyen: 90% de consumo de memoria antes de una falla, un trabajo que falla de forma recurrente. Agradecemos los comentarios adicionales del ecosistema sobre la necesidad de este indicador.
Especificaciones	¿Cuál es el tiempo de ejecución típico de los lotes de informes de AgS?	Consulta la guía aquí.

API de Private Aggregation

Tema de los comentarios	Resumen	Respuesta de Chrome
Solicitud de función	Solicitud para permitir que las contribuciones de valores de punto flotante (incluidos los negativos) se agreguen a contributeToHistogramOnEvent con una sensibilidad de 2^16	Actualmente, estamos analizando esta propuesta aquí y recibimos con gusto más comentarios.

Limita el seguimiento encubierto

Reducción del usuario-agente o sugerencias de cliente de usuario-agente

No se recibieron comentarios este trimestre.

IP Protection (antes Gnatcatcher)

Tema de los comentarios	Resumen	Respuesta de Chrome
Ubicación geográfica	Solicitud del archivo de geolocalización de la Protección de IP	El archivo que asigna las IP a ubicaciones aproximadas para la protección de IP está disponible aquí. Ten en cuenta que este archivo se actualiza periódicamente.

Mitigación del seguimiento por rebote

Tema de los comentarios	Resumen	Respuesta de Chrome
Lista de instancias permitidas	La posición actualizada ya no aborda la lista de entidades permitidas ni mecanismos similares que serían independientes del proceso de toma de decisiones de Google.	Google no planea tener listas de entidades permitidas asociadas con mitigaciones del seguimiento por rebote (BTM); las protecciones se aplican de forma uniforme a todos los dominios.
Cumplimiento	La ICO debe tener autoridad sobre el cumplimiento relacionado con la privacidad.	El estado de cumplimiento no tiene relación con la aplicación de la BTM, y Google no toma ninguna decisión con respecto al cumplimiento en la implementación de la BTM.
Competencia	Al parecer, Google podría tener permitido excluir a la competencia de PET con la BTM (o con otras medidas) y, luego, decidir si permitir que vuelvan al mercado. El proceso de apelación actual puede impedir temporalmente que los competidores de PET usen la BTM o medidas similares.	La propuesta actual de la BTM se orienta al seguimiento de rebotes como técnica. Si bien Google intenta evitar que se incumplan ciertos casos de uso que pueden implicar técnicas similares, no tiene previsto proporcionar exenciones individuales de la BTM. Por lo tanto, no surge la cuestión de si Google ejerce discreción sobre la presencia de competidores.

Fortalecimiento de los límites de la privacidad entre sitios

Conjuntos de sitios web relacionados (anteriormente, Conjuntos propios)

Tema de los comentarios	Resumen	Respuesta de Chrome
(También se informa en trimestres anteriores) Límite de dominios de los conjuntos de sitios web relacionados (RWS)	El límite actual de cinco dominios asociados no es lo suficientemente alto para lograr casos de uso de medición entre sitios.	Nuestra respuesta es similar a la de trimestres anteriores: Por el momento, no esperamos aumentar el límite numérico. El límite se estableció en función de las 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 nuestras entradas de blog (1, 2). Te recomendamos que examines los casos de uso que requieren acceso a cookies entre sitios más allá del límite numérico y que consideres aprovechar nuestra guía para casos de uso de identidad, integraciones autenticadas y casos de uso de publicidad. Te invitamos a que nos envíes más comentarios sobre este problema aquí.

API de Fenced Frames

Tema de los comentarios	Resumen	Respuesta de Chrome
Anuncios nativos	La renderización de anuncios nativos en marcos vallados plantea desafíos, ya que heredar el diseño del publicador está limitado debido a las limitaciones en la comunicación entre el iframe y la página del publicador.	La compatibilidad adicional con los anuncios nativos, incluida la compatibilidad posterior a la aplicación de la política de marcos delimitados, es un área de investigación activa. Te invitamos a que nos envíes más comentarios sobre este problema aquí.

API de Shared Storage

Tema de los comentarios	Resumen	Respuesta de Chrome
Uso de API	La API de Shared Storage no está disponible en algunos dispositivos cuando otras APIs de Privacy Sandbox están en funcionamiento.	Se espera que este comportamiento se presente en un pequeño subconjunto de usuarios (alrededor del 1%) que forman parte del experimento de aislamiento de almacenamiento compartido. Esta configuración experimental se usa para evaluar el rendimiento y la adopción de las APIs en diversas situaciones.
Uso de API	¿Las operaciones de escritura en Shared Storage se realizan en el origen del publicador o en el origen de la secuencia de comandos de ofertas? Las pruebas iniciales no mostraron ninguna operación de escritura cuando el origen del publicador difería del origen de la secuencia de comandos.	Este problema se resolvió y solo permanece abierto en caso de un posible error de herramientas para desarrolladores. Aquí puedes encontrar más detalles. El almacenamiento compartido escribe en el origen del comprador en el contexto de ofertas de la llamada `generateBid`. La escritura no está vinculada al origen del publicador, incluso si la página del publicador reside en un dominio diferente.
Uso de API	¿Qué protecciones existen para que una persona o entidad que actúa de mala fe pueda leer los informes de almacenamiento compartido?	El almacenamiento compartido se particiona llamando al origen para que un usuario malicioso o una tecnología publicitaria no puedan leer los datos del almacenamiento compartido desde otra tecnología publicitaria. Los informes de agregación privada se envían directamente al mismo origen a través de TLS para que no se puedan interceptar.

CHIPS

Tema de los comentarios	Resumen	Respuesta de Chrome
Cookies particionadas	El manejo de cookies es incoherente en diferentes puertos localhost en Chrome y Firefox, en particular cuando se usa el atributo Partitioned.	Firefox trata a localhost con diferentes puertos como claves de partición distintas. Si bien este comportamiento se alinea con los principios de seguridad, se desvía de la especificación y del enfoque de Chrome. Esperamos analizar esto con otros navegadores en una discusión sobre las especificaciones de HTML y notificaremos al ecosistema si esto genera un cambio en la clave de partición de CHIPS. Aceptamos comentarios adicionales sobre este problema aquí.
Cookies particionadas	El borrador de Clear-Site-Data permite borrar incorrectamente más allá de la partición del sitio emisor, lo que contradice las discusiones anteriores a las que se hace referencia aquí.	Este es un error en el documento de especificación de estándares, que corregiremos pronto. El comportamiento correcto se especifica en esta sección de la explicación y se alinea con el comportamiento de otros navegadores en el repositorio de explicaciones sobre el particionamiento de almacenamiento. La implementación de Chrome ya funciona correctamente.