Informe trimestral del 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ó 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, Protected Audience 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 |
|---|---|---|
| Administración de datos y cumplimiento normativo | Orientación del ecosistema sobre el uso de Privacy Sandbox de conformidad con los requisitos normativos. | Al igual que con cualquier tecnología nueva, cada empresa es responsable de garantizar que el uso que haga de Privacy Sandbox satisfaga 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, publicamos documentación técnica extensa, que debería proporcionar la base para realizar las evaluaciones legales necesarias, y estamos trabajando para poner a disposición materiales adicionales en apoyo de los esfuerzos de las empresas para cumplir con los requisitos reglamentarios. |
| Propuesta de prueba cuantitativa de CMA | Más información sobre la propuesta de prueba cuantitativa de CMA | Estamos trabajando junto con la CMA para diseñar experimentos que brinden un panorama del impacto de la baja de las cookies de terceros y la introducción de las propuestas de Privacy Sandbox en el ecosistema. En abril, la CMA publicó orientación de alto nivel sobre lo que se puede esperar durante el período de prueba y prueba, seguida de orientación detallada en junio. Recomendamos que las preguntas o los comentarios sobre la propuesta de prueba cuantitativa de la CMA se compartan directamente con la CMA. |
| Modos de prueba facilitados de Chrome | Más información y aclaraciones sobre los cronogramas de pruebas | El 18 de mayo, publicamos una entrada de blog con más información sobre los dos modos de prueba facilitada de Chrome. Estos detalles no son definitivos. A medida que avancemos en el 3er trim. de 2023, publicaremos más lineamientos de implementación. |
| Almacenamiento particionado | ¿Se usará el almacenamiento particionado durante las pruebas facilitadas de 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, se habilitará 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 que se lleva a cabo para que Chrome solucione los problemas técnicos y las derivaciones de Privacy Sandbox que afecten 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 a fin de obtener más información sobre los foros públicos y privados para obtener comentarios y derivaciones. |
| 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 de la política y nos gustaría saber qué cronograma sería más adecuado para el ecosistema. |
| Número DUNS | Más información sobre el requisito del número DUNS para la inscripción y certificación | Los participantes pueden encontrar 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, por lo 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 es posible que se les solicite a los participantes que proporcionen información financiera, como los ingresos anuales de la empresa. Una vez completada 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 de 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 generará una superposición entre la disponibilidad de la prueba de origen y la disponibilidad 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 estimaran las tasas de sincronización y los ingresos para sus empresas. La metodología de los encuestados para responder sus preguntas individuales dependía de ellos. |
| Valores del parámetro | ¿Cómo se determinan los valores de 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. Todavía estamos definiendo muchos valores y agradecemos los comentarios sobre este tema. |
Mostrar anuncios y contenido relevantes
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Preservación de la privacidad | Investigación que evalúa la API de Topics sobre la preservación de la privacidad | Participamos de forma activa con la comunidad de investigación y presentamos nuestra investigación 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 participan en esta área. La API de Topics protege a los usuarios contra el seguimiento general en la Web, ya que dificulta demasiado su seguimiento a gran escala. En estos artículos, se muestra que lo estamos haciendo con éxito con la API de Topics. Es más privada que las cookies de terceros y protege a los usuarios mientras 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, incluidas las específicas de una región. | En respuesta a los comentarios anteriores del ecosistema, publicamos una entrada de blog el 15 de junio en la que detallamos una nueva taxonomía actualizada que incorpora varias mejoras después 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 (anteriormente CafeMedia) y Criteo. La taxonomía actualizada quita las categorías que, según sabemos, son menos útiles para dar lugar a las que coinciden mejor con los intereses de los anunciantes, a la vez que mantenemos nuestro compromiso de excluir los temas potencialmente sensibles. Recomendamos que el ecosistema revise la taxonomía más reciente y 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 estas actualizaciones. | Como se compartió en la entrada de blog reciente, esperamos que la taxonomía evolucione con el tiempo y que, finalmente, la administración de la taxonomía pase a una parte externa que represente a las partes interesadas de la industria. También compartimos el plan de adaptación en el grupo topics-announce. |
| Impacto en los indicadores propios | El aumento en la cantidad de temas en la reciente actualización de taxonomía puede ser muy valioso y, por lo tanto, desvaloriza otros indicadores propios basados en intereses. | En el informe del 1er trimestre de 2023, la CMA comentó lo siguiente: "Entendemos que Google ha estado analizando la nueva taxonomía propuesta con varios participantes del mercado en toda la cadena de suministro de tecnología publicitaria. Si bien algunos grandes publicadores afirmaron que una mayor utilidad de los temas aumentaría la presión competitiva sobre sus soluciones basadas en datos de origen, nuestra visión preliminar es que una mayor utilidad es mejor para la competencia en general, en particular para la capacidad de los publicadores más pequeños de seguir monetizando su inventario después de la baja de las cookies de terceros". Nuestra opinión está alineada con el comentario que realizó la CMA. |
| Utilidad para diferentes tipos de interesados | Las tecnologías publicitarias que actúan como SSP y DSP pueden tener ventajas significativas en comparación con otros participantes del ecosistema. | Nuestra respuesta no cambió con respecto a trimestres anteriores: "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 en estrecha colaboración con la CMA para garantizar que nuestro trabajo cumpla con estos compromisos. A medida que avanzan las pruebas de Privacy Sandbox, una de las preguntas clave que evaluaremos es el rendimiento de las nuevas tecnologías para los diferentes tipos de partes interesadas. Los comentarios son fundamentales en este sentido, especialmente 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". |
| Temas subordinados | Como los criterios de selección de temas son la frecuencia de las visitas al navegador, ¿la fragmentación de los segmentos hará que los temas subordinados no aparezcan nunca en primer lugar? | Actualmente, Chrome está evaluando otras metodologías de clasificación y explorando otros indicadores que podrían mejorarlo. Comunicaremos nuestros planes revisados al ecosistema a su debido tiempo. |
| Sensibilidad | El objetivo de la API de Topics debe ser garantizar que la información del usuario que se obtiene o deriva de la API de Topics sea menos sensible a nivel personal que la que se podría derivar de 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. Reconocemos 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 la taxonomía | Agrega ID, control de versiones y otras estructuras de metadatos a la taxonomía de temas. | Actualmente, incluimos el ID de la taxonomía en la respuesta de la API. A medida que avanzamos hacia la administración a largo plazo, tiene sentido revisar el objeto Topics y, luego, incluir metadatos adicionales sobre el control de versiones si es necesario. |
| Control del publicador | Los publicadores deben poder opinar sobre los temas en los que deben clasificarse sus sitios. | La clasificación incorrecta de los sitios puede hacer que el indicador de Topics sea un poco menos útil como indicador en general, pero los sitios específicos que se clasifican de forma errónea 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 las subastas en su sitio, lo que proporcionaría información comparable con el tema correcto, incluso en el caso de una clasificación errónea. Agradecemos los comentarios sobre este tema. 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 reduce la utilidad para todos, o codifiquen significados sensibles en temas menos comunes, lo que perjudica la privacidad del usuario. |
| Extensiones de Chrome | Permitir que las extensiones de Chrome administren y filtren los temas de forma similar a las extensiones actuales de Administración de cookies | Esto ya debería ser posible, como se explicó en GitHub, pero agradecemos los comentarios adicionales del ecosistema. |
| Transición a la disponibilidad general | ¿Habrá 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 de los usuarios que cambien de la prueba de origen a la disponibilidad general. |
| Privacidad | Los nombres de host pueden contener información privada que la API de Topics podría revelar | Contamos con varias mitigaciones para garantizar la privacidad, como se describe aquí. |
| Fraude y abuso | Cómo evitar la manipulación de Topics por medio de visitas fraudulentas | Las mitigaciones se explican aquí. |
| Clasificador de Topics | ¿Los sitios web pueden solicitar que se modifique su clasificación de Topics? | Nos interesa conocer la opinión del ecosistema sobre este tema y te damos la bienvenida aquí. |
| Sitios de proveedores de temas | Designa ciertos sitios web que alojan contenido para muchos temas como "Sitios especiales del Proveedor de temas" y entrena los clasificadores en función de las etiquetas proporcionadas en las páginas web. | Estamos debatiendo la propuesta aquí y agradecemos cualquier comentario adicional. |
API de Protected Audience (anteriormente, FLEDGE)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Determinación por tráfico | Impacto en el rendimiento del filtrado basado en SSP para optimizar la carga de consultas por segundo (QPS) | Invertimos una cantidad considerable de tiempo pensando en la determinación del tráfico, y la recomendación es que las SSP aprovechen el almacenamiento en caché. |
| Volumen de pruebas | Es un desafío 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 adoptar y probar Protected Audience. Comenzó la disponibilidad general y estamos seguros de que el porcentaje de tráfico con PA habilitado hará que sea más satisfactorio para los socios que lo prueben. |
| Complejidad | La implementación de las 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 brindar información y respaldar sus iniciativas, y está evaluando continuamente otras medidas 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ública | Si bien estamos explorando opciones potencialmente de respaldo más allá de las soluciones basadas en la nube, actualmente no es factible admitir TEE locales dadas las limitaciones de seguridad locales que requerirían una evaluación lenta para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que seguir expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, recibimos comentarios adicionales sobre por qué ese requisito es necesario. |
| Estructura de costos | La propuesta de servicios de ofertas y subastas aumentará el costo y la complejidad de las tecnologías publicitarias en comparación con los modelos del cliente. | Actualmente, estamos desarrollando una guía para calcular los costos de compatibilidad con los flujos de trabajo de ofertas y subastas en el servidor de ofertas y subastas, la cual se correlacionará con el uso de la tecnología publicitaria, lo que cumplirá uno de los objetivos de nuestros diseños. |
| Cronogramas de K-Anon | ¿Cuándo se aplicarán las restricciones planificadas de k-anonimato en `renderUrl` ? | Estamos trabajando en una explicación del cronograma de aplicación que lanzaremos pronto. |
| Restricciones de runAdSubasta | ¿Chrome puede restringir runAdAuction para que solo se pueda llamar desde la página principal? |
Si bien nuestro diseño admite que se pueda llamar a runAdAuction desde la página superior, creemos que sería más perjudicial para los publicadores restringirlo a fin de que solo se pueda llamar desde el dominio principal.El ecosistema de la plataforma nos informó que Privacy Sandbox debe minimizar la carga de los publicadores y anunciantes. Esos comentarios coinciden 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 es fomentar un ecosistema saludable sin necesidad de prescribir cómo funcionan los publicadores y las tecnologías publicitarias. Cuando permitimos que el publicador elija quién llama a runAdAuction en su sitio y cómo lo hace, creemos que les ofrecemos flexibilidad a los publicadores para que encuentren la mejor ruta para sus requisitos. |
| Asistencia para la implementación | ¿Chrome puede compilar o contribuir a una implementación de código abierto de una subasta de varios vendedores? | Privacy Sandbox tiene como objetivo desarrollar tecnologías que preserven la privacidad y no usen cookies de terceros ni otros identificadores entre sitios. Queremos promover un ecosistema saludable sin necesidad de prescribir cómo deben funcionar las tecnologías publicitarias. En nuestro repositorio de GitHub, publicamos lineamientos sobre cómo funcionan las APIs y estamos dispuestos a explorar soluciones con la industria. No planeamos crear ninguna implementación específica, ya que nuestra tarea principal es crear tecnologías de plataforma, no dictar estrategias para usar esas tecnologías. Nuestras tecnologías permitirán que las empresas de tecnología publicitaria atiendan mejor a sus clientes con las barreras de privacidad adecuadas para los consumidores. |
| Subastas de varios vendedores | ¿Chrome forzará el uso compartido de un ganador "contextual" con subastas de componentes? | La API de Protected Audience está diseñada para ofrecer a las partes que inician la subasta de varios vendedores la posibilidad 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 una información es un ganador contextual o no, por lo que no podemos forzar el bloqueo ni exigir cierta información. |
| Preferencia del usuario para el seguimiento del consentimiento | AdTech le pregunta al PA cómo implementar correctamente el seguimiento del consentimiento del usuario | Nuestra respuesta incluye lo que dijimos en el primer trimestre: "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". Analizamos varias situaciones relacionadas con este problema durante la reunión de Protected Audience de WICG y recibimos con gusto comentarios y debates sobre el tema. |
| Públicos personalizados | ¿La API de Protected Audience admitirá los casos de uso de SSP relacionados con la creación de públicos personalizados? | 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 y 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 una de estas dos formas: 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 devolver cualquiera de los formatos mediante una renderURL. La especificación de VAST se actualizó recientemente para admitir la API de Attribution Reporting. Los sitios que publiquen anuncios de video deberán prepararse para la forma en que se publican los anuncios mediante la API de Protected Audience. Esto significa asegurarse 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 Fenced Frames, trabajaremos para abordar las necesidades de video antes de usar Fenced Frames, no antes de 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 de más socios SSP, ya que, hasta la fecha, esto ha sido principalmente una preocupación relacionada 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 productos. |
Agradecemos tus comentarios. Hay otras soluciones disponibles para permitir que las tecnologías publicitarias usen indicadores que se actualizan en diferentes cadencias, como las búsquedas K/V. |
| Control de calidad del anuncio | ¿Cómo implementan los publicadores el control de calidad de los anuncios? | En la actualidad, la API de Protected Audience ofrece funciones para que los publicadores informen a sus SSP ciertos controles que pueden establecer como parte de la configuración de la subasta, antes de la oferta (es decir, listas de bloqueo basadas en etiquetas asociadas con anuncios). Agradecemos los comentarios sobre cualquier funcionalidad adicional que el ecosistema pueda requerir. |
| Depuración | ¿Cuándo se quitará la funcionalidad de forDebuggingOnly? |
Planeamos retirar forDebuggingOnly por eventos de pérdida por la baja de las cookies de terceros. Planeamos retirar forDebuggingOnly para los eventos ganadores en 2026 como mínimo. |
| Grupos de interés multidispositivo | Propuesta para habilitar grupos de intereses multidispositivo para usuarios-agentes autenticados | Estamos evaluando esta propuesta, pero la alta especificidad de la segmentación en varios dispositivos genera importantes inquietudes sobre la privacidad, como se explica en este problema de GitHub. |
| (También se informa en el primer trimestre) Remarketing dinámico | ¿El remarketing dinámico seguirá siendo posible con la API de Protected Audience después de que se den de baja las cookies de terceros? | Creemos que este caso de uso es posible si se utiliza Protected Audience, como se explica aquí. |
| Datos relacionados con los clics | Agregue datos relacionados con los clics a browserSignals. |
Solicitamos una aclaración sobre el momento en el que se hizo clic para dar una posición preliminar. |
| (También se informó en el cuarto trimestre de 2022) Funciones definidas por el usuario en Protected Audience | ¿Cómo se admitirán las funciones definidas por el usuario (UDF) en la API de Protected Audience? Se trata de 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 aún está evaluando lo que podría hacer con el flujo unidireccional de datos, por lo que aquí no hay comentarios prácticos para reaccionar, no hasta al menos la disponibilidad general. |
| Moneda | Los importes de la moneda no se deben representar mediante puntos flotantes. | Abordamos este problema en detalle aquí. |
| Capacidades 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? | Estamos al tanto de las solicitudes para que los servidores de anuncios sigan ofreciendo servicios de selección de anuncios posteriores a la oferta y de optimización de creatividades dinámicas. Estamos evaluando el análisis detallado de brechas que existe entre la API de Protected Audience actual y estas solicitudes. |
| GenerateBid | Se agregó compatibilidad con la propuesta de Google Ads para mostrar más de un anuncio candidato por grupo de interés de anuncios de generateBid y calificar a esos candidatos en "scoreAd". |
Se está evaluando. Recibiremos comentarios adicionales aquí. |
| Pedido de subasta | ¿Las subastas con la API de Protected Audience deben ser las últimas en publicarse para que puedan 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 | Exponer la navegación no iniciada por el usuario | Estamos revisando esta solicitud y la analizamos aquí y agradecemos que nos envíes más comentarios. |
| Almacenamiento en caché | La SSP no debe compilar los perBuyerSignals de una DSP determinada desde una caché si cambia el estado del usuario. | Entendemos que el almacenamiento en caché no funciona en todos los casos de uso de los indicadores perBuyer, por lo que estamos evaluando otras opciones. Agradecemos cualquier comentario adicional del ecosistema sobre si el almacenamiento en caché funcionará en sus casos de uso. |
| Informes de atribución y público protegido | ¿Cómo pueden funcionar en conjunto la API de Attribution Reporting y la API de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience en los modos de la API de Attribution Reporting (informes de resumen y a nivel del evento). Compartimos más información sobre la integración mejorada de la API de Protected Audience y Attribution Reporting el 1 de junio. Puedes obtener más información aquí. |
| Extremo del servidor | En el diseño final, ¿el extremo del servidor será el servidor de agregación confiable? | El extremo del servidor es uno 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 previsto ningún cambio para el extremo de informes. El diseño actual tiene como objetivo garantizar que los 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 las diferentes plataformas de tecnología publicitaria tengan diferentes estrategias deseadas de lote. Recibiremos comentarios adicionales aquí. |
| WebIDL | La especificación actual de la API de Protected Audience no es compatible con la de WebIDL. | Estamos evaluando estos comentarios y analizamos el problema aquí. |
| Administración de consentimiento | ¿Cómo se controlará el paso de indicadores de consentimiento en la API de Protected Audience? | La información contextual no está dentro del alcance de la API de Protected Audience. Estamos debatiendo este tema y recibiremos más comentarios al respecto. |
| 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 comprendiendo cómo la API de Protected Audience puede brindar la mejor asistencia a este caso de uso en particular y damos la bienvenida a los comentarios adicionales del ecosistema. |
| Subasta de componentes | ¿Qué califican los participantes de la subasta de componentes? | Las subastas de componentes no califican directamente los grupos de interés, sino que asignan una puntuación a los anuncios y las ofertas que una DSP envía a partir de 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. | Esperamos actualizar nuestros procesos relevantes para respaldar las contribuciones externas al código de GitHub. |
| Tamaño del grupo de interés | ¿Cuál es la cantidad máxima de claves que admite IG? | El límite actual es de 50 KB en el tamaño de un IG, y las claves cuentan como parte de este. Nos encantaría recibir más debates sobre el límite de tamaño. |
| Agrupación en lotes | ¿Cómo se puede reducir la cantidad de llamadas al servidor de K/V? | Puedes usar encabezados de control de caché HTTP para reducir la cantidad de llamadas de K/V. Por ejemplo, podría almacenarse en caché en subastas de componentes y también en espacios publicitarios de una sola página. |
| Control de versión | Compatibilidad con varias versiones del código de tecnología publicitaria | Los servicios de ofertas y subastas admitirán varias versiones del 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, subastas y también informes). |
| Almacenamiento compartido | Compatibilidad con la redacción de contenido para el almacenamiento compartido en el servicio de ofertas y subastas | Actualmente, los Servicios de ofertas y subastas no son compatibles con el almacenamiento compartido, pero aceptamos comentarios adicionales que expliquen por qué estos casos de uso son importantes para el ecosistema. |
| Web a app | Admite el uso compartido de la Web a la app de los grupos de interés. | Por el momento, la función de Web a app no se aplica a la implementación de la API de Protected Audience en Chrome y Android, pero nos interesa conocer la importancia de este caso de uso en el ecosistema. |
| K-Anonimato | Cómo manejar los resguardos de K-Anonymity | Estamos debatiendo el problema y recibiremos comentarios adicionales. |
Medición de anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Configuraciones alternativas de informes a nivel del evento de VTC | Comentarios sobre configuraciones alternativas de informes de VTC a nivel del evento | Recibimos comentarios de que las configuraciones actuales a nivel de evento no son óptimas y solicitamos comentarios sobre configuraciones globales óptimas. Estamos dispuestos a recibir comentarios adicionales sobre este tema y creemos que nuestra explicación flexible a nivel del evento también ayuda a abordar este problema. |
| 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 está en la etapa de propuesta, y estamos buscando más comentarios sobre si será valiosa para el ecosistema. |
| Configuración flexible a nivel del evento | ¿Cómo se pueden conciliar los informes en conflicto de distintas partes? | La mayoría de los casos de generación de informes se abordan mediante el uso de informes agregados, mientras que la propuesta de configuración flexible a nivel del evento es específicamente para la flexibilidad adicional de los informes a nivel del evento, los cuales se utilizan con mayor frecuencia para los casos de uso de optimización. Agradeceremos cualquier comentario o comentario adicional sobre el ecosistema en relación con 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 se produce después del registro del activador, la fuente y el activador no se podrán atribuir entre sí. Este parece ser un caso límite. Agradecemos cualquier comentario adicional sobre este problema y trataremos de solucionarlo si es una situación a la que se enfrentan 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 que se puede usar incluso cuando un anunciante trabaja con varias agencias publicitarias. 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 mediante la API de Shared Storage para el escenario específico 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 los límites de destino. | Analizamos este tema en la reunión de WICG del 1 de mayo y estamos buscando comentarios sobre cuál sería el límite razonable. Agregamos la explicación de Informes de atribución con informes a nivel del evento para indicar que el navegador puede limitar la cantidad de eTLD+1 de "destino" representados por los sitios de origen. (Consulta la solicitud de extracción). |
| Informes de atribución y público protegido | ¿Cómo pueden funcionar en conjunto la API de Attribution Reporting y la API de Protected Audience? | Actualmente, las integraciones están disponibles para la API de Protected Audience en los modos de la API de Attribution Reporting (informes de resumen y a nivel del evento). Compartimos más información sobre la integración mejorada de la API de Protected Audience y 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. | Tenemos un código compartido en GitHub que cualquier persona puede usar para evaluar la ganancia de información y el impacto del ruido para cualquier configuración flexible a nivel de evento que desee probar. Nos encantaría conocer la opinión de cualquier persona que elija hacer una prueba con el código y que quiera compartir sus comentarios. |
| Medición de atribución entre apps y la Web | ¿Cuándo estará disponible la medición de atribución web y entre apps? | El 9 de mayo, anunciamos un experimento para la medición de atribución entre aplicaciones y sitios web a través de la API de Attribution Reporting. Si bien está prevista la disponibilidad general para las APIs de relevancia y medición en Chrome 115, la medición de atribución entre apps y la Web no está planificada actualmente para alcanzar la disponibilidad general con Chrome 115. |
| Anula conversiones duplicadas | ¿Cómo se pueden conciliar las soluciones de medición independientes con las ARA? | Al igual que con la práctica estándar actual, los anunciantes trabajarían con un proveedor de medición externo independiente para anular las conversiones duplicadas en los informes. Ofrecimos recursos sobre cómo anular las conversiones duplicadas para 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 de forma predeterminada las APIs de relevancia y medición para algunos usuarios de Chrome. 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 3er trimestre de 2023. Esto coincidirá con la finalización de la prueba de origen de relevancia y medición. A partir de julio, los verificadores podrán inscribirse para acceder a estas APIs con disponibilidad general. Esto generará una superposición entre la disponibilidad de la prueba de origen y la disponibilidad general por medio de la inscripción. El token de la prueba de origen será válido hasta el 19 de septiembre, pero te recomendamos que te inscribas en las APIs antes del vencimiento para realizar la transición sin interrupciones y sin interrumpir las pruebas en curso. Como se mencionó en este anuncio, los datos registrados de 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 utilizar 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 información irrelevante que se agrega a los informes a nivel del evento y de resumen. Alentamos a los participantes del ecosistema a compartir comentarios sobre el impacto en varios modelos de facturación a través de la API de Attribution Reporting en GitHub. |
Servicio de agregación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cambio en el retraso del informe agregable | Reacciones positivas a la propuesta de cambiar el retraso del informe agregable para que pase de [10 a 60 min] a [0-10 min] después de los comentarios del ecosistema | Nos complace ver una 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 de respaldo más allá de las soluciones basadas en la nube, actualmente no es factible admitir TEE locales dadas las limitaciones de seguridad locales que requerirían una evaluación lenta para Privacy Sandbox. Teniendo en cuenta los requisitos de seguridad de Privacy Sandbox y los desafíos significativos que presentan las implementaciones locales, creemos que seguir expandiendo y mejorando las implementaciones basadas en la nube (p.ej., admitir GCP además de AWS) es lo más beneficioso para el ecosistema. Sin embargo, recibimos comentarios adicionales sobre por qué ese requisito es necesario. |
| Volver a procesar informes para diferentes períodos de tiempo | La capacidad de volver a procesar informes para diferentes períodos de tiempo. | Recibimos solicitudes similares para poder dividir lotes en diferentes períodos. Una propuesta es permitir que se extienda el ID compartido con una etiqueta definida por la tecnología publicitaria para que los informes se dividan en diferentes lotes. Nos encontramos en el proceso inicial de evaluar este proceso y mantendremos el ecosistema actualizado a medida que evolucione la propuesta. |
| Implicaciones de privacidad del entorno de ejecución confiable | Opiniones positivas 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 los acepten lo antes posible a fin de evitar retrasos en la inscripción. Recomendamos a las empresas que se comuniquen con nosotros si tienen alguna pregunta. |
| Descubrimiento clave | La función de descubrimiento de claves permitirá a los verificadores consultar informes agregados sin necesidad de una lista explícita de combinaciones de claves posibles para procesar informes de resumen para la atribución entre redes y mejorar el rendimiento y la precisión. | 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 llamador de la agregación privada. |
| Espacio de claves de 128 bits | Claridad en el límite de espacio de claves de 128 bits | Aclararemos esta limitación del espacio de claves y resolveremos las incoherencias entre las páginas. Recomendamos usar estrategias de hash para no exceder 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 dividir los informes en vez de truncarlos según el límite establecido. Nos involucraremos en el ecosistema a medida que evolucione esta propuesta. |
| Informes de alcance | Solicita informes de alcance multiplataforma y de dispositivos múltiples. El alcance es una métrica fundamental de la publicidad de marca. Los anunciantes recurren a las aproximaciones multiplataforma y multidispositivo para los informes de alcance y frecuencia a fin de analizar sus campañas y asignar la inversión. Los modelos de alcance usan cookies de terceros como un indicador para medir los anuncios que se muestran en entornos de terceros. Por lo tanto, 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 las 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 del usuario-agente/Sugerencias de clientes de usuario-agente
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| (También se informó en el primer trimestre de 2023) Sugerencias para factores de forma adicionales | Solicitud de User-Agent Client Hints (UA-CH) para proporcionar factores de forma adicionales, como TV o RV | Aún estamos trabajando en algunas decisiones de diseño clave (ya sea proporcionar un solo valor, 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 de presupuesto de privacidad pueden hacer que las solicitudes de UA-CH se vuelvan no deterministas cuando se envían demasiadas solicitudes. | No tenemos actualizaciones nuevas sobre la propuesta de presupuesto de privacidad en este momento, pero nos comprometimos a no restringir las solicitudes de sugerencias de clientes de UA antes de que las cookies de terceros dejen de estar disponibles. |
| 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. En una UA, es gratis tener varias marcas para solucionar estos problemas. |
Protección de IP (anteriormente conocido como Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Fraude y abuso | ¿Cómo pueden las empresas establecer medidas antifraude con la protección de IP? | Comprendemos la importancia de los casos de uso contra el fraude y su posible impacto en ellos. Planeamos publicar más detalles sobre el apoyo a la lucha contra el fraude más adelante este verano. Queremos recibir comentarios sobre el ecosistema sobre cómo podemos brindar una mejor asistencia en los casos de uso de la lucha contra el fraude. |
| GeoIP | Más información sobre el cronograma de pruebas y de implementación para GeoIP | Recientemente, Chrome publicó nueva información 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 la protección de IP como una función de aceptación del usuario 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, y queremos darle tiempo al ecosistema para adaptarse y proporcionar comentarios antes de lanzar la función de forma más general. |
| Autenticación de cuenta | ¿Cómo funcionará exactamente la autenticación de la cuenta con el servidor proxy? | Planeamos publicar más detalles sobre la autenticación de cuentas más adelante este verano, aunque ya compartimos algunas consideraciones iniciales. |
Mitigación del seguimiento por rebote
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Lineamientos 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 es, en gran medida, un trabajo en curso, y Chrome continúa 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 la caché, como se explica aquí. |
| Elusión de la mitigación del seguimiento por rebote | La clasificación del seguimiento de rebote se puede omitir mediante la realización de redireccionamientos con ventanas emergentes o pestañas nuevas. | Aún estamos trabajando en la especificación de mitigación del seguimiento por rebote. Hasta ahora, nos hemos centrado principalmente en los redireccionamientos de la misma pestaña, pero planeamos trabajar en los flujos de ventanas emergentes en el futuro. Recibiremos 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 el tema y nos gustaría conocer más sobre el impacto potencial del ecosistema. |
Fortalecer 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 expandir 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 en los casos de uso que se identificaron. Desde el inicial, Chrome compartió que todavía no se completaba la cifra exacta para el subconjunto Associated. |
| Caso de uso incorporado | Compatibilidad con casos de uso incorporados que requieren conjuntos propios, CHIP y almacenamiento compartido | Chrome recibió comentarios sobre este caso de uso. El equipo está investigando el caso 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 negligencia | Chrome recibió comentarios sobre este caso de uso. El equipo está investigando y agradecemos que envíes comentarios adicionales. |
| Educación del usuario | Chrome debe aumentar el reconocimiento y la comprensión de los conjuntos propios para fomentar la adopción por parte de los usuarios. | Chrome tiene el compromiso de educar a los usuarios sobre los conjuntos propios y publicó un artículo del Centro de ayuda (vinculado desde la IU de Chrome) a tal efecto. Chrome también está comprometido con seguir aprendiendo cuál es la mejor manera de educar a los usuarios en los contextos adecuados. |
| Publicación de 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 la invocación activa por parte del sitio, en lugar de estar disponibles de forma predeterminada, como sucede con el estado actual de las cookies de terceros (en Chrome).Si bien esta invocación dentro de un solo conjunto no requerirá la aprobación del usuario, los usuarios pueden evitarlo si rechazan este comportamiento en Configuración. Hay más información disponible para los usuarios en el artículo del Centro de ayuda (vínculo desde la IU de Chrome). Planeamos ampliar la guía para desarrolladores existente a medida que el FPS aumente 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 recibimos comentarios adicionales aquí. |
API de Fenced Frames
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Bloqueo de anuncios | Los marcos cercados pueden facilitar que los bloqueadores de anuncios bloqueen los anuncios. | Las extensiones pueden interactuar con marcos cercados de manera similar a como interactuarían con los iframes. La URL real a la que se va a navegar por el marco vallado también será visible para las extensiones y, por lo tanto, pueden aplicar cualquier regla de coincidencia de URL para el bloqueo como lo harían en los iframes. Si simplemente bloqueas incondicionalmente todos los fotogramas vallados, es posible que dejen de funcionar los casos de uso de marcos vallados que no sean 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 la industria que esté disponible en todos los navegadores. | Apreciamos y agradecemos estos comentarios. Chrome sigue participando activamente en los foros de W3C para defender la propuesta, obtener comentarios e impulsar la adopción. |
| Puertas de salida | Las puertas de salida de almacenamiento compartido son demasiado limitadas. | Consideramos 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 la vida útil y el vencimiento de los datos almacenados. Las tecnologías publicitarias pueden actualizar o borrar datos de almacenamiento compartido en función de marcas de tiempo de escritura. |
| A/B Testing | ¿Cómo se pueden realizar las pruebas A/B para la API de Shared Storage y 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 de agregar simplemente agregará el nuevo valor al final del valor preexistente. |
| Funcionalidad de iframe | ¿El almacenamiento compartido admitirá ciertas funciones de iframe una vez que dejen de funcionar tras la baja de las cookies de terceros? | Después de la baja de las cookies de terceros, el almacenamiento local de los iframes se dividirá por el sitio de nivel superior, pero los iframes en sí no se bloquearán. 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 que los desarrolladores le proporcionen comentarios a Apple directamente sobre este problema de GitHub con respecto a 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 al SSO actual debido a que las diferentes particiones 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 las incorporaciones autenticadas y, recientemente, enviamos un intent-to-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 de por vida a las cookies propias. |
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Asistencia de autorización de OAuth | Alinearse con la autorización de permisos de OAuth que no son de perfil | Buscamos activamente comentarios de la comunidad de identidad web a través de los FedID CG del 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 | Cumplen con los requisitos de la compatibilidad con SAML. | El equipo busca activamente la opinión de las comunidades educativas y de investigación sobre las necesidades de asistencia de SAML (además de la asistencia con OpenID-connect) después de la baja de las cookies de terceros. |
Combate el spam y el fraude
API de Private State Token (y otras)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Explorar indicadores nuevos | Varios socios expresaron opiniones positivas respecto de la exploración de indicadores facilitados por el navegador sobre la integridad de los dispositivos o la confianza de los usuarios. En general, también son cautelosos cuando los nuevos indicadores basados en propósitos específicos son suficientes para mantener los niveles actuales de detección de fraudes. | Nos entusiasma explorar nuevas propuestas en conjunto dentro de la comunidad contra el fraude y la seguridad web. Además, reconocemos y compartimos sus inquietudes. Esa es la razón por la que “luchar contra el spam y el fraude” ha sido una corriente de trabajo fundamental de Privacy Sandbox y por qué seguimos priorizando la inversión para preservar la seguridad web a medida que mejoramos la privacidad de los usuarios. |
| Comentarios positivos en PST | Varios socios expresaron su interés en probar o utilizar las PST para varios casos de uso de seguridad web o antifraude. | Nos complace saber que tenemos asistencia y nos interesa explorar más soluciones nuevas que utilicen PST. Disponemos de recursos y código de muestra en el sitio para desarrolladores de Chrome, por lo que agradecemos que nos envíes más comentarios. |
| Fraude y abuso | Orientación para la prevención y detección de fraudes publicitarios en la medición después de la baja de las cookies de terceros 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 perdida por las cookies de terceros con fines antifraude, pero con nuevos controles de privacidad implementados. Invertimos activamente en nuevas propuestas antifraude y antiabuso para preservar las capacidades con otros cambios de Privacy Sandbox. |
| Tasa de información de la entidad emisora al origen | El porcentaje de información de la entidad emisora al origen es lo suficientemente alto como para identificar usuarios únicos. | Actualizamos la especificación para que sea más clara sobre los datos del usuario que se pueden transmitir mediante los tokens de estado privado. Por diseño, se pueden usar hasta seis claves públicas al mismo tiempo, 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 necesita una rotación de claves de emergencia), lo que ralentiza la posibilidad de unir datos adicionales del usuario con el tiempo. Con cualquier API web nueva, se obtiene un equilibrio entre la utilidad proporcionada y la información neta del usuario nuevo que brinda. Estimamos que los PST logran el equilibrio adecuado en la protección de la privacidad del usuario y, a la vez, permiten los casos de uso clave antifraude afectados por la baja de las cookies de terceros. |
| Integración de Fetch | La integración de fetch es innecesaria y complicada. |
Existen ventajas y desventajas en cuanto al uso de fetch, y nos gustaría continuar con la estandarización del ecosistema web, pero creemos que sería demasiado 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 nos comprometemos a realizar la transición responsable de los desarrolladores web a ese estándar. |
| Ubicación del almacenamiento | Los parámetros de configuración de la clave de los tokens de estado privado deben almacenarse en la misma ubicación que el protocolo de PrivacyPass. | Mientras realizaban pruebas durante la prueba de origen, los desarrolladores indicaron que preferían la flexibilidad para almacenar sus claves en URLs generales en lugar de un directorio .well-known. El formato de compromiso de clave en PrivacyPass no es particularmente adecuado para una versión en la que los conjuntos de claves están diseñados para permitir un valor de "metadatos públicos" implícito. Si una variante de PrivacyPass se estandariza con metadatos públicos (ya sea como POPRF, cegamiento parcial de RSA o conjuntos de claves), es posible que cambiemos a una versión futura de PST para admitir esa opción. |
| Implementación del encabezado de la API | Preguntas relacionadas con la implementación de encabezados de la API | A medida que se estandariza la API y el uso del ecosistema de esta API evoluciona, es de esperar que podamos admitir la versión estándar sin encabezado de esta API y, finalmente, 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 relacionar las solicitudes de emisión o canje con otros datos. Estamos debatiendo el problema aquí. |
| Registro | ¿Es práctico hacer que las entidades emisoras se registren con proveedores de navegadores? | Actualizamos la especificación para describir el proceso de registro de la entidad emisora de los 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 los que les pedimos a las entidades emisoras que hagan una declaración pública sobre cómo pretenden usar las PST y que acepten las restricciones técnicas que protegen la privacidad del usuario. |