Informe trimestral del cuarto trimestre de 2022 que resume los comentarios del ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan a partir de la agregación de los comentarios que recibe Chrome de las diversas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome recibe con gusto los comentarios que recibe del ecosistema y explora activamente formas de integrar los aprendizajes en las decisiones de diseño.
Los temas de los comentarios se clasifican según su prevalencia por API. Para ello, se realiza una agregación de la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Para identificar los temas de comentarios comunes, se revisaron los temas de debate de las reuniones públicas (W3C, PatCG, IETF), los comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos de Google y los formularios públicos.
Más específicamente, se revisaron los actas de las reuniones de los organismos de estándares web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios público. Luego, Google coordinó entre los equipos involucrados en estas diversas actividades de divulgación para determinar la prevalencia relativa de los temas que surgieron en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de las preguntas frecuentes publicadas, las respuestas reales a los problemas planteados por las partes interesadas y la determinación de una posición específica para los fines de este ejercicio de informes públicos. Debido al enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Fledge y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período de informes actual aún no tengan una respuesta de Chrome.
Glosario de acrónimos
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- FPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IDP
- Proveedor de identidad
- IETF
- Internet Engineering Task Force
- IP
- Dirección de protocolo de Internet
- openRTB
- Licitaciones en tiempo real
- TS
- Prueba de Origin
- PatCG
- Grupo de la comunidad de tecnología publicitaria privada
- Acceso al
- Usuario de confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- Cadena de usuario-agente
- UA-CH
- Sugerencias de clientes de usuario-agente
- W3C
- World Wide Web Consortium
- WIPB
- Ceguera IP intencional
Comentarios generales, sin API ni tecnología específicas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en el tercer trimestre) Utilidad para diferentes tipos de partes interesadas |
Preocupaciones sobre el hecho de que las tecnologías de Privacy Sandbox favorezcan a los desarrolladores más grandes y que los sitios de nicho (más pequeños) contribuyan más que los sitios genéricos (más grandes) | Nuestra respuesta no ha cambiado desde el tercer trimestre: "Google se comprometió con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia mediante la preferencia propia de la empresa de Google y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes, independientemente de su tamaño. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos. A medida que avanzan las pruebas de Privacy Sandbox, una de las preguntas clave que evaluaremos es el rendimiento de las nuevas tecnologías para los diferentes tipos de partes interesadas. Los comentarios son fundamentales en este sentido, en especial los comentarios específicos y prácticos que pueden ayudarnos a mejorar aún más los diseños técnicos. Trabajamos con la CMA para desarrollar nuestro enfoque de pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño de experimentos para proporcionar más información a los participantes del mercado y una oportunidad para comentar sobre los enfoques propuestos". |
| (También se informa en el tercer trimestre) Solicitudes de documentación |
Solicitudes de más recursos que detallen cómo administrar las pruebas, el análisis y la implementación | Actualización del cuarto trimestre: Agradecemos que los desarrolladores hayan encontrado útil nuestro material actual y seguimos comprometidos a proporcionar más material para que puedan comprender cómo pueden beneficiarse de las nuevas tecnologías. Durante el último trimestre, agregamos una sección de "Noticias y actualizaciones" a privacysandbox.com y publicamos una revisión exhaustiva de cómo Privacy Sandbox puede ayudar a impulsar la relevancia de los anuncios en el futuro. También realizamos sesiones públicas de horas de oficina para desarrolladores para compartir prácticas recomendadas y demostraciones, junto con sesiones de preguntas y respuestas con líderes de productos y de ingeniería para permitir debates o preguntas en vivo. |
| Métricas web esenciales | ¿Cómo afecta la latencia de la API de Privacy Sandbox a las Core Web Vitals? | Mantener la latencia al mínimo es un objetivo de diseño clave de las APIs de Privacy Sandbox. Nuestra expectativa actual es que la latencia de la API tenga un impacto mínimo en las métricas principales de la Web de un sitio, ya que la mayoría de las APIs se llaman después de la renderización inicial del sitio web. Seguimos supervisando y realizando mejoras para reducir aún más la latencia de cada una de las APIs, y recomendamos que se realicen pruebas y comentarios continuos. La latencia en el proceso de ofertas en tiempo real se aborda en la sección de FLEDGE, en "Rendimiento de las subastas de FLEDGE". |
| Interoperabilidad | Inquietudes sobre la interoperabilidad con otras posibles soluciones | El objetivo de Privacy Sandbox es proteger a los usuarios contra el seguimiento entre sitios y, al mismo tiempo, respaldar las necesidades del ecosistema web. Para lograrlo, nos alejamos de las tecnologías heredadas de los navegadores que permiten ese seguimiento entre sitios, como las cookies de terceros, y proporcionamos en su lugar nuevas tecnologías diseñadas específicamente para admitir casos de uso específicos. Las propuestas de Privacy Sandbox mejoran la privacidad limitando los datos que salen del dispositivo de un usuario. Las propuestas no imponen restricciones técnicas a la capacidad de un sitio web para compartir o procesar datos una vez que se recopilan desde el navegador. Por lo tanto, las tecnologías no impiden que las empresas celebren acuerdos de “administración de datos” ni cualquier otra relación contractual similar. Del mismo modo, no restringen la capacidad de los usuarios de dar su consentimiento para compartir sus datos por otros medios. Para mayor claridad, Google se comprometió a aplicar las tecnologías de Privacy Sandbox de la misma manera a todos los sitios web, incluidos los productos y servicios de Google. Después de que Chrome finalice la compatibilidad con las cookies de terceros, los compromisos también dejan en claro que Google no usará otros datos personales, como el historial de navegación sincronizado de Chrome de los usuarios, para realizar un seguimiento de los usuarios con el objetivo de segmentar o medir la publicidad digital. |
Muestra anuncios y contenido relevantes
Temas
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Impacto en la clasificación de la Búsqueda de Google | Consulta sobre si la compatibilidad de un sitio web con la API de Topics se usará como un indicador potencial para la clasificación de los resultados de la Búsqueda de Google | Algunos sitios web pueden inhabilitar la API de Topics. El equipo de Privacy Sandbox no coordinó ni solicitó a la organización de Búsqueda que use la clasificación de páginas como incentivo para que los sitios web adopten la API de Topics. Google confirmó a la CMA que la Búsqueda de Google no usará la decisión de un sitio de inhabilitar la API de Topics como un indicador de clasificación. |
| Clasificador de temas | Agrega la URL y el contenido de la página, además del nombre de host, para determinar el tema de una página web y mejorar la utilidad para varias partes interesadas. | Actualmente, el historial de navegación de un usuario se clasifica con los nombres de host de un sitio web. Chrome sigue evaluando opciones para considerar los metadatos a nivel de la página (como todos o algunos componentes de la URL o el contenido de la página) en la clasificación de temas. Cualquier mejora de utilidad debe sopesarse con los riesgos de privacidad y abuso. Por ejemplo, en lo que respecta a los metadatos en particular, algunos de los riesgos incluyen los siguientes: - Sitios que modifican los metadatos a nivel de la página como método para codificar diferentes significados (y potencialmente sensibles) en los temas - Sitios que modifican los metadatos a nivel de la página para tergiversar sus temas con fines de lucro - Sitios que modifican los metadatos a nivel de la página de forma dinámica como método de seguimiento entre sitios |
| (También se informó en el tercer trimestre) Impacto en los indicadores propios |
El indicador de temas puede ser muy valioso y, como resultado, desvaloriza otros indicadores basados en intereses propios. | Nuestra respuesta no ha cambiado desde la pregunta 3: "Creemos que la publicidad basada en intereses es un caso de uso importante para la Web, y Topics está diseñado para admitir ese caso de uso. Como se describe [en nuestro informe del tercer trimestre], otras partes interesadas del ecosistema expresaron su preocupación de que los temas podrían no ser lo suficientemente útiles como para proporcionar valor. En todos los casos, las mejoras en la taxonomía son un esfuerzo continuo, y esperamos que la taxonomía evolucione con las pruebas y las entradas del ecosistema". |
| Actualiza la taxonomía | ¿Cómo se actualizará la lista de taxonomías? | Estamos buscando activamente comentarios sobre la taxonomía que sería más útil para el ecosistema. La taxonomía incluida en la propuesta inicial de la API de Topics se diseñó para permitir pruebas funcionales. Chrome está considerando activamente varios enfoques para actualizar la taxonomía. Por ejemplo, Chrome puede utilizar un concepto de valor comercial para cada tema para determinar qué categoría incluir en iteraciones futuras. |
| Rendimiento del clasificador regional de temas | El clasificador de temas tiene un rendimiento bajo en los dominios regionales | La mejora del clasificador es un esfuerzo continuo. En función de los comentarios que recibimos, una posibilidad que estamos considerando es expandir la lista de anulación de Topics, que, según nuestro análisis, aumentará la cobertura global y mejorará la precisión. Para explicarlo, la clasificación de la API de Topics tiene dos componentes relevantes: (1) una lista de anulación que contiene los 10,000 sitios principales y sus temas, y (2) un modelo de IA integrado en el dispositivo que clasifica los nombres de host en temas. Si expandimos la lista de anulación (1), podemos mejorar el rendimiento de la clasificación para aquellas regiones en las que el clasificador podría tener un rendimiento bajo. |
| Época de una semana | La época de una semana es demasiado larga para los usuarios que desean tomar decisiones a corto plazo. | Estamos analizando activamente cuál debería ser la duración adecuada de la época y recibimos con gusto más comentarios sobre cuál sería una época mejor para el ecosistema. |
| Recuperación de encabezados HTTP | Inquietud por la falta de información sobre la recuperación de temas de los encabezados HTTP | Estamos trabajando en los encabezados y en fetch(). También tenemos información disponible aquí. También agregamos información sobre skipObservation a la explicación. |
| El objetivo de Topics es ayudar solo a los anunciantes, no a los usuarios. | Al parecer, Topics/Privacy Sandbox es un enfoque centrado en la industria. El beneficio para los usuarios no es tan claro como el beneficio para la industria. | Creemos que el beneficio para los usuarios es que Topics admite anuncios basados en intereses que mantienen la Web libre y abierta, y también creemos que mejora significativamente la privacidad en comparación con las cookies de terceros. Quitar las cookies de terceros sin alternativas viables puede afectar negativamente a los publicadores y generar enfoques más deficientes, menos privados y no transparentes, que los usuarios no pueden restablecer ni controlar de forma realista. Muchas empresas están probando activamente las APIs de Topics y Sandbox, y nos comprometemos a proporcionar las herramientas para avanzar en la privacidad y respaldar la Web. Recientemente, el grupo de arquitectura técnica del W3C publicó su opinión inicial sobre la API de Topics, a la que responderemos públicamente. En esta etapa, dado que Google recibió preguntas del ecosistema sobre lo que esta revisión podría implicar para el desarrollo y el lanzamiento de la API de Topics, nos gustaría reafirmar nuestro plan de ponerla a disposición de Chrome estable este año. Si bien Google agradece los aportes del Grupo de Arquitectura Técnica del W3C, considera de suma importancia continuar con los esfuerzos para desarrollar y probar Topics en consulta con la CMA y el ecosistema. |
| Filtración de datos | Preocupación por la posibilidad de que los temas se filtren a otros sitios sin permiso | El diseño de la API de Topics hace que sea muy improbable que se filtren los datos de un solo publicador (o incluso de un grupo más pequeño de publicadores) de ninguna manera. Los sitios web de los publicadores también tienen el control total de la API de Topics y pueden prohibir el acceso a esta API mediante la política de permisos. |
| Falta de anunciantes para realizar pruebas | Los publicadores se preocupan porque, en la actualidad, no pueden demostrar el valor de Topics a los anunciantes. | En la segunda mitad de 2023, planeamos tener todas las APIs relacionadas con los anuncios disponibles para las pruebas de integración y permitir el análisis del ecosistema del valor de Topics para los anunciantes. La CMA supervisará las pruebas y la publicación de los resultados, y revisará los datos, el análisis y la metodología. Se recomienda que el ecosistema comparta comentarios con Google y la CMA. |
| Topics y FLEDGE | Solicita más información para usar Topics en la lógica de ofertas de FLEDGE | Es posible usar temas dentro de la lógica de ofertas de FLEDGE. También se está preparando una guía de integración que incluirá detalles adicionales sobre la implementación. |
| Clasificación personalizada para el llamador de temas | Permite que el emisor personalice las clasificaciones | El desafío con la clasificación o los valores de temas personalizados para cada tecnología publicitaria es que esto podría convertirse en un mecanismo a través del cual una tecnología publicitaria pueda influir en los temas que se muestran, por lo que se convierte en un vector de huellas digitales. |
| Lista de prioridades de los emisores de temas | Permite que los llamadores proporcionen una lista de prioridad clasificada de los temas que la API de Topics mostrará en función de la elegibilidad. | Actualmente, estamos analizando esta idea en más detalle y recibimos con gusto más aportes. |
FLEDGE
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Google Ad Manager | Inquietud por el hecho de que Google Ad Manager es el encargado de tomar la decisión final en las subastas de FLEDGE y favorecería a las etiquetas Google Publisher Tag y Google Ad Manager. | FLEDGE permite que cada publicador elija la estructura de la subasta, incluida la elección de vendedores de componentes y de nivel superior. Cada comprador y vendedor en una subasta de componentes sabe quién es el vendedor de nivel superior y puede elegir si ofertar o no. |
| No hay suficientes participantes que prueben FLEDGE | Solicitud para alentar a más empresas a probar FLEDGE, por ejemplo, mejorando la funcionalidad de la API y desalentando las alternativas invasivas de la privacidad, como la creación de huellas digitales | Privacy Sandbox se está implementando por etapas, en estrecha colaboración con la orientación de la CMA y la ICO, y las pruebas funcionales de FLEDGE demostraron la estabilidad y la capacidad necesarias. Google sigue alentando al ecosistema a probar las APIs de Sandbox y, recientemente, publicó la documentación "Maximiza la relevancia de los anuncios" para mostrar cómo FLEDGE y otras APIs pueden ayudar a admitir casos de uso fundamentales para la industria publicitaria después de que dejen de estar disponibles las cookies de terceros. Otras partes de Privacy Sandbox ya admiten mitigaciones para cubrir el seguimiento (consulta UA-CH, Protección de IP y Mitigaciones de seguimiento de rebotes) y seguirán mejorando con el tiempo. El objetivo de Google no es que FLEDGE sea la única solución de segmentación viable, sino que se mantiene comprometido a trabajar en asociación con la industria y los reguladores para impulsar las mejores tecnologías publicitarias que preserven la privacidad en el navegador Chrome. |
| Casos de uso de aprendizaje automático | Más orientación sobre cómo se admitirán los casos de uso de aprendizaje automático para entrenar algoritmos de ofertas de subastas en FLEDGE y los informes de atribución | Reconocemos la necesidad de ayudar a los verificadores a encontrar las formas más útiles de aplicar las tecnologías de Privacy Sandbox. Comenzamos a publicar orientación específica relacionada con el uso de los diversos aspectos de las APIs de Privacy Sandbox como entradas para el aprendizaje automático. En el artículo más reciente, Maximiza la relevancia de los anuncios, se explica cómo la industria publicitaria puede usar estos indicadores para el aprendizaje automático, y planeamos seguir publicando este tipo de orientación en el futuro. |
| Cómo consultar el servidor de par clave-valor (K/V) de FLEDGE | ¿Por qué el servidor K/V se puede consultar de forma pública? | El objetivo del servidor de par clave-valor es proporcionar indicadores en tiempo real a las subastas de FLEDGE. Por lo tanto, se debe poder acceder al servidor de K/V desde donde se ejecutan esas subastas de FLEDGE, que se encuentran en los dispositivos del usuario, lo que requiere que esté disponible públicamente. Solo una parte que ya tenga la clave puede recuperar un valor almacenado en el servidor de pares clave-valor. Por lo tanto, si una tecnología publicitaria solo proporciona las claves a los navegadores que están en el grupo de intereses y no usa claves que se puedan adivinar de forma aleatoria, solo los navegadores que necesiten el valor para ejecutar su subasta podrán recuperarlo. |
| ¿Cómo se realiza la segmentación por fecha y hora? | Compatibilidad con objetos de fecha en la función de lógica de ofertas | Hay distintas formas de hacerlo: Los compradores pueden pedirles a los vendedores que proporcionen la fecha y hora actuales, y los vendedores deberían poder proporcionar esta información a todos los compradores con facilidad. Los compradores también pueden proporcionar la fecha y la hora en su respuesta de par clave-valor en tiempo real. Por último, los compradores pueden proporcionar la fecha y la hora como parte de su respuesta contextual en los indicadores por comprador, que un vendedor podría pasar a la secuencia de comandos generateBid del comprador. |
| Preferencias de usuario | Los usuarios pueden elegir bloquear las creatividades por anunciante cuando se publican a través de FLEDGE o soluciones alternativas. | Los usuarios pueden inhabilitar las APIs de Google Ads en Chrome. En el caso de los anuncios específicos, la tecnología publicitaria relevante es la parte mejor posicionada para ofrecer controles sobre qué creatividades se muestran o cómo se seleccionan. |
| Cronogramas más claros | Solicita más información sobre la disponibilidad de las protecciones de privacidad en FLEDGE, como la solicitud de marcos delimitados. | Planeamos publicar cronogramas más detallados en el primer trimestre. |
| Denuncia de confusión | Solicitar más claridad sobre cómo funcionarán los informes de FLEDGE con otras APIs, como Fenced Frames y la API de Private Aggregation | Planeamos publicar una explicación sobre la interacción entre la API de Private Aggregation, FLEDGE y Fenced Frames en las próximas semanas. |
| Ofertas en tiempo real y FLEDGE | Orientación sobre cómo se integra FLEDGE con las ofertas en tiempo real estándar. | Los dos aspectos principales que complican la capacidad de una tecnología publicitaria para realizar ofertas en tiempo real son el acceso a los datos a nivel del evento y la integración más sencilla en la ARA. Planeamos enviar actualizaciones y explicaciones sobre ambos en el 1ᵉʳ trimestre. |
| Rendimiento de las subastas de FLEDGE | Informe de los verificadores que indica que las subastas de FLEDGE tienen una latencia alta | Agradecemos los informes de los verificadores que comparten sus resultados y casos de uso, y compartimos algunas sugerencias sobre cómo mejorar el rendimiento de FLEDGE. En paralelo, agregamos herramientas al navegador que permiten a los desarrolladores diagnosticar mejor qué hace que las subastas sean lentas y abordamos de forma sistemática las fuentes principales de latencia observadas. Entre las mejoras recientes, se incluyen tiempos de espera para subastas lentas, una técnica de filtrado rápido de ofertantes, una forma de volver a usar worklets de FLEDGE para evitar pagar costos de inicio y un trabajo continuo para permitir que la solicitud de anuncio contextual se ejecute en paralelo con el tiempo de inicio de FLEDGE y las recuperaciones de red. Esperamos que la optimización de la latencia continúe como una conversación continua entre los desarrolladores de Chrome y los verificadores de FLEDGE en función de su experiencia real con la API. |
| Límite de memoria del tamaño del grupo de intereses | Solicita aumentar el límite de tamaño de un solo grupo de intereses de 50 KB. | Estamos considerando activamente la solicitud y buscamos comentarios sobre qué valor de límite funciona. |
| Combinación de los datos publicados de FLEDGE con la cookie propia | ¿FLEDGE admitirá la integración con los datos de origen de un anunciante? | FLEDGE se creó para admitir la publicidad con los datos de origen que ya tiene un anunciante. Sin embargo, FLEDGE no tiene la intención de permitir que un anunciante conozca el comportamiento de navegación de una persona en ningún sitio web que no sea el suyo. Vincular el comportamiento de navegación fuera del sitio a los datos de origen va en contra de los objetivos de Privacy Sandbox. Planeamos compartir guías de integración con más detalles sobre cómo FLEDGE admitirá la integración con datos propios en las próximas semanas. |
| Valor de k-anonimato | ¿Cómo se decidirá el valor de "K" a "k-anon" y se publicará? | El valor de "K" aún está en proceso de definición, y compartiremos más información a medida que se desarrollen nuestros planes. Nos interesa obtener más información sobre cómo un valor de k desconocido puede dificultar la preparación de FLEDGE y el alcance del entrenamiento de modelos de AA. Aceptamos comentarios adicionales sobre este tema. |
| Compatibilidad con varias SSP | ¿Cómo se admitirán varias SSP en FLEDGE? | FLEDGE admite subastas de varios vendedores, como se indica en esta propuesta. |
| Visibilidad de la lógica de ofertas | Preocupación por que la lógica de ofertas de la DSP se exponga en JavaScript | Con la lógica de ofertas de diseño actual, otras personas pueden acceder a JavaScript, pero recibimos con gusto más comentarios sobre por qué esto podría ser una fuente de preocupación para las DSP. |
| prebid.js | ¿Cuál es el cronograma para admitir prebid.js en FLEDGE? | Solo las versiones 7.14 y posteriores de Prebid.js admiten el módulo FLEDGE. Los publicadores interesados en realizar pruebas deben agregar el módulo de FLEDGE y actualizar su instancia de Prebid. |
| Funciones definidas por el usuario en FLEDGE | ¿Cómo se admitirán las funciones definidas por el usuario (UDF) en FLEDGE? Estas son funciones que los usuarios finales pueden programar para extender la funcionalidad de la API. | Consulta la explicación aquí. Todavía estamos definiendo este aspecto, por lo que recibimos con gusto comentarios adicionales sobre los casos de uso. |
| Se flexibiliza la restricción de origen en los recursos de los grupos de intereses | Solicitar que se relaje la restricción de origen en los recursos del grupo de intereses para habilitar ciertos casos de uso de la tecnología publicitaria | En la implementación actual de FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl y trustedBiddingSignalsUrl deben tener el mismo origen que el propietario del grupo de intereses.La restricción existe para evitar que los atacantes realicen ciertos exploits, como se explica aquí. |
| Ownership | Solicitud para limitar si una tecnología publicitaria puede usar joinInterestGroup para los mismos grupos de interés en todos los sitios | Nos enfocamos en cómo se usan los públicos, no en cómo se crean. Estamos analizando posibles enfoques y recibimos con gusto más aportes. |
| Vencimiento de la clave del servidor de par clave-valor | Discusión sobre la eliminación de claves de servidor una vez que venzan los grupos de intereses correspondientes | Estamos explorando formas de controlar el vencimiento de las claves y buscamos comentarios. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Tráfico de pruebas de origen | El tráfico actual de la prueba de origen no es suficiente para realizar pruebas de utilidad. | Las pruebas de origen actuales están diseñadas para que los participantes del ecosistema realicen pruebas funcionales para garantizar que la API funcione según lo previsto. Entendemos que se requerirán mayores cantidades de tráfico para realizar pruebas de utilidad una vez que el desarrollo de las diversas APIs de Privacy Sandbox esté más maduro. Según el cronograma de pruebas actual, esto ocurrirá cuando se alcance la disponibilidad general (es decir, cuando se lancen las tecnologías para los casos de uso y estén disponibles para el 100% del tráfico de Chrome) en el tercer trimestre de 2023 (consulta nuestro cronograma actualizado en privacysandbox.com). Aceptamos cualquier comentario adicional sobre las pruebas de casos de uso que requieran tráfico adicional. |
| Superposición de funciones de diferentes APIs de medición de Privacy Sandbox | Las preocupaciones sobre la superposición de varios enfoques de medición a través de Privacy Sandbox aumentarán la complejidad, por ejemplo, la API de Attribution Reporting y la API de Private Aggregation. | Estamos trabajando para mejorar la documentación y aclarar los diferentes casos de uso de las APIs. Agradecemos los comentarios adicionales sobre las áreas que carecen de explicación. Por ejemplo, la API de Attribution Reporting está diseñada específicamente para admitir la medición de conversiones, mientras que la API de Private Aggregation y Shared Storage son APIs de uso general diseñadas para admitir una gama más amplia de casos de uso de medición entre sitios. |
| Vuelve a intentar la solicitud de informe fallida | Se aclaró cuántas veces se intenta realizar una solicitud de informe si falla. | Publicamos una guía sobre este tema. En resumen, los informes solo se envían cuando el navegador está en ejecución o en línea. Después de la primera falla de envío, se vuelve a intentar el informe después de 5 minutos. Después del segundo error, se vuelve a intentar el informe después de 15 minutos. Después de eso, no se enviará el aviso. |
| Retraso en los informes | ¿Cuál es el retraso de los informes esperado? | Queremos escuchar más comentarios del ecosistema sobre las demoras en los informes que experimentan mientras recopilamos datos para evaluarlas en paralelo. |
| Renderización previa de páginas | ¿La atribución de ARA funcionará en las páginas de renderización previa? | El registro de atribución se aplaza en las páginas con renderización previa hasta que se produce la activación (se produce el clic o la vista reales). Esto significa que diferiremos el ping de la solicitud "attributionsrc". |
| Cómo medir la efectividad de conversiones | Cómo medir el aumento de conversiones con pruebas A/B en el mismo dominio | Los sitios web pueden medir el aumento de conversiones con pruebas A/B en el mismo dominio a través de los informes de atribución. Pueden codificar sus parámetros A/B como claves con la API de agregación y, luego, recibir informes de resumen de los valores de conversión por esos segmentos de claves. |
| Conversiones multidominio (también se registran en el tercer trimestre) | Cómo hacer un seguimiento de las conversiones multidominio, como con 2 o más destinos | Actualización del cuarto trimestre: Publicamos una propuesta para quitar la restricción de destino de la página de destino que permite hacer un seguimiento de las conversaciones entre dominios. Esta propuesta se implementó. |
| (También se informó en el tercer trimestre) Configuración de vencimiento en el informe de conversiones |
Solicitud para admitir el filtro de informes o el vencimiento por menos de 24 horas | Actualización del cuarto trimestre: Compartimos esta solicitud de extracción , que desacoplará los períodos de vencimiento y de informes para mitigar la compensación entre el retraso en los informes y el vencimiento de las conversiones. Ahora se lanzó en M110. |
| Fraude y abuso | Solicitudes de anunciantes y especialistas en marketing para poder segmentar y agregar datos en función de los sitios de publicadores en los que se publican sus anuncios, lo que también proporcionaría más estadísticas sobre posibles prácticas publicitarias fraudulentas | Estos comentarios se están analizando de forma activa aquí y recibimos con gusto más aportes. |
| (También se informó en el tercer trimestre) Retraso en los informes a nivel del evento | El retraso de 2 a 30 días en los informes a nivel del evento puede ser demasiado largo para ciertos casos de uso. | Los informes a nivel del evento tienen ventanas de informes predeterminadas de 2, 7 y 30 días. Esto se puede modificar con el parámetro "expiry". Las tecnologías publicitarias podrían configurar el vencimiento, con un mínimo de 1 día, para obtener informes potenciales en menos de 2 días. Limitamos el nivel de detalle de los vencimientos a 1 día como mecanismo de protección de la privacidad, ya que los informes más detallados podrían generar ataques de sincronización. Además, permitimos configurar parámetros de "vencimiento" independientes para los informes agregados y a nivel del evento. Obtén más información aquí. Además, Google Ads no obtendrá ninguna ventana de informes especiales que otras tecnologías publicitarias no obtengan a través de la API de Attribution Reporting. |
| Mismo requisito de origen de informes | Solicitud para quitar el requisito de que el origen del registro de la fuente sea el mismo que el del registro de conversiones | Proponemos usar redireccionamientos HTTP para delegar el registro y resolver este caso de uso. Agradecemos cualquier comentario adicional sobre la nueva guía. |
| Seguimiento de conversiones | Es necesario diferenciar si la conversión ocurrió antes o después de ciertas horas establecidas por el anunciante. | La API de Attribution Reporting admite la configuración de una ventana de vencimiento y una prioridad para la atribución de la fuente. Si utilizas ambos, técnicamente será posible atribuir una conversión que se produjo dentro de una ventana de X días por separado de una conversión que se produjo después de X. |
| Simulación de ruido | Solicitar la posibilidad de simular el volumen diferente de conversiones por bucket para comprender el impacto en los anunciantes con menos conversiones | Estamos buscando agregar formas de simular esto en versiones futuras de Noise Lab. Agradecemos cualquier comentario adicional. |
| Informes en dispositivos móviles | ¿Se enviará el informe cuando Chrome se ejecute en segundo plano en dispositivos móviles? | Por el momento, incluso en dispositivos móviles, el informe no se enviará cuando Chrome esté en segundo plano. Es probable que esto cambie cuando la API se integre en Privacy Sandbox de Android. Obtén más información aquí. Ten en cuenta que Privacy Sandbox de Android no forma parte de los compromisos aceptados por la CMA. |
| Disponibilidad de los datos | Preocupaciones sobre el acceso adicional de Google a los datos a través de las APIs de Privacy Sandbox | En primer lugar, Google Ads no recibe ningún acceso preferencial a los datos de la API de Attribution Reporting ni de otras APIs de Privacy Sandbox. Este problema también se aborda en la sección Comentarios generales, en "Interoperabilidad", que incluye más detalles sobre los compromisos de Google. En segundo lugar, en cuanto a la diferencia entre los sitios más grandes y los más pequeños, Google reconoce que las protecciones de la privacidad basadas en el ruido pueden tener un mayor impacto en los segmentos de datos más pequeños. Sin embargo, existen algunas mitigaciones posibles: por ejemplo, métodos como la agregación durante períodos más largos resolverían este problema. Dicho esto, aún no está claro si las conclusiones basadas en segmentos de datos muy pequeños (como una o dos compras) son significativas para los anunciantes. Durante la prueba de origen, Google animó a los verificadores a aprovechar la capacidad de experimentar con una amplia variedad de parámetros de privacidad y ruido para que puedan proporcionar comentarios más específicos sobre este problema. |
Limita el seguimiento encubierto
Reducción de usuario-agente
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Retrasa la reducción de usuario-agente hasta que el ecosistema web esté más listo | No hay tiempo suficiente para adaptarse a los próximos cambios de reducción de User-Agent. | Responderemos estos comentarios en el informe completo, en "Preocupaciones de las partes interesadas", en la sección titulada "Interacción de Google con la CMA". |
| Retrasa la reducción de usuario-agente hasta que el ecosistema web esté más listo | Solicitud para retrasar el lanzamiento de la reducción de usuario-agente hasta que se implementen los usuarios-agentes estructurados (SUA) | El equipo de Google Ads propuso la adición de User-Agent estructurado (consulta la especificación) a OpenRTB en octubre de 2021, y se incorporó en la actualización de la especificación 2.6 que se lanzó en abril de 2022. Tenemos algunas evidencias de que la SUA está implementada y disponible en la actualidad, como se muestra en la entrada de blog de Scientia Mobile, en la que se explica cómo usar UA-CH y la API de WURFL para crear una SUA. |
###
Sugerencias de clientes de usuario-agente
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Prueba UA-CH con otras técnicas de seguimiento no oculto | Orientación para probar todas las APIs de Privacy Sandbox y las técnicas de creación de huellas digitales propuestas en conjunto en un enfoque integral | Nuestro plan de pruebas se diseñó para reflejar los cronogramas asíncronos para desarrollar algunas de las medidas contra la creación de huellas digitales, en comparación con el resto de las propuestas de Sandbox. Se aborda la realidad de que algunas medidas contra la creación de huellas digitales (es decir, el presupuesto de privacidad, la protección de IP y las mitigaciones de seguimiento de rebotes) estarán completamente desarrolladas y listas para lanzarse a la disponibilidad general solo después de que dejen de estar disponibles las cookies de terceros. Si bien esas medidas contra la creación de huellas digitales no se incluirán en las pruebas cuantitativas, estarán sujetas a una evaluación cualitativa en función de los hechos disponibles en el momento de la inactividad. |
| (También se informa en el segundo trimestre) Rendimiento |
Preocupaciones sobre la latencia de obtener sugerencias a través de Critical-CH (en la primera carga de la página) | Consulta la sección dedicada a UA-CH a continuación |
| Comentarios insuficientes | Es posible que los comentarios del ecosistema sobre el cambio de UA a CH no sean suficientes, lo que genera preocupaciones sobre la falta de conocimiento del ecosistema. | Hemos estado compartiendo nuestros planes de forma proactiva para garantizar un lanzamiento cuidadoso que minimice las interrupciones. Los planes de reducción de usuario-agente y la API de UA-CH se presentaron al grupo comunitario de prevención de fraudes del W3C el 18 de marzo de 2022 y al grupo de trabajo de pagos web y al grupo de interés de seguridad de pagos web el 20 de enero de 2022. No se plantearon preocupaciones significativas durante ni después de las presentaciones. Google se comunicó de forma proactiva con más de 100 operadores de sitios para obtener comentarios. Además, Google también usó los canales de Blink-Dev para comunicar el lanzamiento de la reducción del usuario-agente de forma pública en función de los comentarios de las partes interesadas del ecosistema. |
| Tiempos | Inquietudes sobre los plazos de lanzamiento y el nivel de preparación de la industria | Consulta la sección dedicada a UA-CH a continuación |
| Estado de la plataforma de Chrome | Se solicitó que se actualizara la página chromestatus para UA-CH. | La entrada de chromestatus se actualizó el 19 de diciembre a "Indicios mixtos". |
IP Protection (antes Gnatcatcher)
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Habilita o inhabilita la función | ¿La privacidad de la dirección IP es optativa o no? | Nuestro objetivo es proporcionar Protección de IP a todos los usuarios. Con ese objetivo en mente, actualmente estamos evaluando las opciones de elección del usuario para la protección de IP. |
| Caso de uso de la dirección IP para los datos de origen | ¿Es posible usar direcciones IP para unir los recorridos de los usuarios en dominios propios después de la Protección de IP? | Como se publicó anteriormente, la Protección de IP se enfocará inicialmente en el seguimiento en el contexto de terceros, lo que significa que los dominios propios no se verán afectados. |
| Casos de uso de la tecnología publicitaria | ¿Cómo pueden las empresas configurar medidas contra el fraude con IP Protection? | Reconocemos la importancia de la dirección IP como indicador para las iniciativas contra el fraude en la Web actual. Como parte de nuestros compromisos con la CMA (párrafo 20), indicamos que no implementaremos la Protección de IP sin realizar esfuerzos razonables para respaldar la capacidad de los sitios web de realizar iniciativas contra el spam y el fraude. Una de nuestras prioridades principales es comprender cómo la protección de IP afecta los casos de uso y las capacidades de detección contra el fraude, de modo que podamos invertir más en tecnologías que preserven la privacidad y ayuden a las empresas a preservar la seguridad web. Fomentamos los comentarios y las opiniones sobre nuevas propuestas que tengan como objetivo respaldar las necesidades de las empresas de seguridad y prevención de fraudes, incluso a medida que los indicadores cambian con el tiempo. |
| Fraude y abuso | ¿La protección de IP incluye la protección contra la denegación del servicio (DoS)? | Nos comprometemos a mejorar la privacidad y, al mismo tiempo, mantener la seguridad de la Web. Proteger contra los ataques de denegación de servicio es un caso de uso importante contra el abuso para el que se debe diseñar. Esperamos minimizar el impacto en las protecciones contra DoS a través del diseño de la protección de IP y de nuevas soluciones contra el abuso. Debido a que la Protección de IP se enfoca inicialmente en los servicios incorporados de terceros, algunas partes interesadas indicaron que debería tener un impacto limitado en la protección contra DoS de los sitios propios. Sin embargo, seguimos solicitando comentarios del público para evaluar el riesgo de los casos de uso de DoS, en particular para los servicios incorporados de terceros. En paralelo, estamos explorando mecanismos de comentarios sobre abusos y bloqueo de clientes que permitan que un sitio o servicio bloquee a un usuario que envía spam sin identificarlo. |
| Filtrado de contenido | Filtrado de contenido con Protección de IP | Las diferentes empresas tienen necesidades diferentes en cuanto al filtrado de contenido y la personalización de la experiencia del usuario. Actualmente, muchos de estos casos de uso no dependen de las direcciones IP y, por lo tanto, no deberían verse afectados por la Protección de IP. Por ejemplo, un publicador que desee personalizar su contenido y generar más participación podría usar cookies propias o cookies de terceros particionadas (CHIP) para comprender los intereses de un usuario y sus interacciones anteriores con el publicador. O bien, un socio de tecnología publicitaria enfocado en publicar el anuncio correcto para el usuario correcto puede incorporar FLEDGE y Topics, por ejemplo, para publicar resultados de anuncios similares a los que obtienen actualmente con cookies de terceros o con otras tecnologías de seguimiento entre sitios. También estamos explorando la creación de nuevas funciones que preserven la privacidad en la Protección de IP, como la geolocalización aproximada, para admitir aún más el filtrado de contenido en los casos en que los mecanismos existentes sean insuficientes. Agradecemos los comentarios adicionales sobre los casos de uso de filtrado de contenido que podrían verse afectados por la Protección de IP. |
| (También se informó en el tercer trimestre) Casos de uso de la geolocalización |
La Protección de IP puede impedir que funcionen casos de uso legítimos de la ubicación geográfica en el futuro, como la personalización de contenido basada en la ubicación geográfica. | Actualización del cuarto trimestre: Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos de las direcciones IP. Estamos buscando comentarios del ecosistema sobre el nivel de detalle de la geolocalización por IP aquí. |
Privacy Budget
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Documentación más clara | Más ejemplos para que las partes interesadas puedan anticiparse a cómo se pueden limitar las acciones una vez que se implemente el presupuesto de privacidad | La propuesta de Privacy Budget aún está en debate y ningún navegador la implementó. La fecha más antigua de disponibilidad ajustada representa la fecha más antigua en la que se podría aplicar el presupuesto de privacidad. Esto no sucederá antes de la eliminación de las cookies de terceros en 2024. Por el momento, no tenemos documentación adicional para compartir. Compartiremos más detalles sobre la propuesta cuando esté más definida. Mientras tanto, invitamos a las partes interesadas a compartir sus comentarios que ayuden en el desarrollo de la propuesta. |
Fortalecimiento de los límites de la privacidad entre sitios
Conjuntos propios
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Límite de dominios (también se informó en el tercer trimestre) | Solicitud para expandir la cantidad de dominios asociados | Actualización del cuarto trimestre: Lanzamos FPS para pruebas locales, incluido un proceso de envío de conjunto simulado en GitHub y una marca para probar rSA y rSAFor de forma local. También organizamos dos reuniones abiertas para desarrolladores sobre FPS para seguir respondiendo preguntas sobre los casos de uso del subconjunto asociado. Recomendamos a los desarrolladores que prueben la funcionalidad de FPS para enviar comentarios sobre cómo el límite de dominios del subconjunto asociado afectaría la usabilidad de FPS para sus casos de uso. En las llamadas de WICG, aclaramos que Chrome se compromete a proporcionar una solución utilizable que también tenga en cuenta los intereses de privacidad de los usuarios. En ese sentido, agradecemos los comentarios de la comunidad sobre casos de uso específicos que podrían verse afectados por el límite de dominios, de modo que el equipo pueda considerar formas de abordar estos casos de uso y, al mismo tiempo, seguir protegiendo la privacidad de los usuarios. |
| Solicita más detalles sobre las medidas de mitigación de abusos | ¿Qué sucede si se agrega un dominio a un conjunto para el que no se otorgó consentimiento? | El 2 de diciembre de 2022, publicamos los lineamientos de envío de conjuntos propios aquí. Como se explica en los lineamientos de envío, cualquier administración de cambios establecidos seguirá y respetará un proceso de validación en GitHub, incluida la validación de la propiedad, lo que debería mitigar este riesgo. |
| Mitigación de abusos | Preocupación por el posible aprovechamiento de las formaciones de conjuntos propios | Estamos buscando formas de expandir las verificaciones técnicas para los tipos de subconjuntos y buscamos activamente aportes adicionales de la comunidad aquí. |
| Casos de uso de Google Ads | Preguntas sobre si se deben usar conjuntos propios para admitir la segmentación de anuncios | No intentamos admitir casos de uso de segmentación de Google Ads para conjuntos propios y te recomendamos que uses las APIs de Google Ads disponibles para esos casos de uso. |
| Política (también se informó en el tercer trimestre) | Inquietud por el hecho de que el FPS no es coherente con los compromisos de la CMA en relación con la "Legislación de Protección de Datos Aplicable", ya que el GDPR no impone un límite a la cantidad de sitios en un conjunto, mientras que el FPS prevé un límite de 3. | Nuestra respuesta no ha cambiado desde el tercer trimestre: "Google sigue comprometiéndose con la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia mediante la autopreferencia de la propia empresa de Google y a tener en cuenta el impacto en la competencia en la publicidad digital, los publicadores y los anunciantes, así como el impacto en los resultados de la privacidad y el cumplimiento de los principios de protección de datos establecidos en la legislación aplicable de protección de datos. La preocupación expresada no revela ninguna incompatibilidad con el RGPD. Seguimos trabajando en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos". |
| Propuesta alternativa | Conjuntos validados por el GDPR | Además de los comentarios que proporcionó el ecosistema sobre la propuesta de adoptar "conjuntos validados por el RGPD", Chrome tiene inquietudes sobre las siguientes limitaciones de esta propuesta alternativa:
Desde que se planteó esta alternativa, Chrome actualizó la propuesta de conjuntos propios y publicó lineamientos de envío para crear conjuntos nuevos. |
API de Fenced Frames
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Restricciones de marcos protegidos durante la OT | ¿Cuáles son las restricciones actuales de Fenced Frames para el período de la Prueba de origen? | Estamos trabajando en la documentación sobre las restricciones y el estado de implementación, y planeamos compartirla durante el primer trimestre de 2023. |
| Varios anuncios en un solo marco de contenido protegido | Solicitud para mostrar varios anunciantes en un marco de contenido exclusivo en una subasta | Actualmente, no estamos desarrollando activamente esta solicitud, pero recibimos con gusto comentarios adicionales si los actores del ecosistema consideran que la función es importante. |
| Paquetes web | ¿Cuáles son los requisitos y la compatibilidad planificados para los paquetes web con marcos delimitados? | Actualmente, no tenemos información sobre si este será el requisito en el futuro. Cualquier cambio se anunciaría con anticipación y no se aplicaría antes de que se den de baja las cookies de terceros. Consulta esta explicación para conocer el estado actual. |
API de Shared Storage
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Almacenamiento compartido para la tecnología publicitaria | Incertidumbre en torno al uso del almacenamiento compartido para casos de uso de tecnología publicitaria | Las APIs de Shared Storage y Private Aggregation se pueden usar para diferentes tipos de mediciones que necesitan mediciones de almacenamiento entre sitios. Algunos ejemplos se indican aquí. Prevemos que los proveedores de soluciones de medición y DSP serán los principales integradores de los casos de uso de anuncios. |
CHIPs
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en el tercer trimestre) Requisito de partición | Se agregó un requisito de comportamiento explícito para el atributo "Partitioned" en las cookies propias. | Actualización del cuarto trimestre: Después de las discusiones en GitHub y las llamadas de PrivacyCG, el comportamiento en el que nos alineamos es que las cookies particionadas establecidas en las cookies propias usarán una clave de partición de (A,A), donde "A" es el sitio de nivel superior. Documentaremos este comportamiento en la explicación y la especificación. |
| Administración de cookies | ¿Existen herramientas para administrar o gobernar las cookies propias o de terceros? | Las Herramientas para desarrolladores de Chrome y NetLog se pueden usar para probar sitios con el bloqueo de cookies de terceros habilitado. Ambas herramientas informan cuando se bloquean las cookies debido a la configuración del usuario. Agradecemos los comentarios sobre qué tipo de sitios web de auditoría adicionales te gustaría ver. |
FedCM
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| La IdP requiere conocimiento de la RP para permitir una sesión. | Se produce un problema cuando un usuario intenta acceder al IdP de Feide desde dos RP diferentes. | Estamos analizando posibles soluciones para este problema. |
| Interoperabilidad | Inquietudes sobre el impacto de FedCM en la relación entre los usuarios y los sitios web a los que acceden con FedCM, y la "interoperabilidad" entre los sitios web | El objetivo de FedCM es seguir admitiendo los servicios de identidad federada que actualmente dependen de cookies de terceros una vez que se quiten de Chrome. Esperamos que FedCM sea solo una opción disponible para esos servicios. Los proveedores de identidad (IdP) y las partes de confianza (RP) pueden usar otras tecnologías que se adapten mejor a sus necesidades. Al parecer, las inquietudes sobre la relación entre el usuario y el RP y la "interoperabilidad" se deben a un malentendido de la propuesta de la FedCM. FedCM permite que las AC decidan qué información compartir con un RP y en qué formato, una vez que el usuario haya elegido acceder al sitio de ese RP. El MTC federal no requiere que las AC "creen un identificador seudónimo único para cada [RP] con el que se autentica el usuario". En cambio, FedCM está abierto para que cada IdP elija si compartir el identificador real del usuario, una versión de ese identificador por sitio o alguna otra versión de esta información. (La especificación de FedCM identifica la correlación entre sitios como un riesgo de privacidad asociado con la API y analiza los identificadores dirigidos (por sitio) como una posible mitigación. Sin embargo, la decisión de usar identificadores dirigidos queda a cargo de los IdP, no la impone el navegador). FedCM también permite que el usuario elija con respecto a la identidad. Por ejemplo, si un usuario tiene varias identidades con el mismo IdP (p.ej., un perfil de trabajo y un perfil personal), FedCM le brinda una forma de seleccionar cuál quiere usar para acceder al sitio del RP. Además, cada RP decide por sí mismo qué IdP admitir en su sitio. Un aspecto de esa decisión es considerar el mecanismo en el que se basa una AC, ya sea FedCM o una tecnología diferente. Una vez más, el navegador no dicta estas opciones para los RP o los IdP. |
Cómo combatir el spam y el fraude
API de Private State Tokens
| Tema de los comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cómo controlar bots | ¿Qué sucede si el emisor descubre que se emitieron tokens de estado privado a bots? | Para evitar que los tokens emitidos a los bots permanezcan en el ecosistema durante mucho tiempo, los emisores deben rotar las claves que usan para firmar tokens con regularidad, de modo que los tokens antiguos emitidos con una lógica de emisión potencialmente dañada caduquen y los sitios canjeen tokens más nuevos con una lógica de emisión actualizada. |
| Envíos de formularios en el mismo sitio | ¿Se pueden usar los tokens de estado privados para enviar formularios en el mismo sitio que involucren la navegación de página completa (es decir, Content-Type: application/x-www-form-urlencoded) en lugar de una solicitud de las APIs de fetch/XMLHttpRequest? | Actualmente, esto no se admite en la primera versión de los tokens de estado privado. Agradecemos los comentarios del ecosistema si hay una gran demanda para este caso de uso. |
| Verificación del servidor | Preguntas sobre si los tokens de estado privado se pueden verificar del servidor | Los tokens se canjean con el emisor, que luego crea un registro de canje que puede contener el token en sí o algún valor firmado derivado del token. Los servidores pueden usar ese registro de canje para verificar la autenticidad del token, y esperamos que los diferentes ecosistemas de emisores propongan diferentes estándares para interpretar sus registros de canje. |