Informe trimestral para el segundo trimestre de 2023 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ó brindar informes trimestrales sobre el proceso de participación de las partes interesadas para su Privacy Sandbox propuestas (consulte los párrafos 12 y 17(c)(ii) de los de Google Cloud). Estos informes de resumen de comentarios de Privacy Sandbox se generan agregando comentarios recibidos por Chrome de diversas fuentes, como se indica en el comentarios descripción general, incluidos, sin limitaciones, GitHub los problemas, el formulario de comentarios está disponible en privacysandbox.com, reuniones con la industria interesados y foros de estándares web. Chrome agradece los comentarios recibidos del ecosistema y explora activamente formas de integrar los aprendizajes en decisiones de diseño.
Los temas de los comentarios se clasifican por prevalencia por API. Para ello, se debe tomar una la cantidad de comentarios que recibió el equipo de Chrome en torno a un tema determinado y lo organizamos en orden descendente de cantidad. Los comentarios comunes temas se identificaron revisando temas de debate en reuniones públicas (W3C, PatCG, IETF), comentarios directos, GitHub y preguntas frecuentes que surgen en los equipos internos y los formularios públicos de Google.
Más concretamente, las actas de reuniones para las reuniones web estándar de los organismos revisar y, para recibir comentarios directos, los registros de Google de las reuniones 1:1 con las partes interesadas correos electrónicos recibidos por ingenieros individuales, la lista de distribución de la API y el formulario de comentarios. Luego, Google las coordina entre los equipos participan de estas diversas actividades de outreach para determinar la relación la prevalencia 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 la preguntas frecuentes, respuestas reales a problemas planteados por los interesados y determinar un a los fines de este ejercicio de denuncia pública. que refleja el enfoque actual del desarrollo y las pruebas, las preguntas y los comentarios. se recibieron en particular con respecto a Topics, Protected Audience y Attribution APIs de informes.
Es posible que los comentarios recibidos después de que finalice el período del informe actual aún no una respuesta considerada 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
- Agencia de Publicidad Interactiva
- IDP
- Proveedor de identidad
- IETF
- Grupo de trabajo de ingeniería de Internet
- IP
- Dirección de Protocolo de Internet
- openRTB
- Ofertas en tiempo real
- TS
- Prueba de origen
- PatCG
- Grupo de la Comunidad de tecnología de publicidad privada
- Acceso al
- Grupo de confianza
- SSP
- Plataforma de proveedores
- TEE
- Entorno de ejecución confiable .
- UA
- Cadena de usuario-agente
- UA-CH
- User-Agent Client Hints
- W3C
- Consorcio World Wide Web
- WIPB
- Ceguera intencional de IP
Comentarios generales, sin API o tecnología específica
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Administración de datos y Cumplimiento de normativas | Orientación del ecosistema sobre el uso de Privacy Sandbox en cumplimiento de los requisitos reglamentarios. | Al igual que con cualquier tecnología nueva, cada empresa es responsable de garantizar que el uso que haga de Privacy Sandbox cumpla con la ley. Google no puede proporcionar asesoramiento legal a otras personas. Sin embargo, sabemos que esta es un área de interés clave para el ecosistema. Para cada API, hemos publicado una amplia documentación técnica que debe proporcionar la base para realizar las evaluaciones legales necesarias. Además, estamos trabajando para ofrecer materiales adicionales en apoyo de las y las iniciativas para satisfacer los requisitos reglamentarios. |
| Propuesta de pruebas cuantitativas de CMA | Más información sobre la propuesta de pruebas cuantitativas de CMA | Estamos trabajando junto con la CMA para diseñar experimentos que brinden una imagen del impacto de la baja de las cookies de terceros y la presentación de las propuestas de Privacy Sandbox en el ecosistema. En abril, la CMA publicó orientación de alto nivel sobre qué esperar durante el período de prueba y prueba, seguida de una orientación detallada en junio. Recomendamos que las preguntas o los comentarios sobre la propuesta de pruebas cuantitativas de la CMA se compartan directamente con la CMA. |
| Modos de prueba facilitados por Chrome | Más información y aclaraciones sobre los cronogramas de pruebas | El 18 de mayo, publicamos una entrada de blog en la que compartimos más información sobre los dos modos de pruebas facilitadas por Chrome. Estos detalles no son definitivos, por lo que publicaremos más guías de implementación a medida que avancemos en el tercer trimestre de 2023. |
| Almacenamiento particionado | ¿Se usará el almacenamiento particionado durante las pruebas facilitadas por Chrome? | La partición de almacenamiento se enviará a todos los usuarios antes del experimento de baja de las cookies de terceros. Por lo tanto, estará habilitada para todos los grupos del experimento. Los sitios tendrán la opción de habilitar una prueba de baja para recuperar el almacenamiento no particionado durante este período. |
| Asistencia de producción | ¿Cuál es el proceso implementado para que Chrome brinde asistencia a los problemas técnicos y derivaciones de Privacy Sandbox que afectan al ecosistema? | Google proporciona una variedad de canales para permitir que las tecnologías publicitarias informen problemas y habiliten las derivaciones necesarias. Consulta nuestra publicación para desarrolladores si quieres obtener más información en los foros públicos y privados para obtener comentarios y derivación. |
| Cronograma de inscripción | El plazo actual para la inscripción es demasiado corto | Aún estamos evaluando la fecha límite para la aplicación y nos gustaría saber qué plazo sería más adecuado en el ecosistema. |
| Número DUNS | Más información sobre el requisito del número DUNS para la Inscripción y la Certificación | Los participantes pueden consultar los requisitos para obtener un número DUNS en el sitio web de Dun & Bradstreet. Los requisitos varían según el mercado, por lo que los participantes deben asegurarse de consultar el sitio web del mercado específico que les interesa. Sin embargo, en general, los participantes deberán proporcionar información básica acerca de su empresa, como el nombre, la dirección y la información de contacto del propietario o administrador de la empresa. También se les puede solicitar a los participantes que proporcionen información financiera, como los ingresos anuales de la empresa. Una vez que se complete la solicitud, D&B la revisará y emitirá un número DUNS si se aprueba. |
| Transición de la prueba de origen a la disponibilidad general | ¿La transición de la prueba de origen a la disponibilidad general afectará a los verificadores actuales de la prueba de origen? | A partir de julio, los verificadores podrán acceder a las APIs de relevancia y medición con disponibilidad general. Esto proporcionará una superposición entre la disponibilidad de la prueba de origen y la general. |
| Estudio de AdExchanger | Más información sobre la metodología de la encuesta | En la encuesta, se les pidió a los encuestados que estimen las tasas de sincronización y los ingresos de sus empresas. Encuestados para responder cada pregunta individual estaba en sus manos. |
| Valores del parámetro | ¿Cómo se determinan los valores de los parámetros, como el nivel de ruido, los umbrales de anonimato y el presupuesto de privacidad? | En esta explicación de GitHub, se establecen los principios más generales detrás de las APIs de Privacy Sandbox. Muchos valores aún se están ultimando y agradecemos los comentarios al respecto. |
Mostrar contenido relevante y Anuncios
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Preservación de la privacidad | Investigación que evalúa la API de Topics sobre preservación de la privacidad | Colaboramos activamente con la comunidad de investigadores y presentamos nuestras investigaciones sobre las propiedades de privacidad de la API de Topics en artículos, informes y presentaciones de talleres. Nos alegra ver que más miembros externos de la comunidad de investigación se involucran en esta área. La API de Topics protege a los usuarios del seguimiento general en la Web, ya que dificulta mucho el seguimiento a gran escala. En estos informes, se demuestra que lo hacemos correctamente con la API de Topics. Es más privada que las cookies de terceros y protege a los usuarios, a la vez que respalda los sitios que disfrutan visitar. |
| La taxonomía de temas no es lo suficientemente detallada | La taxonomía de temas generales no incluye temas más detallados, incluidos los específicos de una región. | En respuesta a comentarios anteriores del ecosistema, el 15 de junio publicamos una entrada de blog en la que se detalla una nueva taxonomía actualizada que incorpora numerosas mejoras a partir de los comentarios del ecosistema. Como parte de nuestro trabajo en la taxonomía revisada, trabajamos con varias empresas de todo el ecosistema, como Raptive (antes CafeMedia) y Criteo. La taxonomía actualizada quita las categorías que consideramos menos útiles y favorece las que mejor se adaptan a los intereses de los anunciantes, a la vez que mantiene nuestro compromiso de excluir los temas potencialmente sensibles. Alentamos al ecosistema a que revise la taxonomía más reciente y que proporcione comentarios sobre los cambios. |
| Proceso de actualización de la taxonomía y el clasificador | Obtén más información sobre la taxonomía de Topics y la cadencia de lanzamiento de los clasificadores, y cómo las empresas pueden prepararse para esas actualizaciones. | Como se compartió en la entrada de blog reciente, esperamos que la taxonomía evolucione con el tiempo, y que la administración de la taxonomía eventualmente se traslade a una parte externa que represente a las partes interesadas de toda la industria. También compartimos el plan de aumento en el grupo topics-announce. |
| Impacto en los indicadores propios | El aumento en la cantidad de temas en la reciente actualización de la taxonomía puede ser muy valioso y, como resultado, devalúa otros indicadores propios basados en intereses. | En el informe del primer trimestre de 2023, la CMA comentó lo siguiente: “Entendemos que Google ha estado analizando su nueva taxonomía propuesta con varios participantes del mercado de toda la cadena de suministro de tecnología publicitaria. Si bien algunos editores importantes afirman que una mayor utilidad de los temas aumentaría la presión competitiva en sus soluciones basadas en datos de origen, nuestro punto de vista preliminar es que una mayor utilidad es mejor para la competencia en general, en particular, para la capacidad de los editores más pequeños de seguir monetizando su inventario después de la baja de las cookies de terceros". Nuestra opinión concuerda con este comentario de la CMA. |
| Utilidad para diferentes tipos de interesados | Las tecnologías publicitarias que funcionan como SSP y DSP pueden tener ventajas significativas en comparación con otros actores del ecosistema. | Nuestra respuesta no cambia con respecto a los trimestres anteriores: “Google se comprometió a la CMA a diseñar e implementar las propuestas de Privacy Sandbox de una manera que no distorsione la competencia al priorizar el propio negocio de Google, y a tener en cuenta el impacto en la competencia en la publicidad digital y en los publicadores y anunciantes, sin importar 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 evaluamos es el rendimiento de las nuevas tecnologías para los diferentes tipos de partes interesadas. Los comentarios son fundamentales en este aspecto, especialmente los comentarios específicos y prácticos que pueden ayudarnos a mejorar aún más los diseños técnicos. Hemos trabajado con la CMA para desarrollar nuestro enfoque de las pruebas cuantitativas y apoyamos la publicación de una nota sobre el diseño de experimentos para proporcionar más información a los participantes del mercado y la oportunidad de comentar los enfoques propuestos". |
| Temas subordinados | Si los criterios de selección de temas son la frecuencia de las visitas al navegador, ¿la fragmentación de los temas hará que los temas descendientes nunca asciendan a la parte superior? | En este momento, Chrome está evaluando otras metodologías de clasificación y explorando otros indicadores que podrían mejorarla. Comunicaremos nuestros planes revisados al ecosistema en el momento oportuno. |
| Sensibilidad | El objetivo de la API de Topics debe ser garantizar que la información del usuario obtenida o derivada de esta API sea menos sensible que la que podría derivarse con los métodos de seguimiento actuales. | Creemos que la API de Topics es significativamente más privada que las tecnologías actuales, limita significativamente la reidentificación de los usuarios y está diseñada para excluir temas sensibles. Sabemos que los temas se pueden correlacionar o combinar con datos de origen para crear categorías sensibles, pero creemos que la API de Topics es un paso adelante hacia la privacidad del usuario, y nos comprometemos a seguir mejorando la API. |
| Estructura de taxonomía | Agrega un ID, el control de versiones y otra estructura de metadatos a la taxonomía de Topics | Actualmente, incluimos el ID de taxonomía en la respuesta de la API. A medida que avanzamos hacia una administración a largo plazo, tiene sentido revisar el objeto Topics y, además, incluir metadatos adicionales sobre el control de versiones si es necesario. |
| Control del publicador | Los publicadores deben opinar sobre los temas en los que se deben clasificar sus sitios. | La clasificación incorrecta de los sitios puede hacer que la señal de Topics sea un poco menos útil como indicador en general, pero los sitios específicos que se clasifican de forma incorrecta no son más ni menos afectados por esto que cualquier otro sitio. Esto se debe a que la información contextual de un sitio siempre estará disponible para subastas en su sitio, lo que proporcionaría información comparable con el tema correcto, incluso en el caso de una clasificación incorrecta. Nos complace recibir comentarios sobre este tema aquí. Permitir que los publicadores controlen su clasificación conlleva riesgos. Es posible que los sitios clasifiquen sus sitios de forma incorrecta de forma intencional, lo que reduciría la utilidad para todos o codificará significados sensibles en temas menos comunes, lo que afectaría la privacidad del usuario. |
| Extensiones de Chrome | Permite que las extensiones de Chrome administren y filtren Topics, de manera similar a las extensiones actuales de la administración de cookies | Como se explicó en GitHub, esto ya debería ser posible, pero agradecemos los comentarios adicionales del ecosistema. |
| Transición a la disponibilidad general | ¿Se verá algún impacto en la API de Topics cuando se pase de la prueba de origen a la disponibilidad general? | No se perderán datos para los usuarios que se cambien de la prueba de origen a la disponibilidad general. |
| Privacidad | Es posible que los nombres de host contengan información privada que podría revelar la API de Topics. | Tenemos una serie de mitigaciones para garantizar la privacidad, como se describe aquí. |
| Fraude y abuso | Cómo evitar la manipulación de Topics por parte de visitas fraudulentas | Las mitigaciones se explican aquí. |
| Clasificador de temas | ¿Los sitios web pueden solicitar modificar su clasificación de Topics? | Nos interesa conocer la opinión del ecosistema sobre este tema y recibir comentarios aquí. |
| Sitios de proveedores de temas | Designar ciertos sitios web que alojan contenido para muchos temas como "Sitios de proveedores de temas especiales" y entrena clasificadores basados en etiquetas proporcionadas en las páginas web. | Estamos debatiendo la propuesta aquí y agradecemos que nos envíes comentarios adicionales. |
API de Protected Audience (anteriormente, FLEDGE)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Conformación del tráfico | Impacto en el rendimiento del filtrado basado en la SSP para optimizar la carga de consultas por segundo (QPS) | Pasamos mucho tiempo pensando en la determinación por tráfico, y se recomienda que las SSP aprovechen el almacenamiento en caché. |
| Volumen de pruebas | Es difícil probar Protected Audience, ya que las SSP y las DSP tienen dificultades para obtener grandes volúmenes de tráfico. | Trabajamos constantemente con socios SSP y DSP para que adopten y prueben Protected Audience. Comenzó la disponibilidad general y estamos seguros de que el porcentaje de tráfico con PA será más atractivo para los socios cuando lo prueben. |
| Complejidad | La implementación de soluciones de Protected Audience requiere esfuerzos y costos considerables. | Reconocemos que es difícil adoptar tecnologías nuevas, como Privacy Sandbox. El equipo de Privacy Sandbox trabaja en estrecha colaboración con una amplia variedad de partes interesadas para educar y apoyar sus iniciativas, y evalúa continuamente a otros aceleradores para respaldar la adopción del ecosistema. |
| Entornos de ejecución confiables | Compatibilidad con entornos de ejecución confiables (TEE) en entornos de nube no públicos | Si bien estamos explorando opciones potencialmente compatibles más allá de las soluciones basadas en la nube, actualmente no es factible admitir TEE locales dadas las limitaciones de seguridad locales que requerirían una evaluación tediosa para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que continuar expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, agradecemos que nos envíes comentarios adicionales sobre por qué este requisito es necesario. |
| Estructura de costos | Ofertas y La propuesta de servicios de subasta aumentará el costo y la complejidad para las tecnologías publicitarias en comparación con los modelos del cliente. | Actualmente, estamos desarrollando una guía para estimar los costos de los flujos de trabajo de licitación y subastas en las campañas de ofertas y Servidor de subasta, que se correlacionará con el uso de tecnología publicitaria, cumpliendo con uno de los objetivos de nuestros diseños. |
| Cronologías de K-Anon | ¿Cuándo se aplicarán las restricciones planificadas de k-anonimato en `renderUrl` ? | Estamos trabajando en una explicación sobre el cronograma de aplicación que lanzaremos pronto. |
| Restricciones de runAdSubasta | ¿Chrome puede restringir a runAdAuction para que solo se pueda llamar desde la página principal? |
Si bien nuestro diseño admite por completo la posibilidad de llamar a runAdAuction desde la página principal, creemos que sería más perjudicial para los publicadores restringir la posibilidad de llamar solo desde el dominio principal.En específico, recibimos comentarios del ecosistema de que Privacy Sandbox necesita minimizar la carga de los publicadores y anunciantes. Esos comentarios se alinean con el principio general del desarrollo web de que los propietarios de sitios pueden usar herramientas de terceros para ejecutar sus sitios. El objetivo de Privacy Sandbox ha sido fomentar un ecosistema saludable sin necesidad de prescribir cómo funcionan los publicadores y las tecnologías publicitarias. Al permitir que el publicador elija cómo y quién llama a runAdAuction en su sitio, creemos que ofrecemos flexibilidad a los publicadores para encontrar la mejor ruta para sus requisitos. |
| Asistencia para la implementación | ¿Chrome puede crear una implementación de código abierto de una subasta de varios vendedores o contribuir a ella? | Privacy Sandbox tiene como objetivo desarrollar tecnologías que preserven la privacidad y no se basen en cookies de terceros ni en otros identificadores entre sitios. Queremos fomentar un ecosistema saludable sin necesidad de prescribir el funcionamiento de las tecnologías publicitarias. Publicamos orientación sobre el funcionamiento de las APIs en nuestro repositorio de GitHub y estamos dispuestos a explorar soluciones con la industria. No planeamos crear ninguna implementación específica, ya que nuestro objetivo principal es crear tecnologías de plataforma, no dictar estrategias para usar esas tecnologías. Nuestras tecnologías ayudarán a las empresas de tecnología publicitaria a ofrecer un mejor servicio a sus clientes con las barreras de privacidad adecuadas para ellos. |
| Subastas de varios vendedores | ¿Chrome forzará el uso compartido de mensajes ganador con las subastas de componentes? | La API de Protected Audience está diseñada para ofrecer a las partes que inician la subasta de varios vendedores la capacidad de pasar información a la subasta de componentes (nota: solo antes de iniciar la subasta). Dicho esto, no vemos ninguna forma de que el navegador distinga si la información es contextual o no, por lo que no pudimos imponer el bloqueo o la solicitud de cierta información. |
| Preferencia del usuario para el seguimiento del consentimiento | AdTech le pregunta a PA cómo implementar correctamente el seguimiento del consentimiento del usuario | Nuestra respuesta incluye lo que dijimos en el primer trimestre: "Para 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". Analizamos varias situaciones relacionadas con este problema durante la Reunión de Protected Audience de WICG de mayo y agradecemos los comentarios y debates adicionales sobre este tema. |
| Públicos personalizados | ¿Se admitirán los casos de uso de SSP relacionados con la creación de públicos personalizados con la API de Protected Audience? | La API de Protected Audience permite que las SSP y otros proveedores de tecnología publicitaria posean y administren públicos personalizados. Se está desarrollando más orientación sobre cómo una SSP puede integrarse con la API de PA. Esta se pondrá a disposición de las SSP y otros proveedores de tecnología publicitaria para respaldar sus iniciativas de integración. |
| Formatos | ¿Los videos son compatibles con la API de Protected Audience? | Los anuncios de video se publican de dos maneras: como XML de VAST o HTML (un anuncio outstream que, en última instancia, también puede cargar XML de VAST en un reproductor de video). Los compradores pueden mostrar cualquier formato a través de una renderURL. La especificación de VAST se actualizó recientemente para que sea compatible con la API de Attribution Reporting. Los sitios que publican anuncios de video deberán prepararse para la forma en que se publican los anuncios a través de la API de Protected Audience. Esto significa que debes asegurarte de que las etiquetas de posición puedan pasar la URL de un iframe de Protected Audience a un reproductor de video. En el caso de los marcos vallados, trabajaremos para abordar las necesidades de video antes de la necesidad de usar marcos vallados, que no será anterior a 2026. |
| Ritmo | ¿Cómo funciona el caso de uso de Pacing con la API de Protected Audience? | Agradecemos tus comentarios. Nos interesaría ver más instancias de esta solicitud con más detalles provenientes de más socios SSP, ya que hasta la fecha se trata principalmente de un problema relacionado con la DSP. |
| Frecuencia de actualización | Es posible que la frecuencia de las llamadas de dailyUpdate (hasta 1 por grupo de interés por día) no sea suficiente para ciertos casos de uso, como actualizar la información de un producto. |
Agradecemos tus comentarios. Hay otras soluciones disponibles para permitir que las tecnologías publicitarias usen indicadores que se actualizan en diferentes cadencias, como búsquedas de K/V. |
| Control de calidad de los anuncios | ¿Cómo implementan los publicadores el control de calidad de los anuncios? | Actualmente, la API de Protected Audience ofrece funciones para que los publicadores informen a sus SSP sobre ciertos controles que pueden establecer como parte de la configuración de la subasta previa a la oferta (es decir, listas de bloqueo basadas en etiquetas asociadas con anuncios). Agradecemos los comentarios sobre cualquier funcionalidad adicional que pueda requerir el ecosistema. |
| Depuración | ¿Cuándo se quitará la funcionalidad de forDebuggingOnly? |
Planeamos retirar forDebuggingOnly debido a eventos de pérdida por la baja de las cookies de terceros. Planeamos retirar forDebuggingOnly para los eventos de victoria en 2026 como muy pronto. |
| Grupos de interés multidispositivo | Propuesta para habilitar grupos de interés en dispositivos múltiples para usuarios-agentes autenticados | Estamos evaluando esta propuesta, pero la alta especificidad de la segmentación en varios dispositivos plantea importantes inquietudes sobre la privacidad, como se explica en este problema de GitHub. |
| Remarketing dinámico (también se informó en el primer trimestre) | ¿El remarketing dinámico seguirá siendo posible con la API de Protected Audience después de la baja de las cookies de terceros? | Creemos que este caso de uso es posible con Protected Audience, como se explica aquí. |
| Datos relacionados con los clics | Agrega datos relacionados con los clics a browserSignals. |
En este momento, solicitamos una aclaración sobre cuándo se hizo el clic para proporcionar una posición preliminar. |
| Funciones definidas por los usuarios en Protected Audience (también se informó en el 4o trim. de 2022) | ¿Cómo se admitirán las funciones definidas por el usuario (UDF) con la API de Protected Audience? Estas son funciones que los usuarios finales pueden programar para extender la funcionalidad de la API. | La tecnología publicitaria que planteó este problema también mencionó que todavía están evaluando lo que podrían hacer con el flujo unidireccional de datos, por lo que todavía no hay comentarios prácticos para los que se deba reaccionar, al menos hasta que esté disponible de manera general. |
| Moneda | Los importes de la moneda no deben representarse con puntos flotantes. | Abordamos este problema de forma detallada aquí. |
| Funciones de selección de anuncios que no son de DSP | ¿Qué rol desempeñan los servidores de anuncios en las subastas de la API de Protect Audience? | Conocemos las solicitudes de los servidores de anuncios para seguir ofreciendo servicios de selección de anuncios posteriores a la oferta y de optimización de creatividades dinámicas. Actualmente, estamos evaluando el análisis detallado de la brecha que existe entre la API de Protected Audience actual y estas solicitudes. |
| GenerateBid | Asistencia para Google Ads propuesta para mostrar más de un anuncio candidato por grupo de interés por el anuncio de generateBid y que esos candidatos obtengan una puntuación de "scoreAd". |
Se está evaluando. Nos gustaría recibir comentarios adicionales aquí. |
| Orden de subasta | ¿Se requiere que las subastas de la API de Protected Audience sean la última para ejecutarse, de modo que pueda obtener información del resultado de todas las demás subastas? | No hay requisitos técnicos para que la API de Protected Audience se ejecute en último lugar. |
| Navegación no iniciada por el usuario | Cómo exponer la navegación no iniciada por el usuario | Estamos revisando la solicitud y analizandola aquí . Agradecemos que nos envíes comentarios adicionales. |
| Almacenamiento en caché | La SSP no debe compilar los perBuyerSignals de una DSP determinada a partir de una caché si cambia el estado del usuario. | Entendemos que el almacenamiento en caché no funciona para todos los casos de uso de los indicadores por comprador y estamos evaluando otras opciones. Agradeceremos cualquier comentario adicional del ecosistema sobre si el almacenamiento en caché funcionaría en sus casos de uso. |
| Attribution Reporting y Protected Audience | ¿Cómo pueden funcionar en conjunto la API de Attribution Reporting y la de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience para los dos modos de la API de Attribution Reporting (informes de resumen y a nivel del evento). Compartimos más información sobre la mejora de la integración de la API de Protected Audience y de Attribution Reporting el 1 de junio. Puedes obtener más información aquí. |
| Extremo del servidor | ¿El extremo del servidor será el servidor de agregación confiable en el diseño final? | El extremo del servidor es un extremo que mantiene la tecnología publicitaria y es independiente de los servidores de agregación confiables que se usan para procesar los informes recopilados y transformados. Por el momento, no tenemos ningún cambio planificado para el extremo de los informes. El diseño actual tiene como objetivo garantizar que los propios informes agregables (con cargas útiles encriptadas) no filtren datos entre sitios, por lo que no debería ser necesario un extremo de confianza. Una complicación adicional es que es probable que diferentes tecnologías publicitarias tengan diferentes estrategias de lotes deseadas. Nos gustaría recibir comentarios adicionales aquí. |
| WebIDL | La especificación actual de la API de Protected Audience no es compatible con la especificación de WebIDL. | Estamos evaluando estos comentarios y analizando el problema aquí. |
| Administración del consentimiento | ¿Cómo se controlará el pase del indicador de consentimiento en la API de Protected Audience? | La información contextual no está dentro del alcance de la API de Protected Audience. Estamos analizando el problema y agradecemos que nos envíes comentarios adicionales. |
| Marketing basado en las cuentas | ¿Serían posibles casos de uso de marketing basado en cuentas? | La API de Protected Audience admite una variedad de casos de uso de marketing basados en el público. Seguimos entendiendo cómo la API de Protected Audience puede admitir mejor este caso de uso en particular y aceptamos recibir comentarios adicionales sobre este problema por parte del ecosistema. |
| Subasta de componente | ¿Qué puntuación obtienen los participantes de la subasta del componente? | Las subastas de componentes no asignan una puntuación a los grupos de interés directamente, sino que califican los anuncios y las ofertas que una DSP envía desde la función generateBid. La función generateBid() se ejecuta por grupo de interés, y la DSP muestra lo siguiente cuando ejecuta generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contribuciones externas | Solicitud para admitir contribuciones externas en la base de código de GitHub del servidor de pares clave-valor. | Queremos actualizar nuestros procesos relevantes para admitir contribuciones externas al código de GitHub. |
| Tamaño del grupo de interés | ¿Cuál es la cantidad máxima admitida de claves que admite IG? | El límite actual es de 50 KB para el tamaño de un IG y se cuentan las claves como parte de eso. Te invitamos a seguir conversando sobre el límite de tamaño. |
| Agrupación en lotes | ¿Cómo se puede reducir la cantidad de llamadas al servidor K/V? | Puedes usar los encabezados de control de caché HTTP para reducir la cantidad de llamadas K/V. Por ejemplo, se podrían almacenar en caché en las subastas de componentes y, también, en los espacios publicitarios de una sola página. |
| Control de versión | Compatibilidad con varias versiones de código de AdTech | Los servicios de ofertas y subastas admitirán varias versiones de código de tecnología publicitaria. En la API de Bidding and Auction, la solicitud SelectAd puede especificar la versión del código que se usa para la solicitud de subasta (es decir, para ofertas o subastas y también para los informes). |
| Almacenamiento compartido | Se admite la escritura en el almacenamiento compartido en el servicio de ofertas y subastas. | Actualmente, los Servicios de ofertas y subastas no admiten el almacenamiento compartido, pero agradecemos que nos envíes comentarios sobre por qué estos casos de uso son importantes para el ecosistema. |
| Web a aplicación | Admite el uso compartido de grupos de interés desde la Web a la app. | Actualmente, la opción de Web a app no está dentro del alcance de la implementación de la API de Protected Audience en Chrome y Android, pero nos interesa escuchar a nivel del ecosistema sobre la importancia de este caso de uso. |
| K‐anonimato | Cómo manejar los resguardos de K-Anonimato | Estamos analizando el problema y agradecemos que nos envíes comentarios adicionales. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Parámetros de configuración de informes de VTC alternativos a nivel del evento | Comentarios sobre las configuraciones de los informes de VTC alternativas a nivel del evento | Sabemos que los parámetros de configuración actuales a nivel del evento no son óptimos y estamos pidiendo comentarios sobre los parámetros de configuración globales óptimos. Estamos abiertos a recibir comentarios adicionales sobre este tema y creemos que nuestra explicación flexible a nivel del evento también ayuda a abordarlo. |
| Configuración flexible a nivel del evento | ¿Cuál es el estado de la función de configuración flexible a nivel del evento? | Compartimos documentación sobre la configuración flexible a nivel del evento. La función aún se encuentra en la etapa de propuesta y estamos esperando más comentarios sobre si será valiosa para el ecosistema. |
| Configuración flexible a nivel del evento | ¿Cómo se pueden conciliar informes contradictorios de diferentes partes? | La mayoría de las situaciones de informes se abordan a través del uso de informes agregados, mientras que la propuesta de configuración flexible a nivel del evento es específicamente para obtener flexibilidad adicional para los informes a nivel del evento, que se usan con mayor frecuencia en casos de uso de optimización. Agradeceremos cualquier comentario o comentario adicional sobre esta situación. |
| Registro de origen | ¿Qué sucede si el registro de la fuente ocurre después del registro del activador? | Actualmente, si un registro de fuente ocurre después del registro del activador, la fuente y el activador no podrán atribuirse entre sí. Esta parece ser una situación de caso límite. Agradecemos cualquier comentario adicional sobre este problema y trataremos de resolverlo si es una situación que aparentan encontrar muchas tecnologías publicitarias. |
| Cómo trabajar con varias agencias publicitarias | ¿Cómo pueden las DSP usar la API de Attribution Reporting cuando un anunciante trabaja con varias agencias de publicidad? | La API admite redireccionamientos; por lo tanto, puede usarse incluso cuando un anunciante trabaja con varias agencias de publicidad. Además, existen algunas limitaciones con respecto a los redireccionamientos para garantizar que la API mejore la privacidad. También identificamos una posible solución alternativa con la API de Shared Storage para la situación específica que presentó la tecnología publicitaria. Agradecemos cualquier comentario adicional sobre esta situación y seguiremos iterando en función de ellos. |
| Límites de destino | El caso de uso de los anuncios que se actualizan automáticamente puede verse afectado por tener límites de destino. | Analizamos este problema en la reunión de WICG del 1 de mayo y estamos buscando comentarios sobre cuál sería un límite razonable. Agregamos la explicación sobre Informes de atribución con informes a nivel del evento, en el que se indica que el navegador puede limitar la cantidad de eTLD+1 de "destino" representados por los sitios de origen. (Consulta la solicitud de extracción). |
| Attribution Reporting y Protected Audience | ¿Cómo pueden funcionar en conjunto la API de Attribution Reporting y la de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience para los dos modos de la API de Attribution Reporting (informes de resumen y a nivel del evento). Compartimos más información sobre la mejora de la integración de la API de Protected Audience y de Attribution Reporting el 1 de junio. Puedes obtener más información aquí. |
| Configuración flexible a nivel del evento | Comparte las prácticas recomendadas para la simulación de ruido ahora que los parámetros se pueden configurar. | Compartimos código en GitHub que cualquiera puede usar para evaluar la ganancia de información y el impacto del ruido de cualquier configuración flexible a nivel del evento que desee probar. Nos gustaría conocer la opinión de cualquier persona que elija probar el código y nos gustaría compartir comentarios. |
| Medición de atribución en la aplicación y en la Web | ¿Cuándo estará disponible la medición de atribución web y entre aplicaciones? | El 9 de mayo, anunciamos un experimento para la medición de atribución web y entre aplicaciones a través de la API de Attribution Reporting. Si bien está planificado la disponibilidad general para las APIs de relevancia y medición de Chrome 115, por el momento, no se planea que la medición entre apps y la atribución web alcance la disponibilidad general con Chrome 115. |
| Anulación de conversiones duplicadas | ¿Cómo se pueden conciliar las soluciones de medición independientes con la ARA? | Al igual que con la práctica estándar actual, los anunciantes trabajarían con un proveedor de medición independiente externo para anular la duplicación en los informes de conversiones. Ofrecemos recursos sobre cómo anular la duplicación de conversiones en los informes a nivel del evento. |
| Pérdida de datos durante las actualizaciones de la base de datos de Attribution Reporting | ¿Se perderán datos cuando Chrome actualice la base de datos de Attribution Reporting como se anunció? | A partir de la versión estable de Chrome 115, comenzaremos a habilitar las APIs de relevancia y medición para una parte de los usuarios de Chrome de forma predeterminada. Esta disponibilidad general aumentará a medida que supervisemos posibles problemas. El objetivo será alcanzar el 100% de disponibilidad durante un período de semanas, antes del tercer trimestre de 2023. Esto coincidirá con el final de la prueba de origen de relevancia y medición. A partir de julio, los verificadores podrán inscribirse para obtener acceso a estas APIs con disponibilidad general. Esto proporcionará una superposición entre la disponibilidad de la prueba de origen y la disponibilidad general durante la inscripción. Tu token de prueba de origen será válido hasta el 19 de septiembre, pero te recomendamos que te inscribas en las APIs antes del vencimiento para poder salir sin problemas de la prueba de origen sin interrumpir las pruebas en curso. Como se mencionó en este anuncio, los datos registrados en versiones anteriores (M113 y anteriores) no se migrarán después de la actualización, por lo que es posible que se pierdan datos. Esta pérdida de datos no se mostrará en los informes de depuración, y trataremos de evitar la pérdida de datos de 114 a 115. |
| Facturación | Cómo usar Attribution Reporting para la facturación de costo por conversión | Como se indica en este artículo, es posible que la API de Attribution Reporting no sea adecuada para las necesidades de facturación de costo por conversión debido a la interferencia que se agrega a los informes de resumen y a nivel del evento. Alentamos a los jugadores del ecosistema a compartir comentarios sobre el impacto en varios modelos de facturación mediante la API de Attribution Reporting en GitHub. |
Servicio de agregación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cambio de retraso de informe agregable | Reacciones positivas a la propuesta de cambiar el retraso del informe agregable de [10 a 60 min] a [0 a 10 min] después de los comentarios del ecosistema. | Nos complace ver la reacción positiva al cambio propuesto y alentamos al ecosistema a que siga enviando comentarios sobre nuestras propuestas. |
| Solución local | ¿Se puede implementar el servicio de agregación en centros de datos locales? | Si bien estamos explorando opciones potencialmente compatibles más allá de las soluciones basadas en la nube, actualmente no es factible admitir TEE locales dadas las limitaciones de seguridad locales que requerirían una evaluación tediosa para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que continuar expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, agradecemos que nos envíes comentarios adicionales sobre por qué este requisito es necesario. |
| Cómo volver a procesar informes para diferentes períodos | La capacidad de volver a procesar informes para diferentes períodos de tiempo | Recibimos solicitudes similares para poder dividir los lotes para diferentes períodos. Una propuesta es permitir la capacidad de extender el ID compartido con una etiqueta definida por tecnología publicitaria, de modo que los informes se puedan dividir en lotes diferentes. Nos encontramos en el proceso inicial de evaluación de este proceso y mantendremos el ecosistema actualizado a medida que esta propuesta evolucione. |
| Implicaciones de privacidad del entorno de ejecución confiable | Opinión positiva sobre las implicaciones de privacidad de los entornos de ejecución confiables | Nos complace escuchar las reacciones positivas del ecosistema con respecto a nuestras propuestas y agradecemos los comentarios adicionales a medida que seguimos iterando y desarrollando. |
| Condiciones del Servicio | ¿Cuál es la fecha límite para aceptar las Condiciones del Servicio del servicio de agregación? | Si bien aún no especificamos una fecha límite para aceptar los Términos y Condiciones, recomendamos a las empresas del ecosistema que lo hagan lo antes posible para evitar retrasos en la inscripción. Recomendamos a las empresas que se comuniquen con nosotros si tienen preguntas. |
| Descubrimiento de claves | La función de descubrimiento de claves permitirá que los verificadores consulten informes agregados sin necesidad de la lista explícita de posibles combinaciones de teclas para procesar informes resumidos para la atribución entre varias redes y, así, mejorar el rendimiento y la precisión. | Actualmente, estamos explorando posibles soluciones y soluciones, y agradecemos los comentarios adicionales del ecosistema. |
API de Private Aggregation
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Origen de los informes | ¿Cómo se define el origen de los informes? | El origen de los informes es siempre el origen de la secuencia de comandos del emisor de agregación privada. |
| Espacio de claves de 128 bits | Claridad en la limitación de espacio de la clave de 128 bits | Haremos que esta limitación de espacio de claves sea más clara y resolveremos las incoherencias entre las páginas. Recomendamos usar estrategias de hash para mantenerte dentro de este espacio de claves. |
| Contribución máxima por informe | El límite actual de 20 contribuciones por informe es demasiado bajo. | En lugar de aumentar la cantidad máxima de contribuciones, estamos dispuestos a considerar dividir los informes en lugar de truncarlos al límite. Interactuaremos con el ecosistema a medida que esta propuesta evolucione. |
| Informes de alcance | Solicitud de informes de alcance multiplataforma. El alcance es una métrica fundamental de la publicidad de marca. Los anunciantes utilizan las aproximaciones multiplataforma y para varios dispositivos para los informes de alcance y frecuencia para analizar sus campañas y asignar inversión. Los modelos de alcance usan cookies de terceros como indicadores para medir los anuncios que se muestran en entornos de terceros, por lo que las tecnologías publicitarias solicitaron una solución alternativa una vez que las cookies de terceros dejen de estar disponibles. |
El equipo de Privacy Sandbox está explorando funciones para admitir metodologías de alcance multidominio después de la baja de las cookies de terceros. Agradecemos los comentarios adicionales del ecosistema. |
Limita el seguimiento encubierto
Reducción de usuario-agente/Sugerencias de clientes de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También informado en el 1er trim. de 2023) Sugerencias sobre factores de forma adicionales | Solicitud de User-Agent Client Hints (UA-CH) para proporcionar factores de forma adicionales, como TV, RV | Seguimos trabajando en algunas decisiones de diseño clave (si proporcionar un valor único, como "TV", o una lista de capacidades de factores de forma), pero siguemos interesados en el prototipado de esta idea. |
| Presupuesto de privacidad | Las restricciones en el presupuesto de privacidad pueden provocar que las solicitudes de UA-CH no sean deterministas cuando se envíen demasiadas solicitudes. | En este momento, no tenemos actualizaciones nuevas sobre la propuesta de presupuesto de privacidad, pero nos comprometimos a no restringir las solicitudes de sugerencias de clientes de UA antes de que se den de baja las cookies de terceros. |
| Compatibilidad con sitios | Los sitios web utilizan la marca UA-CH para restringir el acceso de ciertos navegadores a los sitios. | Existen casos de uso válidos para tener una lista de marcas, y uno de ellos es precisamente la compatibilidad. Una UA tiene la libertad de tener varias marcas para solucionar estos problemas. |
Protección de IP (anteriormente Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Fraude y abuso | ¿Cómo pueden las empresas establecer medidas contra el fraude con IP Protection? | Comprendemos la importancia de los casos de uso antifraude y el posible impacto en ellos. Planeamos publicar más detalles sobre cómo respaldar la lucha contra el fraude a finales de este verano. Esperamos recibir comentarios sobre el ecosistema sobre cómo podemos admitir de mejor manera los casos de uso antifraude. |
| GeoIP | Más información sobre el cronograma de prueba y de implementación para GeoIP | Recientemente, Chrome publicó información nueva que detalla nuestros planes de GeoIP. Planeamos publicar más información sobre los cronogramas de implementación en el tercer trimestre. Inicialmente, esperamos lanzar IP Protection como una función de aceptación de los usuarios en un pequeño porcentaje de tráfico. Esto se debe a que reconocemos que esta propuesta puede implicar algunos cambios significativos para las empresas. Por ello, queremos darle tiempo al ecosistema para que se ajuste y proporcione comentarios antes de que la función se lance de forma más general. |
| Autenticación de cuenta | ¿Cómo funcionará exactamente la autenticación de cuenta con el servidor proxy? | Planeamos publicar más detalles sobre la autenticación de cuentas este verano, aunque ya compartimos algunas consideraciones iniciales. |
Mitigación del seguimiento por rebote
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Orientación para las pruebas | Información para probar la mitigación del seguimiento por rebote | En mayo, publicamos una entrada de blog con más información sobre cómo probar la mitigación del seguimiento por rebote. |
| Documentación | Claridad en la propuesta de seguimiento por rebote | La propuesta actual todavía está en desarrollo, y Chrome sigue actualizándola para brindar información y claridad al ecosistema. Estamos trabajando para proporcionar más detalles y agradecemos cualquier comentario adicional. |
| Eliminación de cookies | ¿La mitigación del seguimiento por rebote borrará todas las cookies de un dominio? | La mitigación de seguimiento por rebote (BTM) borrará todo el almacenamiento y toda la caché, como se explica aquí. |
| Cómo evitar la mitigación del seguimiento por rebote | La clasificación del seguimiento de rebote se puede omitir realizando redireccionamientos con ventanas emergentes o pestañas nuevas. | Aún se está trabajando en la especificación de la mitigación del seguimiento por rebote. Hasta ahora, nos hemos enfocado principalmente en los redireccionamientos en la misma pestaña, pero planeamos trabajar en los flujos de ventanas emergentes en el futuro. Nos gustaría recibir comentarios adicionales aquí. |
Presupuesto de privacidad
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Orientación por proximidad | El presupuesto de privacidad puede afectar los casos de uso de segmentación por proximidad. | Recibimos comentarios sobre este problema y nos gustaría conocer más sobre los posibles impactos del ecosistema. |
Fortalece los límites de privacidad entre sitios
Conjuntos propios
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en trimestres anteriores) Límite de dominios | Solicitud para ampliar la cantidad de dominios asociados | Chrome está evaluando el límite numérico adecuado para el subconjunto asociado que equilibrará la privacidad y la utilidad para los casos de uso que se identificaron. Desde el comienzo, Chrome compartió que la cantidad exacta del subconjunto asociado aún estaba sin definirse. |
| Caso de uso incorporado | Compatibilidad con casos de uso incorporados que requieren Conjuntos propios, CHIP y almacenamiento compartido | Chrome recibió los comentarios sobre este caso de uso. El equipo está investigando y acepta comentarios adicionales. |
| Administración de repositorios | Información sobre las políticas para quitar conjuntos propios del repositorio de GitHub si hay discrepancias o negligencias | Chrome recibió los comentarios sobre este caso de uso. El equipo está investigando el caso y acepta recibir comentarios adicionales. |
| Información del usuario | Chrome debería aumentar el reconocimiento y la comprensión de los conjuntos propios de los usuarios para impulsar la adopción. | Chrome se compromete a educar a los usuarios sobre los Conjuntos propios y, para ello, publicó un artículo del Centro de ayuda (vinculado desde la IU de Chrome). Chrome también invierte en seguir aprendiendo cómo educar mejor a los usuarios en los contextos apropiados. |
| Publicación en 3PCD | Las cookies de terceros seguirán existiendo en un Conjunto propio después de la baja de las cookies de terceros. | Si bien requestStorageAccess y requestStorageAccessFor hacen que las cookies de terceros vuelvan a estar disponibles para casos de uso específicos y claramente definidos, ahora requieren una invocación activa por parte del sitio, en lugar de estar disponibles de forma predeterminada, como con el estado actual de las cookies de terceros (en Chrome).Si bien esta invocación en un solo conjunto no requerirá la aprobación del usuario, los usuarios pueden inhabilitar este comportamiento en Configuración. Para obtener más información, consulta el artículo del Centro de ayuda (vinculado desde la IU de Chrome). Planeamos ampliar la guía para desarrolladores existente a medida que los FPS se aumenten hasta un 100%. |
| Envío de conjuntos propios | Cambia el nombre del .well-known/first-party-set requerido para incluir una extensión .json. |
Realizamos este cambio para asegurarnos de que se admitan ciertos planes de hosting web. |
| Registro de IANA | first_party_sets.JSON debe registrarse en IANA. |
Estamos considerando la propuesta y apreciamos que nos envíes comentarios adicionales aquí. |
API de Fenced Frames
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Bloqueo de anuncios | Los marcos vallados pueden facilitar que los bloqueadores de anuncios bloqueen los anuncios. | Las extensiones pueden interactuar con marcos vallados de manera similar a como interactuarían con iframes. Las extensiones también podrán ver la URL real a la que se navegará el marco vallado, por lo que pueden aplicar cualquier regla de coincidencia de URL para el bloqueo, como lo haría en los iframes. Si solo bloqueas todos los marcos vallados de forma incondicional, podría dañarse los casos de uso que no son anuncios. |
API de Shared Storage
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Adopción más amplia | El almacenamiento compartido debe ser un estándar de toda la industria disponible en todos los navegadores. | Aceptamos y agradecemos tus comentarios. Chrome sigue participando activamente en los foros del W3C para defender la propuesta, solicitar comentarios e impulsar la adopción. |
| Puertas de salida | Las puertas de salida del almacenamiento compartido son demasiado limitadas. | Estamos considerando estos comentarios y agradecemos los comentarios adicionales sobre el ecosistema sobre por qué las puertas de salida son demasiado limitadas. |
| Cumplimiento de las normativas | ¿Cómo manejará el almacenamiento compartido el cumplimiento de las normativas, como las políticas de retención de datos? | El almacenamiento compartido proporciona la flexibilidad de implementar y personalizar la lógica para controlar el ciclo de vida y el vencimiento de los datos almacenados. Las tecnologías publicitarias pueden actualizar o borrar los datos del almacenamiento compartido en función de marcas de tiempo de escritura. |
| A/B Testing | ¿Cómo se pueden realizar las pruebas A/B para el almacenamiento compartido y la API de Protected Audience? | Estamos trabajando para publicar más orientación sobre este asunto y esperamos compartir más detalles en el futuro. |
| Límite de almacenamiento compartido | ¿Qué sucederá una vez que se alcance el límite de almacenamiento compartido? | Si se alcanza el límite, no se almacenarán más entradas. |
| Acceso múltiple en la misma carga de página | ¿Qué sucede cuando se accede varias veces al almacenamiento compartido en la misma carga de página? | La mejor manera de controlar esto es a través de la función window.sharedStorage.append(key, value). En lugar de actualizar el valor de cada anuncio, lo que podría causar colisiones si hay varios anuncios. La función agregar simplemente agregará el nuevo valor al final del preexistente. |
| Funcionalidad de iframe | ¿El almacenamiento compartido admitirá ciertas funciones de iframe una vez que dejen de funcionar después de la baja de las cookies de terceros? | Después de que se dé de baja las cookies de terceros, el sitio de nivel superior particionará el almacenamiento local en iframes, pero no se bloquearán los iframes. Los datos del almacenamiento local de un iframe no se pueden replicar en varios sitios de nivel superior, pero el almacenamiento local se puede seguir utilizando dentro del iframe. |
CHIP
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Límite de particiones | 10 KiB por sitio particionado sigue siendo considerable y nos gustaría que se reduzca. | Firefox ya indicó una posición positiva en CHIPS. Para la compatibilidad con Webkit, recomendamos a los desarrolladores que envíen comentarios directamente a Apple sobre este problema de GitHub en relación con sus casos de uso en los que se prefieren las cookies particionadas en lugar del almacenamiento particionado. |
| Incorporaciones autenticadas | Los CHIP pueden afectar el flujo de acceso de SSO actual debido a que las particiones diferentes afectan a las incorporaciones autenticadas. | Tenemos la intención de aprovechar la API de Storage Access (con indicaciones de los usuarios) para admitir el caso de uso de incorporaciones autenticadas y, recientemente, enviamos un intent a prototipo. |
| Políticas de vida útil | ¿Se aplicarán las posibles políticas de ciclo de vida a las cookies propias? | Actualmente, no tenemos planes de imponer límites en la vida útil de las cookies propias. |
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Asistencia para la autorización de OAuth | Alineación con la autorización de permisos de OAuth que no sean de perfil | Buscamos activamente la opinión de la comunidad de identidad web a través del CG FedID de W3C sobre las mejores formas de respaldar la autorización más allá de la autenticación básica después de la baja de las cookies de terceros. |
| Compatibilidad con SAML | Alineación con los requisitos de compatibilidad con SAML | Después de la baja de las cookies de terceros, el equipo solicita activamente la opinión de las comunidades de investigación y educación sobre las necesidades de asistencia de SAML (además de la asistencia con OpenID-connect). |
Combate el spam y el fraude
API de Private State Token (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Explorar nuevos indicadores | Varios socios expresaron opiniones positivas sobre la exploración de los indicadores facilitados por el navegador sobre la integridad del dispositivo o la confianza del usuario. Por lo general, también son cautelosos con respecto a que los nuevos indicadores con propósitos específicos sean suficientes para mantener los niveles actuales de detección de fraudes. | Nos entusiasma explorar nuevas propuestas en conjunto dentro de la comunidad antifraude y de seguridad web, y también reconocer y compartir sus preocupaciones. Esa es la razón por la que "luchamos contra el spam y el fraude" fue un flujo de trabajo principal de Privacy Sandbox y el motivo por el que seguimos priorizando la inversión en la preservación de la seguridad web a medida que mejoramos la privacidad del usuario. |
| Comentarios positivos sobre PST | Varios socios expresaron su interés en probar o utilizar PST para diversos casos de uso antifraude o de seguridad web. | Nos complace escuchar el apoyo y el interés en seguir explorando nuevas soluciones que utilizan PST. Los recursos y códigos de muestra están disponibles en el sitio para desarrolladores de Chrome. Agradecemos que nos envíes tus comentarios. |
| Fraude y abuso | Orientación para la prevención y detección de fraudes publicitarios en la medición después de que las cookies de terceros dejen de estar disponibles cuando los identificadores ya no están disponibles. | Presentamos herramientas como los tokens de estado privado, que ayudan a recuperar parte de la señal que pierden las cookies de terceros con fines antifraude, pero con nuevos controles de privacidad implementados. Estamos invirtiendo activamente en nuevas propuestas contra el fraude y el abuso para preservar las capacidades con otros cambios de Privacy Sandbox. |
| Tasa de información de entidad emisora a origen | La tasa de información de entidad emisora a origen es lo suficientemente alta para identificar a los usuarios únicos. | Actualizamos la especificación para que sea más claro con respecto a qué datos del usuario se pueden transmitir usando tokens de estado privado. Por diseño, se pueden usar hasta seis claves públicas a la vez, lo que puede representar un “estado”. para un usuario en particular. Estos conjuntos de claves solo se pueden actualizar cada 60 días (excepto en casos excepcionales en los que se necesite una rotación de claves de emergencia), lo que ralentiza la posibilidad de unir datos del usuario adicionales a lo largo del tiempo. Con cualquier API web nueva, existe un equilibrio entre la utilidad proporcionada y la información neta del usuario nuevo que se proporciona. Estimamos que los PST alcanzan el equilibrio adecuado en cuanto a la protección de la privacidad del usuario y, al mismo tiempo, permiten casos de uso clave contra fraudes que se ven afectados por la baja de las cookies de terceros. |
| Recuperar integración | La integración de fetch es innecesaria y complicada. |
Usar fetch tiene ventajas y desventajas, y nos gustaría seguir estandarizado en el ecosistema web, pero creemos que es muy pronto para realizar este cambio hasta que tengamos una idea más clara de cómo será el estándar. Si surge un estándar, también estamos comprometidos con llevar a los desarrolladores web a ese estándar de manera responsable. |
| Ubicación del almacenamiento | Los parámetros de configuración de las claves de los tokens de estado privado se deben almacenar en la misma ubicación que el protocolo PrivacyPass. | Durante las pruebas durante la prueba de origen, los desarrolladores indicaron que preferían la flexibilidad de almacenar sus claves en URLs generales en lugar de en un directorio .well-known. El formato de compromiso de clave de PrivacyPass no es especialmente adecuado para una versión en la que los conjuntos de claves están destinados a permitir un "metadatos públicos" implícito. valor. Si una variante de PrivacyPass se estandariza con metadatos públicos (ya sea como POPRF, cegamiento RSA parcial o conjuntos de claves), podríamos pasar a una versión futura de PST para admitir eso. |
| Implementación del encabezado de la API | Preguntas relacionadas con la implementación del encabezado de la API | A medida que la API se estandariza y el ecosistema de uso de esta API madura, esperamos admitir tanto la versión estándar de esta API que no es encabezado, y potencialmente dar de baja la versión del encabezado si el uso es lo suficientemente bajo o si hay suficientes herramientas o asistencia para desarrolladores para las formas estándar de correlacionar las solicitudes de emisión y canje con otros datos. Estamos analizando el problema aquí. |
| Registro | ¿Es práctico hacer que las entidades emisoras se registren con los proveedores de navegadores? | Actualizamos la especificación para describir el proceso de registro de la entidad emisora para tokens de estado privado. Si bien usa su propio proceso, es similar a los planes de inscripción para el resto del trabajo de Privacy Sandbox, en el que les pedimos a las entidades emisoras que hagan una declaración pública sobre cómo pretenden usar la PST y que reconozcan las restricciones técnicas que protegen la privacidad del usuario. |