Informe trimestral del cuarto trimestre de 2022 que resume los comentarios sobre el ecosistema recibidos sobre las propuestas de Privacy Sandbox y la respuesta de Chrome.
Como parte de sus compromisos con la CMA, Google acordó proporcionar públicamente informes trimestrales sobre el proceso de participación de las partes interesadas para sus propuestas de Privacy Sandbox (consulta los párrafos 12 y 17(c)(ii) de los Compromisos). Estos informes de resumen de comentarios de Privacy Sandbox se generan cuando se agregan los comentarios que recibe Chrome de distintas fuentes que se indican en la descripción general de los comentarios, incluidos, sin limitaciones, los problemas de GitHub, el formulario de comentarios disponible en privacysandbox.com, las reuniones con las partes interesadas de la industria y los foros de estándares web. Chrome agradece los comentarios recibidos del ecosistema y explora activamente formas de integrar el aprendizaje en las decisiones de diseño.
Los temas de comentarios se clasifican por prevalencia en cada API. Para ello, se agrega la cantidad de comentarios que recibió el equipo de Chrome sobre un tema determinado y se organiza en orden descendente de cantidad. Los temas de comentarios comunes se identificaron mediante la revisión de temas de debate de las reuniones públicas (W3C, PatCG, IETF), comentarios directos, GitHub y las preguntas frecuentes que surgieron a través de los equipos internos y los formularios públicos de Google.
Más específicamente, se revisaron las actas de reuniones para las reuniones de organismos estándar de la Web y, para los comentarios directos, se consideraron los registros de Google de las reuniones 1:1 con las partes interesadas, los correos electrónicos recibidos por los ingenieros individuales, la lista de distribución de la API y el formulario de comentarios públicos. Luego, Google coordinó los equipos involucrados en estas diversas actividades de comunicación para determinar la prevalencia relativa de los temas emergentes en relación con cada API.
Las explicaciones de las respuestas de Chrome a los comentarios se desarrollaron a partir de preguntas frecuentes publicadas, respuestas reales a problemas planteados por las partes interesadas y la determinación de una posición específicamente a los fines de este ejercicio de informes públicos. Para reflejar el enfoque actual del desarrollo y las pruebas, se recibieron preguntas y comentarios en particular con respecto a las APIs de Topics, Fledge y Attribution Reporting.
Es posible que los comentarios recibidos después del final del período del informe actual no tengan una respuesta de Chrome considerada.
Glosario de acrónimos
- CHIPS
- Cookies con estado particionado independiente
- DSP
- Plataforma orientada a la demanda
- FedCM
- Administración de credenciales federadas
- MPS
- Conjuntos propios
- IAB
- Interactive Advertising Bureau
- IdP
- Proveedor de identidad
- IETF
- Grupo de trabajo de ingeniería de Internet
- JI
- Dirección de Protocolo de Internet
- openRTB
- Ofertas en tiempo real
- Tiempo Sup.
- Prueba de origen
- PatCG
- Grupo comunitario de tecnología publicitaria privada
- RP
- De confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable
- UA
- String de usuario-agente
- UA-CH
- Client Hints de usuario-agente
- W3C
- Consorcio World Wide Web
- WIPB
- ceguera intencional de IP
Comentarios generales, sin API o tecnología específicas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en el tercer trimestre) Utilidad para diferentes tipos de partes interesadas |
Inquietudes de que las tecnologías de Privacy Sandbox favorecen a los desarrolladores más grandes y de que los sitios especializados (más pequeños) contribuyen más que los genéricos (más grandes) | Nuestra respuesta no cambió con respecto al tercer trimestre: "Google se comprometió a que la CMA diseñe e implemente las propuestas de Privacy Sandbox de una manera que no distorsione la competencia prefiriendo el negocio de Google y tenga en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes, independientemente de su tamaño. Seguimos trabajando estrechamente con la CMA para asegurarnos de 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 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 sobre las pruebas cuantitativas y apoyamos que la CMA publique una nota sobre el diseño del experimento para proporcionar más información a los participantes del mercado y la oportunidad de comentar los enfoques propuestos". |
| (También se informa en el tercer trimestre) Solicitudes de documentación |
Solicitudes de más recursos que detallan cómo administrar las pruebas, el análisis y la implementación | Actualización del 4o trim.: Agradecemos que nuestro material actual les resulte útil a los desarrolladores. Por ello, seguimos comprometidos a brindar más material para que puedan comprender cómo les pueden servir las nuevas tecnologías. Durante el trimestre pasado, agregamos la sección "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 de consulta públicas para desarrolladores a fin de compartir prácticas recomendadas y demostraciones, junto con sesiones de preguntas y respuestas con líderes de ingeniería y productos para permitir debates y preguntas en vivo. |
| Métricas web esenciales | ¿Cómo afecta la latencia de la API de Privacy Sandbox a las Métricas web esenciales? | 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 API tenga un impacto mínimo en las Métricas web esenciales 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 alentamos las pruebas y los 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, satisfacer las necesidades del ecosistema web. Para ello, nos alejamos de las tecnologías de navegador heredadas que permiten dicho seguimiento entre sitios, como las cookies de terceros, y, en su lugar, proporcionamos nuevas tecnologías diseñadas 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 en cuanto a la capacidad de un sitio web para compartir o procesar datos una vez recopilados desde el navegador. Por lo tanto, estas tecnologías no impiden que las empresas celebren acuerdos de "administración de datos" o cualquier otra relación contractual similar. Asimismo, no restringen la capacidad de los usuarios de dar su consentimiento para compartir sus datos a través de otros medios. A modo de aclaración, Google se comprometió a aplicar las tecnologías de Privacy Sandbox de la misma manera en todos los sitios web, incluidos los productos y servicios de Google. Una vez que Chrome deja de admitir las cookies de terceros, los compromisos también aclaran que Google no usará otros datos personales, como el historial de navegación de Chrome sincronizado de los usuarios, para hacer un seguimiento de los usuarios con el fin de segmentar o medir la publicidad digital. |
Mostrar anuncios y contenido relevantes
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Impacto en la clasificación de la Búsqueda de Google | Consulta sobre si la compatibilidad de la API de Topics de un sitio web se usará como un posible indicador para la clasificación de los resultados de la Búsqueda de Google. | Algunos sitios web pueden optar por inhabilitar la API de Topics. El equipo de Privacy Sandbox no coordinó ni le solicitó a la organización de la 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 utilizará la decisión de un sitio de inhabilitar la API de Topics como indicador de clasificación. |
| Clasificador de Topics | Agregue la URL y el contenido de la página, además del nombre de host, para determinar el tema de una página web, con el fin de 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 continúa 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 Topics. Todas las mejoras en la utilidad se deben comparar con los riesgos de privacidad y abuso. Por ejemplo, en relación con los metadatos en particular, algunos de los riesgos son los siguientes: - Sitios que modifican los metadatos a nivel de la página como un método para codificar significados diferentes (y potencialmente sensibles) en temas - Sitios que modifican los metadatos a nivel de la página para tergiversar sus temas y obtener beneficios financieros - Sitios que modifican los metadatos a nivel de la página de forma dinámica como un método de seguimiento entre sitios |
| (También se informa en el tercer trimestre) Impacto en los indicadores propios |
Los indicadores de temas pueden ser muy valiosos y, por lo tanto, desvaloran otros indicadores propios basados en intereses. | Nuestra respuesta no cambió con respecto al tercer trimestre: "Creemos que la publicidad basada en intereses es un caso de uso importante para la Web, y Topics está diseñado para admitirlo. Como se describe [en nuestro informe del 3er trimestre], otras partes interesadas del ecosistema expresaron su preocupación respecto de que Topics podría no ser lo suficientemente útil para proporcionar valor. En todos los casos, las mejoras en la taxonomía son un esfuerzo continuo, y esperamos que evolucione con las pruebas y los aportes de los ecosistemas”. |
| Actualiza la taxonomía | ¿Cómo se actualizará la lista de taxonomía? | Estamos buscando comentarios activamente 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 habilitar pruebas funcionales. Chrome está considerando activamente varios enfoques para actualizar la taxonomía. Por ejemplo, Chrome puede utilizar una noción de valor comercial para cada tema para determinar qué categoría incluir en futuras iteraciones. |
| Rendimiento del clasificador regional de Topics | El clasificador de Topics tiene un rendimiento deficiente en dominios regionales | La mejora del clasificador es un esfuerzo continuo. En función de los comentarios que recibimos, una posibilidad que se está considerando es ampliar la lista de anulación de Topics, la cual, 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 AA 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 tiene un rendimiento deficiente. |
| Ciclo de una semana | El ciclo de una semana es demasiado largo para los usuarios que buscan tomar decisiones a corto plazo. | Estamos analizando activamente cuál debería ser la duración adecuada de la época y agradecemos más comentarios sobre cuál sería una mejor época para el ecosistema. |
| Recuperación de encabezados HTTP | Preocupación de que no hay suficiente información sobre la recuperación del encabezado HTTP de los temas | Se están trabajando en los encabezados y fetch(). También tenemos información disponible aquí. También agregamos información de omitObservación a la explicación. |
| El objetivo de Topics solo es ayudar a los anunciantes, no a los usuarios | Topics/Privacy Sandbox parece ser 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 tener un impacto negativo en los publicadores y generar peores enfoques que son menos privados, no son transparentes y, de manera realista, no se pueden restablecer ni controlar los usuarios. Muchas empresas están probando activamente las APIs de Topics y Sandbox, y nos comprometemos a proporcionar las herramientas para mejorar la privacidad y respaldar la Web. Recientemente, el Grupo de Arquitectura Técnica de W3C publicó su vista 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 puede implicar esta revisión para el desarrollo y el lanzamiento de la API de Topics, nos gustaría reafirmar nuestro plan para que esté disponible en la versión estable de Chrome este año. Si bien Google agradece los aportes del Grupo de Arquitectura Técnica del W3C, considera que es 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 posible filtración de Topics en otros sitios sin permiso | El diseño de la API de Topics hace que sea bastante improbable que los datos de un solo publicador (y hasta de un grupo más pequeño de publicadores) se puedan filtrar de cualquier manera. Los sitios web de publicadores también tienen control total sobre la API de Topics y pueden prohibir el acceso a esta API a través de la política de permisos. |
| Faltan anunciantes para realizar pruebas | A los publicadores les preocupa que actualmente no puedan demostrar el valor de Topics a los anunciantes. | En la segunda mitad de 2023, planeamos que todas las APIs relacionadas con los anuncios estén disponibles para las pruebas de integración y permitiremos el análisis del ecosistema del valor de Topics para los anunciantes. La CMA supervisará las pruebas y publicaciones de los resultados, y se encargará de revisar los datos, el análisis y la metodología. Se alienta a que el ecosistema comparta comentarios con Google y la CMA. |
| Temas y FLEDGE | Solicitud de más información para usar Topics en la lógica de ofertas de FLEDGE | Es posible usar Topics dentro de la lógica de ofertas de FLEDGE. También hay una guía de integración en curso que incluirá detalles adicionales sobre la implementación. |
| Clasificación personalizada para emisores de temas | Permitir 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 podría convertirse en un mecanismo mediante el cual una tecnología publicitaria puede influir en los temas que se muestran, por lo tanto, en un vector de creación de huellas digitales. |
| Lista de prioridad de emisores de temas | Permite que los emisores proporcionen una lista de temas con prioridad clasificada que la API de Topics mostrará según la elegibilidad. | Estamos debatiendo esta idea en más detalle y agradecemos que nos envíes más comentarios. |
FLEDGE
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Google Ad Manager | Inquietud de que Google Ad Manager es el determinante final para las subastas de FLEDGE y preferiría Google Publisher Tags 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. Todos los compradores y vendedores de una subasta de componentes saben quién es el vendedor de mayor nivel y pueden elegir si desean o no ofertar. |
| No hay suficientes participantes que prueben FLEDGE | Solicitar a más empresas que prueben FLEDGE, por ejemplo, mejorando la funcionalidad de la API y desincentivando las alternativas que resguardan la privacidad, como la creación de huellas digitales | Privacy Sandbox está avanzando en 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 motivando al ecosistema para que pruebe las APIs de Sandbox. Hace poco, publicó su documentación "Maximizar 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 las cookies de terceros dejen de estar disponibles. Otras partes de Privacy Sandbox ya admiten mitigaciones para abarcar el seguimiento (consulta UA-CH, Protección de IP y Mitigaciones de seguimientos por rebote) 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 mantiene su compromiso de 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 | Se admitirán más orientación sobre cómo los casos de uso de aprendizaje automático para entrenar algoritmos de ofertas por subasta se admitirán en FLEDGE y Attribution Reporting | 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 relacionada específicamente 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, "Maximizar la relevancia de los anuncios", se analiza cómo la industria publicitaria puede aprovechar estos indicadores para el aprendizaje automático, y planeamos seguir publicando esta guía en el futuro. |
| Consulta el servidor de par clave-valor (K/V) de FLEDGE | ¿Por qué el servidor de K/V se puede consultar de forma pública? | El servidor de K/V tiene como objetivo proporcionar indicadores en tiempo real a las subastas de FLEDGE. Por lo tanto, se debe poder acceder al servidor de K/V desde el lugar en el que se ejecutan esas subastas de FLEDGE, que es en los dispositivos de los usuarios, lo que requiere que esté disponible de forma pública. Un valor almacenado en el servidor de K/V solo lo puede recuperar una parte que ya tenga su clave, por lo que, si una tecnología publicitaria solo proporciona las claves a los navegadores que están en el grupo de interés y no usa claves que puedan adivinarse de forma aleatoria, solo los navegadores que necesiten el valor para ejecutar su subasta podrán recuperarlo. |
| ¿Cómo se configura la orientación por fecha/hora? | Compatibilidad con objetos de fecha en la función lógica de ofertas. | Hay distintas formas de hacerlo: Los compradores pueden pedirle al vendedor que proporcione la fecha y hora actuales, y debería ser sencillo para los vendedores enviar esta información a todos los compradores. 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 | Permite que los usuarios elijan bloquear creatividades por anunciante cuando se publiquen mediante FLEDGE o soluciones alternativas. | Los usuarios pueden inhabilitar las APIs de Ads en Chrome. En el caso de anuncios específicos, la tecnología publicitaria relevante es la que mejor se posiciona para ofrecer controles sobre las creatividades que se muestran o cómo se seleccionan. |
| Cronogramas más claros | Solicita más información sobre la disponibilidad de protecciones de la privacidad en FLEDGE, como los requisitos de marcos cercados. | Planeamos publicar cronogramas más detallados en el primer trimestre. |
| Confusión en los informes | Solicita más claridad sobre cómo funcionarán los informes de FLEDGE con otras APIs, como marcos protegidos y la API de agregación privada. | Planeamos publicar en las próximas semanas una explicación sobre la interacción entre la API de Private Aggregation, FLEDGE y los marcos protegidos. |
| Ofertas en tiempo real y FLEDGE | Orientación sobre cómo FLEDGE se integra con las ofertas en tiempo real estándar. | Los dos factores 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 una integración más simple en ARA. Planeamos enviar actualizaciones y explicaciones sobre ambos temas durante el primer trimestre. |
| Rendimiento de las subastas de FLEDGE | Informe de los verificadores que indica que las subastas de FLEDGE tienen 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. Al mismo tiempo, agregamos herramientas al navegador que permiten que los desarrolladores diagnostican mejor los factores que ralentizan las subastas. Además, hemos abordado de manera sistemática las fuentes principales de latencia observadas. Las mejoras recientes incluyen tiempos de espera para subastas lentas, una técnica de filtrado de ofertantes rápidos, una forma de reutilizar los worklets de FLEDGE para evitar pagar los costos de inicio, y trabajo continuo para permitir que la solicitud de anuncios contextuales se ejecute en paralelo con el tiempo de inicio y las recuperaciones de la red de FLEDGE. Esperamos que la optimización de la latencia continúe así 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 interés | Solicitud para aumentar el límite de tamaño de un solo grupo de interés de 50 KB. | Estamos considerando activamente la solicitud y deseamos recibir comentarios sobre qué valores de límite funcionan. |
| Combina los datos publicados de FLEDGE con cookies propias | ¿FLEDGE admitirá la integración con los datos de origen del anunciante? | FLEDGE se creó para admitir la publicidad con los datos de origen que ya tiene un anunciante. Sin embargo, FLEDGE no admite que un anunciante obtenga información sobre el comportamiento de navegación de un usuario en otro sitio web que no sea el propio del anunciante. Adjuntar el comportamiento de navegación fuera del sitio a datos de origen es contrario a 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 de origen en las próximas semanas. |
| Valor de k-anonimato | ¿Cómo se decidirá el valor de la “K” a “k-anon” y se publicará? | El valor “K” aún está en proceso de finalización, y compartiremos más información a medida que avancen nuestros planes. Nos interesa obtener más información sobre cómo un valor k desconocido puede dificultar la preparación de FLEDGE y el alcance del entrenamiento de modelos de AA, por lo que agradecemos comentarios adicionales sobre este tema. |
| Admite 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 | Inquietud de que la lógica de ofertas de la DSP se exponga en JavaScript | Con la lógica actual de ofertas de diseño, otros pueden acceder a JavaScript, pero recibiremos 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 de 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? Se trata de funciones que los usuarios finales pueden programar para extender la funcionalidad de la API. | Aquí encontrará la explicación. Esto aún se está desarrollando, por lo que recibiremos comentarios adicionales sobre los casos de uso. |
| Flexibiliza la restricción del mismo origen en los recursos de los grupos de interés | Solicitud para flexibilizar la restricción del mismo origen en los recursos de los grupos de interés para habilitar ciertos casos de uso de 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 interés.La restricción existe para evitar ciertas vulnerabilidades por parte de atacantes, como se explica aquí. |
| Propiedad de interestGroup | Solicitud para limitar si una plataforma de tecnología publicitaria puede usar joinInterestGroup para los mismos grupos de interés en diferentes sitios | Nuestro enfoque está en cómo se usan los públicos, no en cómo se crean. Consultamos aquí los posibles enfoques y agradecemos que nos envíes más comentarios. |
| Vencimiento de la clave del servidor de par clave-valor | Debate sobre la eliminación de claves de servidor una vez que hayan vencido los grupos de interés correspondientes | Estamos explorando formas de controlar el vencimiento de las claves y queremos recibir comentarios aquí. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Tráfico de la prueba de origen | El tráfico de la prueba de origen actual no es suficiente para realizar pruebas de la compañía eléctrica. | Las pruebas de origen actuales están diseñadas para que los participantes del ecosistema realicen pruebas funcionales a fin de garantizar que la API funcione según lo previsto. Comprendemos que se requerirán mayores cantidades de tráfico para realizar pruebas de servicios públicos una vez que el desarrollo de las diversas APIs de Privacy Sandbox esté más maduro. En el cronograma de pruebas actual, se prevé que esto ocurrirá durante el período de 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 3er trimestre de 2023 (consulta nuestro cronograma actualizado en privacysandbox.com). Agradecemos cualquier comentario adicional sobre las pruebas de casos de uso que requieran tráfico adicional. |
| Superposición en la funcionalidad de diferentes APIs de medición de Privacy Sandbox | La preocupación por tener múltiples enfoques de medición superpuestos a través de Privacy Sandbox aumentará la complejidad, por ejemplo, la API de Attribution Reporting y la API de Private Aggregation. | Estamos trabajando para mejorar la documentación a fin de aclarar los diferentes casos de uso de las APIs y recibir comentarios adicionales sobre las áreas a las que les falta 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 destinadas a admitir una gama más amplia de casos de uso de medición entre sitios. |
| Reintentar la solicitud de informe fallida | Aclaración sobre cuántas veces se intentará realizar una solicitud de informe si falla | Publicamos orientación sobre este tema. En resumen, los informes solo se envían cuando el navegador está activo o en línea. Después de la primera falla de envío, el informe se vuelve a intentar después de 5 minutos. Después de la segunda falla, el informe se vuelve a intentar después de 15 minutos. Después de ese período, no se enviará la denuncia. |
| Demora en los informes | ¿Cuál es la demora esperada en la generación de informes? | Esperamos recibir más comentarios del ecosistema sobre las demoras en los informes que experimentan a medida que recopilamos datos para evaluar mejor estas demoras en paralelo. |
| Renderizar páginas previamente | ¿La atribución de ARA funcionará en páginas con renderización previa? | El registro de atribución se aplaza en las páginas con renderización previa hasta la activación (se produce un clic o una vista reales). Esto significa que diferiremos el ping de la solicitud `attributionsrc`. |
| Medición de la efectividad de conversiones | Cómo medir la Efectividad de conversiones con pruebas A/B en el mismo dominio | Los sitios web pueden medir la efectividad 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 mediante la API agregada y, luego, recibir informes de resumen de los valores de conversión de esos buckets de claves. |
| (También se informa en el tercer trimestre) Conversiones multidominio | Cómo hacer un seguimiento de las conversiones que son multidominio, por ejemplo, con 2 o más destinos | Actualización del 4o trim.: Publicamos una propuesta para quitar la restricción de destino de la página de destino, lo que permite hacer un seguimiento de las conversaciones entre dominios. Se implementó esta propuesta. |
| (También se informa en el tercer trimestre) Configuración de vencimiento en el informe de conversiones |
Solicitud de compatibilidad con filtro de informes o vencimiento durante menos de 24 horas | Actualización del 4o trim.: Compartimos esta solicitud de extracción , que separará los períodos de vencimiento y de informe para mitigar la compensación entre la demora en los informes y el vencimiento de las conversiones. Ahora se lanzó en la versión M110. |
| Fraude y abuso | Solicitudes de los anunciantes y especialistas en marketing para dividir y agregar datos en función de los sitios de publicadores donde se publican sus anuncios, lo que también brindaría más información sobre posibles prácticas de anuncios fraudulentas | Estos comentarios se están analizando activamente aquí y agradecemos que nos proporciones más. |
| (También se informa en el T3) Retraso en los informes a nivel del evento | La demora de 2 a 30 días en los informes a nivel del evento puede ser demasiado larga para ciertos casos de uso. | Los informes a nivel del evento tienen períodos de informes predeterminados de 2, 7 y 30 días. Esto se puede modificar con el parámetro "expiry". Las AdTech podrían configurar el vencimiento, con un mínimo de 1 día, para obtener informes potenciales en menos de 2 días. Como mecanismo de protección de la privacidad, limitamos el nivel de detalle de los vencimientos a 1 día, ya que la creación de informes más detallados podría generar ataques de tiempo. Además, permitimos establecer 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 tendrá ninguna ventana de informes especial 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 origen del registro de conversiones | Proponemos usar redireccionamientos HTTP para delegar el registro y resolver este caso de uso. Apreciamos cualquier comentario adicional sobre la nueva orientación. |
| Seguimiento de conversiones | Debe diferenciar si la conversión se produjo antes o después de determinadas horas que estableció el anunciante. | La API de Attribution Reporting admite la configuración de una ventana de vencimiento y una prioridad para la atribución fuente. Al utilizar ambos, técnicamente será posible atribuir una conversión que ocurrió dentro de la ventana de X días de forma independiente de una conversión que se produjo después de X. |
| Simulación de ruido | Solicita la posibilidad de simular los diferentes volúmenes 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 con 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 que acepta la CMA. |
| Disponibilidad de los datos | Inquietudes sobre que Google tendrá acceso adicional 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 sitios más grandes y pequeños, Google reconoce que las protecciones de la privacidad basadas en el ruido pueden tener un mayor impacto en porciones de datos más pequeñas. Sin embargo, existen algunas mitigaciones posibles; por ejemplo, los métodos como la agregación durante períodos más largos podrían resolver este problema. Dicho esto, no queda claro si las conclusiones basadas en segmentos muy reducidos de datos (como una o dos compras) son significativas para los anunciantes. Durante la prueba de origen, Google recomendó que los verificadores aprovecharan la capacidad de experimentar con una amplia gama de parámetros de privacidad y ruido para proporcionar comentarios más específicos sobre este problema. |
Limita el seguimiento encubierto
Reducción de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Retrasar la reducción de usuario-agente hasta que el ecosistema web esté más listo | No hay tiempo suficiente para adaptarse a los cambios que se avecinan sobre la reducción de usuario-agente. | Abordamos estos comentarios en el informe completo en la sección "Inquietudes de las partes interesadas", en la sección titulada "Interacción de Google con la CMA". |
| Retrasar 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) | En octubre de 2021, el equipo de Google Ads propuso la incorporación estructurada de usuario-agente (consulta la especificación) a OpenRTB, y esta se incorporó en la actualización de especificaciones 2.6 publicada en abril de 2022. Tenemos pruebas de que los SUA se implementaron y están disponibles en la actualidad, como lo demuestra la entrada de blog de Science Mobile, en la que se demuestra cómo usar UA-CH y la API de WURFL para crear un SUA. |
###
Client Hints de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Prueba UA-CH con otras técnicas de seguimiento antiencubierto | Guía sobre cómo 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ñó con el fin de reflejar los plazos asíncronos para el desarrollo de algunas de las medidas antihuellas digitales en comparación con el resto de las Propuestas de zona de pruebas. Este informe aborda la realidad de que algunas medidas contra la huella digital (es decir, el presupuesto de privacidad, la protección de IP y las mitigaciones de seguimiento por rebote) estarán completamente desarrolladas y listas para su lanzamiento a disponibilidad general solo después de que las cookies de terceros dejen de estar disponibles. Si bien esas medidas contra la huella digital no se incluirán en las pruebas cuantitativas, estarán sujetas a una evaluación cualitativa basada en los datos disponibles al momento de la detención. |
| (También se informa en el 2o trimestre) Rendimiento |
Inquietudes sobre la latencia de la obtención de sugerencias a través del canal Critical-CH (en la carga de la primera página) | Consulta la sección sobre UA-CH específica a continuación. |
| Comentarios insuficientes | Los comentarios del ecosistema sobre el cambio en UA-CH podrían no ser suficientes, lo que genera preocupación por la falta de conocimiento del ecosistema. | Compartimos de manera proactiva nuestros planes para garantizar un lanzamiento cuidadoso que minimice las interrupciones. Los planes de reducción de usuario-agente y de la API de UA-CH se presentaron al Grupo comunitario contra el fraude de W3C el 18 de marzo de 2022 y tanto al Grupo de trabajo de pagos web como al Grupo de interés de seguridad para pagos web el 20 de enero de 2022. No se plantearon inquietudes significativas durante las presentaciones ni después de ellas. Google colaboró de forma proactiva con más de 100 operadores de sitios para obtener comentarios. Además, Google también utilizó los canales Blink-Dev para comunicar públicamente el lanzamiento de la reducción de usuarios-agentes, en función de los comentarios de las partes interesadas del ecosistema. |
| Tiempos | Inquietudes relacionadas con los plazos del lanzamiento y la preparación de la industria | Consulta la sección sobre UA-CH específica a continuación. |
| Estado de la plataforma Chrome | Se solicitó que se actualice la página de estado de Chrome de UA-CH. | El 19 de diciembre, la entrada de chromestatus se actualizó a "Indicadores mixtos". |
Protección de IP (anteriormente conocido como Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cómo habilitar o inhabilitar la función | ¿Se puede habilitar o inhabilitar la privacidad de las direcciones IP? | Nuestro objetivo es brindar 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 dirección IP para datos de origen | ¿Es posible usar direcciones IP para unir los recorridos de los usuarios en los dominios propios después de la protección de la 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 tecnología publicitaria | ¿Cómo pueden las empresas establecer medidas antifraude con la protección de IP? | Reconocemos la importancia de las direcciones IP como un indicador para los esfuerzos 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 la propiedad intelectual sin hacer esfuerzos razonables para respaldar la capacidad de los sitios web de llevar a cabo iniciativas contra el spam y el fraude. Una de nuestras prioridades principales es comprender cómo influye la protección de la IP en los casos de uso y las capacidades de detección contra fraudes, de modo que podamos seguir invirtiendo en tecnologías que preserven la privacidad y ayuden a las empresas a preservar la seguridad web. Alentamos a los usuarios a enviar comentarios y aportar nuevas propuestas destinadas a satisfacer las necesidades de las empresas de seguridad y antifraude, incluso cuando las señales cambian con el tiempo. |
| Fraude y abuso | ¿La protección de IP incluye protección contra la denegación del servicio (DoS)? | Nos comprometemos a mejorar la privacidad mientras protegemos la Web, y la protección contra ataques de denegación del servicio es un importante caso de uso antiabuso para diseñar. Esperamos minimizar el impacto en las protecciones contra DoS mediante el diseño de la protección de IP y de nuevas soluciones contra el abuso. Dado que la protección de IP se enfoca, en un principio, en servicios incorporados de terceros, algunas partes interesadas indicaron que debería tener un impacto limitado en la protección contra DoS para sitios propios. Sin embargo, seguimos solicitando comentarios públicos para evaluar el riesgo de casos de uso de DoS, en particular, para servicios incorporados de terceros. En paralelo, estamos explorando mecanismos para bloquear clientes y enviar comentarios sobre abusos que podrían permitir que un sitio o servicio bloquee a un usuario generador de spam, sin identificar al usuario. |
| Filtrado de contenido | Filtrado de contenido con protección IP | Las diferentes empresas tienen necesidades diferentes con respecto al filtrado de contenido y la personalización de la experiencia del usuario. Muchos de estos casos de uso actualmente no dependen de direcciones IP y, por lo tanto, la protección de IP no deberían verse afectados. Por ejemplo, un publicador que busca adaptar su contenido y generar más participación podría usar cookies propias o de terceros (CHIP) para comprender los intereses de un usuario y sus interacciones anteriores con el publicador. O un socio de tecnología publicitaria enfocado en publicar el anuncio correcto al usuario correcto puede incorporar FLEDGE y Topics, por ejemplo, para ofrecer resultados de anuncios similares a los que tiene actualmente con cookies de terceros y otras tecnologías de seguimiento entre sitios. También estamos explorando la creación de nuevas capacidades que preserven la privacidad en la protección de IP, como la ubicación geográfica aproximada, para respaldar aún más el filtrado de contenido en los casos en que los mecanismos existentes puedan ser insuficientes. Agradecemos los comentarios adicionales sobre los casos de uso de filtrado de contenido que puedan verse afectados por la protección de IP. |
| (También se informa en el tercer trimestre) Casos de uso de ubicación geográfica |
La protección de IP puede impedir que funcionen en el futuro casos de uso legítimos de la ubicación geográfica, como la personalización del contenido basada en la ubicación geográfica. | Actualización del 4o trim.: Estamos trabajando con las partes interesadas para garantizar que Chrome siga admitiendo casos de uso legítimos para las direcciones IP. Estamos buscando comentarios sobre el ecosistema sobre el nivel de detalle de la ubicación geográfica de IP aquí. |
Presupuesto de privacidad
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Documentación más clara | Más ejemplos para que las partes interesadas puedan anticipar las posibles limitaciones una vez que se implemente el Presupuesto de privacidad | La propuesta de presupuesto de privacidad aún se encuentra en proceso de debate y no se implementó en ningún navegador. La fecha más temprana de la disponibilidad escalada representa la fecha más temprana en la que podría aplicarse el Presupuesto de privacidad. Esto no sucederá antes de la eliminación de las cookies de terceros en 2024. No tenemos documentación adicional para compartir en este momento. Compartiremos detalles adicionales sobre la propuesta cuando esté más completa. Mientras tanto, invitamos a las partes interesadas a que compartan comentarios que nos ayuden en el desarrollo de la propuesta. |
Fortalecer los límites de privacidad entre sitios
Conjuntos propios
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en el T3) Límite de dominios | Solicitud para expandir la cantidad de dominios asociados | Actualización del 4o trim.: Lanzamos FPS para pruebas locales, incluido un proceso de envío de conjuntos simulados en GitHub y una marca para probar rSA y rSAFor localmente. También organizamos dos reuniones abiertas para que los desarrolladores en FPS sigan respondiendo preguntas sobre casos de uso del subconjunto asociado. Alentamos a los desarrolladores a probar la funcionalidad de FPS para que proporcionen 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, apreciamos 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 abordarlos sin dejar de proteger la privacidad del usuario. |
| Solicitud de 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 dieron su consentimiento? | El 2 de diciembre de 2022, publicamos los lineamientos de envío de los conjuntos propios aquí. Como se explica en los lineamientos de envío, cualquier administración de cambios de conjunto 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 de que las formaciones de conjuntos propios puedan explotarse | Estamos buscando formas de expandir las verificaciones técnicas para tipos de subconjuntos y buscamos activamente comentarios adicionales de la comunidad aquí. |
| Casos de uso de los anuncios | Preguntas acerca de si los conjuntos propios deben utilizarse para admitir la segmentación de anuncios | No intentamos admitir casos de uso de orientación de anuncios para conjuntos propios, por lo que recomendamos usar las APIs de Google Ads disponibles para esos casos de uso. |
| (También se informa en el tercer trimestre) Política | Preocupación de que el FPS no es coherente con los compromisos de la CMA en relación con la "Legislación Aplicable de Protección de Datos", porque 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 desde el tercer trimestre: "Google continúa comprometiéndose con la CMA para diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia prefiriendo los negocios de Google y que tenga en cuenta el impacto en la competencia en la publicidad digital, los publicadores y los anunciantes, así como el impacto en los resultados de privacidad y el cumplimiento de los principios de protección de datos establecidos en la Legislación Aplicable sobre Protección de Datos. La inquietud expresada no revela ninguna incompatibilidad con el GDPR. Seguimos trabajando estrechamente con la CMA para asegurarnos de que nuestro trabajo cumpla con estos compromisos". |
| Propuesta alternativa | Conjuntos validados por el GDPR | Además de los comentarios que proporciona el ecosistema sobre la propuesta de adoptar "Conjuntos validados por el GDPR", Chrome se preocupa por las siguientes limitaciones de esta propuesta alternativa:
Desde que se presentó 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 comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Restricciones de marcos protegidos durante la PO | ¿Cuáles son las restricciones actuales para las marcos cercados durante el período de prueba de origen? | Estamos trabajando en la documentación sobre las restricciones y el estado de implementación, y tenemos previsto compartirla durante el primer trimestre de 2023. |
| Varios anuncios en un solo marco vallado | Solicitud para mostrar varios anunciantes en un Marco vallado en una subasta | Actualmente, esta solicitud no se está desarrollando de forma activa, pero recibiremos comentarios adicionales si los participantes del ecosistema consideran que esta función es importante. |
| Paquetes web | ¿Cuáles son los requisitos y la asistencia previstos para los paquetes web con marcos cercados? | Actualmente, no tenemos novedades sobre si este será el requisito en el futuro. Cualquier cambio se anunciará con anticipación y no se aplicará 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 comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Almacenamiento compartido para tecnología publicitaria | Incertidumbre en torno al uso del almacenamiento compartido para casos de uso de tecnología publicitaria | La API de Shared Storage y Private Aggregation se pueden usar para diferentes tipos de fines de medición que necesitan medir el almacenamiento entre sitios. Aquí se incluyen algunos ejemplos. Prevemos que los proveedores de soluciones de DSP y medición serán el integrador principal para los casos de uso de anuncios. |
CHIP
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informa en el T3) Requisito particionado | Se agregó el requisito de comportamiento explícito para el atributo "Particionado" en las cookies propias. | Actualización del 4o trim.: Después de los debates sobre las llamadas de GitHub y PrivacyCG, el comportamiento en el que nos alineamos es que las cookies particionadas establecidas en cookies propias utilizarán una clave de partición de (A, A), en la que "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 controlar 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 quisieran ver. |
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| El IdP requiere conocimiento del RP para permitir una sesión | Problema cuando un usuario intenta acceder al IdP de Feide desde dos RP diferentes | Estamos analizando posibles soluciones para este problema aquí. |
| Interoperabilidad | Inquietudes respecto del impacto de FedCM en la relación entre los usuarios y los sitios web a los que acceden mediante FedCM, así como la "interoperabilidad" entre los sitios web | El objetivo de FedCM es seguir admitiendo los servicios de identidad federada que actualmente dependen de las cookies de terceros una vez que estas se quiten de Chrome. Esperamos que FedCM sea solo una opción disponible para esos servicios; los proveedores de identidad (IdP) y los terceros de confianza (RP) tienen la libertad de usar otras tecnologías que se adapten mejor a sus necesidades. Al parecer, las inquietudes relacionadas con la "interoperabilidad" y la relación entre el usuario y el RP se deben a un malentendido de la propuesta de la FedCM. El FedCM deja que los IdP decidan qué información compartir con un RP y de qué forma lo hacen una vez que el usuario elige acceder al sitio de ese RP. FedCM no requiere que los IdP "creen un identificador seudónimo único para cada [RP] con el que se autentica el usuario". En cambio, FedCM está abierto para cada IdP a fin de elegir si desea compartir el identificador real del usuario, una versión por sitio de ese identificador o alguna otra versión de esta información. (La especificación de FedCM sí 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 en manos de los IdP, y el navegador no la impone). FedCM ya también ofrece opciones para los usuarios 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. Más allá de eso, 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 un IdP, ya sea FedCM o una tecnología diferente. Una vez más, el navegador no determina estas opciones para RP o IdP. |
Combate el spam y el fraude
API de Private State Token
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cómo controlar bots | ¿Qué sucede si la entidad emisora descubre que se emitieron tokens de estado privado a los bots? | Para evitar que los tokens emitidos a bots permanezcan en el ecosistema durante mucho tiempo, las entidades emisoras deben rotar las claves que usan para firmar tokens con regularidad a fin de que venzan los tokens antiguos emitidos bajo una lógica de emisión posiblemente interrumpida y los sitios canjeen tokens más nuevos con la lógica de emisión actualizada. |
| Envíos de formularios en el mismo sitio | ¿Se podrían usar tokens de estado privado para envíos de formularios del mismo sitio que impliquen navegación de página completa (es decir, tipo de contenido: application/x-www-form-urlcoded) en lugar de una solicitud de las APIs de fetch/XMLHttpRequest? | Por el momento, esta opción no es compatible con la primera versión de los tokens de estado privado. Si hay una gran demanda de este caso de uso, agradecemos los comentarios del ecosistema. |
| Verificación del servidor | Preguntas sobre si los tokens de estado privado se pueden verificar en el servidor | Los tokens se canjean ante la entidad emisora y esta crea un registro de canje que puede contener el token en sí o algún valor firmado derivado de él. Los servidores pueden usar ese registro de canje para verificar la autenticidad del token, y esperamos que los distintos ecosistemas de la entidad emisora creen estándares diferentes para interpretar sus registros de canje. |