Informe trimestral del tercer 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
- TE
- 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, no hay API ni tecnología específicas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Preparación para el ecosistema | Las SSP destacaron una preocupación por el hecho de que los publicadores no estaban listos ni realizaban el trabajo de implementación requerido. | Privacy Sandbox se enfoca específicamente en brindar información a los publicadores, lo que incluye seminarios en línea y reuniones exclusivos con publicadores y SSP que presentan para impulsar el trabajo de implementación. |
| Baja de las cookies de terceros | La preocupación por la baja de las cookies de terceros (3PCD) aumentó en el 4o trimestre de 2023 debido al corte de tecnología de la industria. | El cronograma de Privacy Sandbox se debatió con la CMA, con una secuencia que conducirá a una segunda mitad de la preparación para 2024. Privacy Sandbox publicará información más detallada sobre la secuencia de la ampliación de 3PCD. En virtud de los Compromisos, 3PCD está sujeto a las inquietudes de competencia de la CMA que se abordan. |
| Google Ad Manager | Google Ad Manager se niega a exponer la superficie de la API, lo que dificulta la prueba. | Respuesta proporcionada por Google Ad Manager: Por los motivos que se explican en esta respuesta de Google Ad Manager, los planes de Google Ad Manager para su integración de la API de Protected Audience no incluyen la compatibilidad con el servidor de anuncios del publicador de Google sin el control de la subasta de nivel superior. |
| Google Ad Manager | Google Ad Manager tiene un precio mínimo secreto que solo se expone a las SSP de AdX o de Open Bidding. | En la documentación pública de Google Ad Manager, se indica que el ganador de la subasta contextual se pasa a la lógica de puntuación de nivel superior y no a la subasta de ningún componente, incluidos Open Bidding o AdX. Además, esa documentación dice sobre la lógica de puntuación de nivel superior: "Ad Manager comparará la oferta ganadora de la subasta de cada componente, incluida la subasta de componentes propia de Ad Manager para las ofertas basadas en el grupo de interés de sus compradores, así como el mejor anuncio contextual (que se selecciona mediante asignación dinámica), y publicará el anuncio con la oferta más alta". |
| Google Ad Manager | Los productos de Google Ads deben estar sujetos a las mismas reglas que los productos publicitarios de terceros. | Los productos de Google Ads ya están sujetos a las mismas reglas que los terceros. |
| Pruebas facilitadas de Chrome | Agrega etiquetas para los navegadores que no estén en A ni B. | No consideramos hacerlo en este momento, ya que en nuestra investigación se descubrió que agregar etiquetas que no pertenecen a experimentos puede complicar las inquietudes de privacidad en torno al tráfico en modo Incógnito. |
| Agencia publicitaria | ¿Las agencias o empresas que no tienen JavaScript en los sitios web pueden usar las APIs de Privacy Sandbox? | Cualquier persona puede llamar a las APIs de Privacy Sandbox. Si una agencia o alguien más quiere crear tecnologías directamente en las APIs, puede hacerlo. Las APIs del cliente requieren integración con el cliente, al igual que las cookies. Muchas de las APIs, como las cookies, también tienen una interfaz de encabezado HTTP. Ya vimos un marco de trabajo para la industria publicitaria, Prebid, que desarrolla integraciones del cliente con las APIs. Otras organizaciones podrían hacer lo mismo. |
| Soluciones del cliente | ¿Por qué Google adopta soluciones del cliente para Privacy Sandbox si un ingeniero expresó su preocupación por la escalabilidad de esas soluciones en 2012? | La tecnología que mejora la privacidad (PET) como campo de estudio evolucionó de manera significativa desde 2012 y, con ella, las aplicaciones comercialmente viables. En el núcleo de Privacy Sandbox hay combinaciones de PET que no habrían sido viables hace más de una década. Además, la capacidad de procesamiento personal aumentó, al igual que las expectativas de los consumidores respecto de los navegadores y las expectativas regulatorias de privacidad. |
| Aprendizaje automático | ¿Cuál es el uso previsto de Google de Privacy Sandbox para fines de aprendizaje automático? | Gran parte del ecosistema de tecnología publicitaria usa aprendizaje automático en la actualidad, y no esperamos que eso cambie. Privacy Sandbox no impide que las empresas de tecnología publicitaria ni nadie más sigan usando el aprendizaje automático. Privacy Sandbox tampoco requiere que las empresas que se integran con sus APIs usen aprendizaje automático. Es razonable esperar que las empresas sigan creando productos y servicios de maneras que satisfagan las necesidades de sus clientes, ya sea que eso incluya el aprendizaje automático o no. Todo aprendizaje automático que compilen los integradores de Privacy Sandbox obviamente será conocido por ellos y, por lo tanto, no se ocultará para ellos. |
| Verificación de datos | ¿Cómo pueden las empresas verificar que los datos que reciben cuando usan Privacy Sandbox son precisos y si Google está dispuesto a revisarse a través de una entidad como el Consejo de Clasificación de Medios (MRC)? | Las APIs de Privacy Sandbox se compilan dentro de la plataforma de código abierto que impulsa Chrome. Las partes de las APIs destinadas a ejecutarse en entornos de ejecución confiables también son de código abierto y se pueden auditar. Cualquier persona que desee inspeccionar el código, puede, incluido el MRC. |
| (También se informó en trimestres anteriores) 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 técnicos y habiliten las derivaciones necesarias a fin de resolver esos problemas. Además, Chrome espera compilar y escalar aún más un proceso para resolver problemas técnicos y derivaciones que afecten el estado del ecosistema. Chrome tiene el compromiso de garantizar recursos para este esfuerzo. 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. |
| Modos de prueba facilitados de Chrome | Obtén más información sobre los cronogramas y las implementaciones exactas para los modos de prueba facilitados por Chrome. | Compartimos una entrada de blog sobre los modos de prueba y estamos trabajando para compartir más información pronto. Estamos recibiendo sugerencias sobre el tamaño que deben tener las etiquetas del modo de prueba. |
| Integración con otros estándares de la industria | ¿Las APIs de Privacy Sandbox se conectarán a uno o a ambos MTC v2.* y el Modo de consentimiento? | No planeamos integrar las APIs de Privacy Sandbox directamente con el MTC v2 ni el modo de consentimiento. Sin embargo, las empresas y los grupos comerciales de la industria pueden adaptar sus productos y frameworks para trabajar en conjunto con las APIs de Privacy Sandbox. Por ejemplo, con frameworks como el MTC, cada participante debe determinar su propio enfoque de cumplimiento en función del indicador del MTC que recibe y las políticas del MTC asociadas. Esperamos que las empresas determinen cuándo y cómo usar diversas funcionalidades que ofrecen los componentes básicos de Privacy Sandbox. |
Inscripción y certificación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Restricción | El proceso de inscripción significa que Google puede decidir qué empresa del ecosistema puede usar las APIs de Privacy Sandbox. | El proceso de inscripción y certificación implica básicamente la verificación de la entidad (por ejemplo, la entidad tiene un número DUN, puede proporcionar un vínculo a una política de privacidad, etc.) y hace que la certificación pública sea un requisito para llamar a las APIs. Se validarán las entidades que puedan cumplir con los requisitos de inscripción de forma correcta. En el caso de las empresas que no tienen un DUN, proporcionamos un proceso acelerado y gratuito a Dun & Bradstreet para que adquiera uno. El objetivo es mejorar la protección de la privacidad de las APIs (según las medidas recién mencionadas) y también agregar una capa de transparencia a las APIs de Privacy Sandbox para que las partes interesadas puedan comprender mejor quiénes usan cada API y qué certificaciones realizan. Estamos dispuestos a recibir más comentarios de la industria sobre este problema, que ya se usaron para definir el proceso. |
| Sobrecarga de reinscripción | El archivo de certificación vence cada 12 meses y requiere que los sitios web se vuelvan a inscribir. | Recibimos comentarios del ecosistema y modificamos nuestro enfoque en consecuencia. Esto significa que los archivos ya no vencerán después de 12 meses o de cualquier período establecido. Actualizaremos nuestra guía de inscripción para desarrolladores con contexto adicional. |
| Archivo de certificación | ¿Cómo se usa el archivo de certificación? | Todas las empresas que llamen a las APIs de relevancia y medición deberán subir el archivo de certificación a su sitio y mantenerlo para que esté en vista pública durante el plazo de aplicación, siempre y cuando continúe llamando a las APIs. Los sitios web podrían esperar aproximadamente una solicitud por hora de Privacy Sandbox, y es posible que otras entidades potenciales también realicen consultas. Esto se llevará a cabo a través del propio mecanismo del sistema de inscripción para consultar los servidores de las entidades inscritas y garantizar que el archivo de certificación sea válido. Las certificaciones se incluirán en los Informes de transparencia y serán visibles para el público en general. Esperamos que las empresas actúen de acuerdo con las certificaciones establecidas, al igual que el resto del ecosistema y los organismos reguladores relevantes. |
| Inscripción | ¿La inscripción es por sitio o por origen? | La inscripción es a nivel del sitio. |
Mostrar anuncios y contenido relevantes
Temas
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Rendimiento | Inquietudes sobre el rendimiento en relación con el impacto de la tasa de participación de Topics en el Espacio Económico Europeo | Sugerimos a las partes interesadas en cuestión que se comuniquen con la agencia de protección de datos pertinente en relación con este problema. Están mejor posicionadas para abordar esas inquietudes y determinar si las aplicaciones de tecnologías que mejoran la privacidad se incentivan por leyes o, en su lugar, se tratan como el seguimiento, lo que requiere los mismos enfoques para obtener el consentimiento. Esto podría hacer que las APIs como las de Privacy Sandbox no estén disponibles con tanta frecuencia. |
| Inscripción | ¿Los ofertantes descendentes deben inscribirse en la API de Topics para usar indicadores de Topics de SSP ascendentes? | No es necesario inscribir los receptores descendentes de temas más allá del llamador inicial de la API de Topics, aunque es probable que muchos estén inscritos para otro uso de la API. Como parte de los esfuerzos de transparencia del programa, se proporcionará de manera programática una lista de los usuarios inscritos en Privacy Sandbox, lo que permitiría que un llamador interesado de la API de Topics verifique si está inscrito el destinatario al que está enviando un tema, si el emisor desea hacerlo. |
| Filtrado de temas | Solicita aplicar el filtro de otro llamador a los temas que recupera en la página para compartir solo lo que los compradores son aptos para recuperar. | Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema. |
| Exclusión de sitios | Excluye sitios web para que no contribuyan a los temas de un usuario. | No se llama a los temas de forma predeterminada. Es importante tener en cuenta que no se tiene en cuenta el contenido de la página cuando se seleccionan los temas, y que todos los temas se seleccionan para garantizar que no sean sensibles. Un sitio web también puede restringir su sitio para que no se incluya en el cálculo de temas a través del siguiente encabezado de la política de permisos: Permissions-Policy:
browsing-topics=() |
| Observación de temas | Permite que los editores otorguen permisos a Chrome para clasificar temas en función del contenido de la página (por ejemplo, encabezado o cuerpo). | Anteriormente, consideramos ofrecer funcionalidad para clasificar sitios en temas según su contenido y tomamos la decisión de no avanzar en función de inquietudes sobre la privacidad y la seguridad. Esta propuesta puede mitigar algunas de esas preocupaciones, pero no está claro en qué medida. Debido al próximo período del experimento de CMA, no se espera que este cambio ocurra antes del 3PCD. Recibiremos comentarios adicionales aquí. |
| Observación de temas | Proporciona políticas de permisos más detalladas a los publicadores. | Proporcionar políticas de permisos más detalladas para los publicadores permitiría que sus sitios tengan un impacto negativo en la utilidad de la API de Topics para todo el ecosistema, sin afectar negativamente la utilidad de la API de Topics para el sitio en sí. Para obtener un análisis más detallado del tema, consulta la Política de permisos de actualización a fin de admitir permisos separados para la recuperación y la observación en el problema de GitHub. |
| Temas de medicina y salud | ¿Por qué la taxonomía de Topics no abarca temas en las categorías de medicina o salud? | Las categorías de medicina y salud se consideran temas sensibles y, por lo tanto, se excluyen de la taxonomía de Topics. |
| Recuperación de temas | Es la forma más rápida de que las DSP obtengan Topics sin recuperar mediante encabezados. | Los métodos de encabezado son más eficaces y menos costosos que crear un iframe de origen cruzado y realizar una llamada a document.browsingTopics() desde él. (se debe usar un iframe de origen cruzado para la llamada, ya que el contexto de nivel superior para observar un tema debe coincidir con el contexto desde el que se accede a los temas). Esto se analizó en detalle aquí. |
| Recuperación de temas | Solicitudes para admitir el paso de temas a través de encabezados en solicitudes de etiqueta de secuencia de comandos de origen cruzado. | Desde una perspectiva de seguridad, esto no es posible. Cada documento y
su entorno de ejecución están asociados con un solo origen:
el del documento. Los subrecursos de terceros que se cargan y ejecutan en ese mismo entorno se consideran propiedad del origen del documento. Esto es para evitar la filtración de datos sin consentimiento de un origen a otro. Una alternativa es proporcionar un atributo browsingTopics en las etiquetas <script>. Esto debe limpiarse desde una perspectiva de seguridad y no debe agregar latencia adicional. Estamos dispuestos a recibir
comentarios de las partes interesadas. |
| Reconocimiento | Mejora el conocimiento público sobre la API de Topics y cómo se usará. | Nos comunicamos con la parte interesada que nos proporcionó estos comentarios y este problema se resolvió en GitHub.
En el futuro, seguiremos brindando asistencia para la comprensión del ecosistema de la API y esperamos conocer las opiniones de las partes interesadas. Mientras tanto, sugerimos a las partes interesadas que deseen saber más sobre la API de Topics que se familiaricen con la documentación de la Guía para desarrolladores de Chrome. |
| Notificación | Notificación para alertar al usuario cuando un sitio web está observando sus temas. | Abordamos estos comentarios en GitHub. Los usuarios pueden obtener más información sobre los controles de Topics en el Centro de ayuda de Chrome. |
| Aprendizaje automático | ¿Cómo se puede usar el AA para inferir los temas de los usuarios? | Estamos analizando este problema y te damos la bienvenida a los comentarios adicionales. |
| Utilidad para diferentes tipos de interesados | Es posible que las empresas de tecnología publicitaria más pequeñas no puedan observar Topics debido a la forma en que los navegadores los calculan. | Solo las tecnologías publicitarias que observaron al usuario visitar una página sobre el tema en cuestión durante las últimas tres semanas recibirán un tema. Si la tecnología publicitaria no llamó a la API en las tres semanas anteriores para ese usuario en un sitio sobre ese tema, el valor que se muestra estará vacío. Esta función implica que las tecnologías publicitarias cuyos servicios se utilizan por una mayor cantidad de propietarios de sitios y, por lo tanto, tienen más oportunidades de observar una visita al sitio de un usuario determinado pueden recibir más temas que otras tecnologías publicitarias. Esta función es esencial para la protección de la privacidad de la API, ya que limita la disponibilidad de la información sobre un usuario solo a aquellas partes que ya pueden observar la misma información subyacente (actualmente, a través de cookies de terceros). |
| Solicitud de XHR | ¿Cuándo quedará obsoleta la inclusión de Topics en las solicitudes XMLHttpRequest (XHR)? |
Como se anunció en agosto de 2023, Chrome comenzó a dar de baja la compatibilidad con XHR cuando pasó de la prueba de origen a la Disponibilidad general. A medida que avanzaba el aumento de Topics, la compatibilidad con XHR solo se incluía para los usuarios para los que estaban habilitadas las funciones de OT y dejó de estar disponible cuando se combinaron los grupos experimentales de OT individuales. Si usabas Topics con XHR, tus sitios no fallarán. Los temas simplemente no se agregarán a los encabezados de tu solicitud XHR. Te recomendamos que realices la transición a fetch para tu solicitud, uses el atributo de iframe o la API de JavaScript para recuperar temas. La recuperación es compatible con todos los navegadores modernos, pero no con Internet Explorer ni con Opera Mini. |
| 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 clasificadores, y cómo las empresas pueden prepararse para esas actualizaciones. | Nuestra respuesta no se modificó con respecto al segundo trimestre: Como se indicó en la entrada de blog reciente, esperamos que la taxonomía evolucione con el tiempo y que, más adelante, 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 grupotopics-announce. |
| Abuso | Posible ataque mediante la cadena de redireccionamiento. | Estamos considerando este problema y agradecemos tus comentarios adicionales. |
| Tipos de inventario del publicador | ¿Qué tipos de inventario de publicadores admitirán las pruebas de Protected Audience y Topics? | Ni Protected Audience ni Topics son inherentemente restrictivos en cuanto a los tipos de inventario en los que se pueden usar. |
| Tiempo de aumento | Se recomienda que no haya un período de adaptación para que las taxonomías nuevas lleguen al 100%. | A partir de esta solicitud de comentarios del ecosistema y del debate durante las reuniones de PATCG, anunciamos nuestro plan para el lanzamiento de la nueva taxonomía. |
API de Protected Audience (anteriormente, FLEDGE)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Subastas de nivel superior | La capacidad de usar el servidor de anuncios del publicador de Google sin también otorgarle a Google Ad Manager el control de la subasta de la API de Protected Audience de nivel superior | Respuesta proporcionada por Google Ad Manager: Los planes de Google Ad Manager para la API de Protected Audience no incluyen compatibilidad con el servidor de anuncios del publicador de Google sin el control de la subasta de Protected Audience de nivel superior, por los siguientes motivos. Para mostrar adecuadamente a nuestros clientes en el mercado de publicación de anuncios del publicador, el servidor de anuncios del publicador de Google debe retener el control de la subasta de Protected Audience de nivel superior. Como servidor de anuncios del publicador, nuestra función es proporcionar previsiones a los publicadores para que puedan negociar las campañas de venta directa sin sobrevender y entregar el ritmo y entregar sus reservas directas de manera óptima. Para ello, es necesario ejecutar la subasta final a fin de comparar toda la demanda apta directa e indirecta. La previsión y el ritmo son funciones principales que los publicadores esperan de un servidor de anuncios. Sin una previsión precisa, los publicadores pueden terminar sobreventa de su inventario, lo que pone en riesgo la reputación de su empresa. El ritmo también es fundamental, ya que no poder cumplir con los contratos de reservación con los anunciantes también corre el riesgo de dañar la relación directa entre el publicador y el anunciante, lo que podría generar un impacto significativo en el negocio de un publicador. En resumen, por lo tanto, no consideramos que la actividad de un servidor de anuncios del publicador de ejecutar la subasta de Protected Audience de nivel superior sea distinta de las demás actividades del servidor de anuncios del publicador. |
directFrom |
directFrompermite que Google Ad Manager evite que el publicador vea el precio de su subasta contextual. |
Respuesta de Chrome: No se sabe que la información que se pasa a runAdAuction() provenga del vendedor, a menos que este llame a runAdAuction() desde su propio iframe. En una subasta de varios vendedores, es imposible que todos los vendedores creen el fotograma que llama a runAdAuction(). directFromSellerSignals resolvió este problema cargando contenido desde un paquete de subrecursos cargado desde el origen de un vendedor. Esto garantiza que la autenticidad y la integridad de la información que se pasa a una subasta desde la configuración de las subastas del vendedor no se puedan manipular. Si los publicadores quieren usar la API de Protected Audience para comprender la información que sus proveedores de tecnología pasan a las subastas de Protected Audience, pueden pedirles esta funcionalidad.Respuesta proporcionada por Google Ad Manager: Durante años, mantuvimos un firme enfoque en la equidad de las subastas, lo que incluye nuestra promesa de que ningún precio de ninguna de las fuentes de publicidad no garantizadas de un publicador, incluidos los precios de líneas de pedido no garantizados, se compartirá con otro comprador antes de que oferte en la subasta, que luego reafirmamos en nuestros compromisos con la Autoridad de la Competencia de Francia. Para las subastas de Protected Audience, queremos mantener nuestra promesa al aprovechar directFromSellerSignals y no compartir la oferta de ningún participante con ningún otro participante antes de que se complete en las subastas de varios vendedores. Para ser claros, no compartiremos el precio de la subasta contextual con nuestra propia subasta de componentes, como se explica en la actualización Aclara más a fondo la dinámica de la subasta de nivel superior. |
| Exposición a la información | Es posible que el navegador exponga la lógica empresarial sensible y los detalles contractuales. | La persona que usa un navegador web puede ver todo lo que sucede en él. Cuando una subasta de anuncios se lleva a cabo dentro del navegador, es cierto que la persona cuyo navegador pueda mirarla y ver qué tan distintas partes deciden ofertar. Dado que un navegador es el agente del usuario, no creemos que sea posible ni deseable intentar cambiar esto. Sin embargo, solo la persona que usa el navegador puede ver estas operaciones. Una ejecución de subasta integrada en el dispositivo con la API de Protected Audience no se puede observar en ningún servidor, incluido el de Google. |
PerBuyerExperiment |
El rango de valores actual dePerBuyerExperimentpodría permitir que los compradores correlacionen los datos contextuales con la solicitud del servidor de confianza. |
El uso de la API de Protected Audience de esta manera no es coherente con la certificación obligatoria de Privacy Sandbox que indica que los usuarios de la API no intentarán eludir las protecciones de Privacy Sandbox. En el futuro, el requisito de que los servidores de pares clave-valor se ejecuten en entornos de ejecución confiables (TEE) proporcionará protección técnica contra este ataque. |
| Política del mismo origen | Flexibiliza la política del mismo origen para permitir subdominios. | Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema. |
| Control de versiones de las APIs | Solicitud de control de versiones y notas de la versión para cambios en la API de Protected Audience. | Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema. |
| Subastas de múltiples SSP | Permite que los indicadores de subasta de nivel superior realicen combinaciones de JSON con el indicador de componente auctionSignals. |
Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema. |
| Límite de oferta | Aumenta el límite en la cantidad de componentes del anuncio que ingresan en la oferta de 20 a 40. | Estamos considerando esta solicitud y recibimos comentarios adicionales del ecosistema sobre por qué sería útil. |
| (También se informó en trimestres anteriores) Rendimiento de las subastas de Protected Audience |
Informa de los verificadores que las subastas de Protected Audience tienen una latencia alta. | En lo que respecta a la latencia, la API de Protected Audience generalmente siguió el paradigma estándar existente de controles de compilación que permiten a los vendedores decidir cuánto tiempo y recursos pueden consumir los ofertantes, y herramientas que permiten a los compradores decidir cómo usar mejor los recursos disponibles para ellos. Estos controles y herramientas están disponibles en la actualidad, pero su beneficio completo solo se podrá aprovechar después de la adopción por parte de los compradores y vendedores. Además, Chrome sigue trabajando en varias mejoras de infraestructura relacionadas con la velocidad de la subasta (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Invitamos a que nos envíes comentarios sobre ambas partes de este esfuerzo de latencia: nuevas herramientas útiles para los compradores y vendedores, e informes sobre cuellos de botella observados que los ingenieros de Chrome deberían investigar. |
| Filtrado orientado a la compra | Se agregó compatibilidad con el filtrado de compras basado en grupos de intereses. | Sugerimos varias formas en que las SSP y las DSP podrían cambiar sus diseños para manejar esto:
|
| Control de grupos de interés del editor | Asistencia para publicadores que buscan delegar el uso de grupos de intereses creados por el publicador. | Hemos mantenido conversaciones con muchas partes sobre la solicitud. Creemos que todos los casos de uso involucrados en la "delegación" de los grupos de interés creados por el publicador se pueden incluir ahora y, además, debemos crear asistencia adicional para que algunos casos de uso fluyan mejor en el futuro. |
| (También se informa en el segundo trimestre) Entornos de ejecución confiables | Compatibilidad con entornos de ejecución confiables (TEE) en entornos de nube no pública | Nuestra respuesta es similar a la de los trimestres anteriores: Si bien seguimos explorando la compatibilidad con opciones más allá de las soluciones públicas basadas en la nube, actualmente no tenemos planes de admitir TEE locales. En esta etapa, debido a 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 (por ejemplo, admitir Google Cloud y AWS) es lo más beneficioso para el ecosistema. Sin embargo, aceptamos comentarios adicionales sobre por qué ese requisito es necesario y factible dadas las restricciones de privacidad y seguridad. |
| Un entorno de ejecución confiable | Los componentes en la ruta de entrega de TEE, como el balanceador de cargas, pueden observar todo el tráfico y tener información de la dirección IP de cada solicitud. | Actualmente, la dirección IP se pasa como metadatos en los encabezados de la solicitud al servicio de anuncios del vendedor no confiable en el caso de las subastas de licitación y subasta, y en las subastas de Protected Audience integradas en el dispositivo. Consulta Reenvío de metadatos para obtener más información. A largo plazo, planeamos usar un proxy de tecnología publicitaria y rastrear el tráfico a través de un proxy de IP, lo que evitará que los componentes observen todo el tráfico en la ruta de entrega. |
| Tiempo de actividad (TTL) | ¿Se establecerá el tiempo de actividad (TTL) antes de que los servicios deban solicitar claves nuevas o se pretende ser flexible (o dinámico)? | Por lo general, el TTL es estático. Actualmente, el TTL para el público es de 8 días, y la rotación ocurre cada 7 días. En el caso del servicio de agregación, también es el mismo para las claves privadas. En el caso de los servicios de ofertas y subastas, las claves privadas y públicas se recuperan cada N horas en la ruta de acceso no solicitada y se almacenan en caché en la memoria, de modo que no haya más de un retraso de N horas entre las claves que rotan y los servidores que recogen estas claves. El búfer de 1 día entre la rotación y el vencimiento de claves sirve para garantizar que los servicios puedan seguir funcionando, incluso si falla la generación de claves. Consideramos extender el TTL para que sea más resistente a las interrupciones. En caso de una filtración de claves, planeamos forzar manualmente su generación y, además, invalidarlas más rápido. Ten en cuenta que las claves públicas se almacenan en caché en los clientes, actualmente durante 24 horas, de nuevo para garantizar que, en caso de que se produzca una interrupción del coordinador, los servicios puedan seguir funcionando. |
| Determinación por tráfico | Compatibilidad con la determinación de tráfico para los servicios de ofertas y subastas. | Los compradores pueden indicar, en función de los datos de origen o los datos contextuales del publicador, la demanda para las subastas de Protected Audience. Los vendedores también pueden realizar determinaciones similares en el servidor de anuncios o en el servidor de Ad Exchange del vendedor. Los modelos se pueden entrenar con datos de origen y con cualquier informe agregado de las subastas de Protected Audience. Los vendedores pueden usar esta información para evitar enviar solicitudes a servidores de ofertas y subastas cuando no hay demanda de subastas de Protected Audience. Creemos que puede ser una manera eficaz de definir el tráfico. |
| Subasta de componentes | ¿Qué indicadores de subasta de nivel superior se comparten con los vendedores de componentes? | Los compradores de una subasta de componentes solo reciben indicadores del vendedor de componentes. Queremos compartir pronto documentación sobre la secuencia general de una subasta combinada con la oferta de encabezado y la subasta de Protected Audience. |
| Renderización de video | Compatibilidad con la renderización de videos mediante Protected Audience y Fenced Frames. | La API de Protected Audience admite la renderización de videos mediante un mecanismo que se basa en iframes. Sin embargo, aún no diseñamos una solución que sea compatible con marcos cercados, y esta es una de las razones por las que decidimos rechazar la aplicación de esta estructura a 2026. Eso significa que, si un socio decide aplicar de manera forzosa Fotogramas cercados, el socio no tendrá compatibilidad con los videos. |
| Limitación de frecuencia | (También se informó en trimestres anteriores) Controles de frecuencia por usuario dentro de una campaña y un grupo de anuncios. |
Nuestra respuesta no cambió con respecto a los informes anteriores: Protected Audience admitirá la limitación de frecuencia en las subastas integradas en el dispositivo y en las campañas contextuales y de desarrollo de la marca. Las limitaciones de almacenamiento compartido y específicas del sitio también se pueden usar para controles de limitación de frecuencia adicionales. |
| Preferencias de anuncios | ¿Protected Audience proporciona una manera de inhabilitar los sitios de anunciantes o de incluirlos en la lista de entidades bloqueadas, o bien una forma de abandonar todos los grupos de intereses del mismo propietario? | Existen varias formas para que los usuarios bloqueen el acceso a la API de Protected Audience y otras funciones de Privacy Sandbox. |
| Política del mismo origen para la URL de origen de las secuencias de comandos de ofertas y subastas | Flexibiliza el requisito de que todos los campos que especifican URLs para cargar secuencias de comandos o JSON deben tener el mismo origen que el propietario. | Estamos considerando esta solicitud y deseamos compartir comentarios adicionales del ecosistema. |
forDebuggingOnly |
Posibilidad de que forDebuggingOnly se use de forma inadecuada si permanece después de la 3PCD. |
En los últimos años, hemos recibido comentarios del ecosistema sobre las brechas de funcionalidad de Protected Audience una vez que las cookies de terceros dejen de estar disponibles, y estamos trabajando para formular un plan que las admita después de 3PCD sin comprometer los objetivos de Privacy Sandbox. Agradecemos cualquier sugerencia o comentario adicional sobre funciones faltantes que el ecosistema desee ver. |
| Varios grupos de interés | Utilice varios grupos de interés en la misma oferta. | En la actualidad, esto no es compatible con la API de Protected Audience, ya que generaría un cambio en el modelo de privacidad subyacente. Se aceptan debates adicionales aquí. |
| Subastas integradas en el dispositivo | ¿Chrome en Android admitirá las subastas de Protected Audience integradas en el dispositivo? | Sí, las subastas integradas en el dispositivo estarán disponibles en Chrome para Android. |
| (Se informó en el 2o trimestre de 2023) Datos relacionados con los clics | Se agregaron datos relacionados con los clics a trafficSignals. | Continuamos evaluando esta solicitud de función y recibimos comentarios adicionales sobre los motivos por los que se debe priorizar. |
| Proveedores de entornos de ejecución confiables | ¿Existen diferencias significativas en las ofertas de entorno de ejecución confiable de diferentes proveedores de servicios en la nube? | No conocemos las diferencias importantes, pero recomendamos que el ecosistema revise las guías de implementación públicas para ver qué solución se adapta mejor a sus necesidades. Google Cloud. AWS. |
| (Se informó en trimestres anteriores) Compatibilidad con la segmentación negativa por grupos de interés |
Una API para admitir la segmentación negativa por grupos de interés: muestra anuncios solo si un usuario no pertenece a un grupo de interés. | Estamos considerando implementar esta función y estamos analizando la solicitud. |
| Infracción de contenido | Se admiten funciones que permiten a los usuarios informar sobre anuncios que infringen las políticas que publica la API de Protected Audience en marcos protegidos. | Creemos que el mecanismo existente de informes de anuncios de marcos ofrece buenas opciones para las tecnologías publicitarias que desean un flujo de informes de "Anuncios malos" generado por el usuario. Esto permitiría que se generen informes sobre los anuncios incorrectos de una manera esencialmente inalterada respecto del estándar de la industria actual. Si quedan brechas, aceptamos solicitudes de funciones adicionales, incluso durante el tiempo posterior a la eliminación de las cookies de terceros, pero antes de que se generalice la renderización de marcos protegidos. |
| Informes de la API de Private Aggregation | ¿Cómo podemos calcular el tiempo que el usuario pasó en ese grupo de interés? | En Chrome M116 y versiones posteriores, deberías poder usar las visitas recientes según se define en pull/639. |
| Servidor de K-Anonymity | Más información sobre el servidor de K-Anonymity. | Compartimos más información sobre los servidores de K-Anonymity aquí y agradecemos tus comentarios. |
| URLs de creatividades dinámicas | Se admiten URLs de creatividades sin declaración previa sin dejar de respetar el k-anonimato. | Estamos analizando la solicitud de esta función y recibimos comentarios adicionales sobre los motivos por los que se debe priorizar. |
| Requisito de k‐anonimato | ¿Se volverá a implementar el requisito de k-anonimato en las actualizaciones del Grupo de interés? | No tenemos previsto cambiar la posición indicada en esta publicación de GitHub. Como anunciamos en esa publicación, decidimos quitar el requisito de k-anonimato en las actualizaciones del grupo de interés de Protected Audience, lo que no tiene un impacto significativo en las protecciones de privacidad generales de la API, y planeamos considerar otras protecciones potenciales más directas (como la privacidad de la dirección IP o un servidor de actualización confiable) en una fecha posterior cuando las tecnologías relacionadas se desarrollen, implementen e implementen. |
| Prueba beta de los servicios de ofertas y subastas | ¿Cuándo comenzará la prueba beta de los servicios de ofertas y subastas? | Como se indica en Cronograma y hoja de ruta, la primera fase de las pruebas de los servicios de licitación y subasta comienza en noviembre de 2023. |
| Simultaneidad | Solicitud para admitir la coordinación de creatividades para redes de publicidad (SSP y DSP se encuentran en la misma empresa o propiedades) | Agradecemos los comentarios sobre este caso de uso y queremos saber si a más tecnologías publicitarias les interesa que esto sea compatible. Recibiremos comentarios adicionales. |
| Publicidad nativa | Compatibilidad con Fenced Frame para la publicidad nativa | Estamos considerando admitir el caso de uso y estamos analizando posibles soluciones y soluciones. |
| K‐anonimato | ¿Cómo puedo maximizar los anuncios basados en un grupo de interés que alcanzan los umbrales de k-anon? | Compartimos algunas orientación táctica sobre este tema. |
| Compatibilidad con POST | Compatibilidad con el envío de datos de subastas mediante solicitudes POST. | Estamos evaluando esta solicitud de función y aceptamos envíos adicionales de problemas de GitHub para explicar por qué debería priorizarse. |
| Nivel de detalle de los informes | ¿Cuál es el nivel de detalle de los informes de anuncios de marco cercado con anuncios compuestos por varias piezas? | El diseño actual no permite capturar el ID o la posición del producto, ya que esto puede comprometer la privacidad del usuario. Solo se puede invocar el reserved.top_navigation, que se enviaría cuando hay una activación del usuario (como un clic) en el marco vallado del componente del anuncio, lo que da como resultado una navegación de nivel superior. |
| Subasta de anuncios | ¿Puede una SSP que participa en una subasta de componentes activar otra subasta de componentes? | Un componentSeller no puede incluir también componentAuctions.La subasta de varios vendedores solo tiene dos niveles: 1. Las subastas de componentes en paralelo. 2. La subasta de nivel superior (donde compite el anuncio ganador de cada componentAuction). |
| Disponibilidad de los servicios de ofertas y subastas | ¿Las ofertas y subastas estarán disponibles durante la fase de prueba facilitada de Chrome? | El servidor de ofertas y subastas no estará disponible durante la fase de prueba facilitada de Chrome. |
| Indicadores de ofertas | Permite que los navegadores soliciten y borren indicadores de ofertas. | Estamos analizando esta solicitud y recibiremos comentarios adicionales sobre los motivos por los que debería priorizarse. |
generateBid() |
La capacidad de actualizar userBiddingSignals de interestGroup a través de updateURL |
Estamos considerando esta propuesta y recibiremos comentarios adicionales y comentarios. |
| Tipos de inventario del publicador | ¿Qué tipos de inventario de publicadores serán compatibles con las pruebas de Protected Audience y TOPICS? | Ni Protected Audience ni Topics son inherentemente restrictivos en cuanto a los tipos de inventario en los que se pueden usar. |
| Integración de servidor a servidor | ¿Se requiere la integración directa entre la SSP y la DSP para Protected Audience? | No se requiere la integración directa entre la SSP y la DSP si la DSP no necesita procesar señales contextuales en su propio servidor para pasar esa información procesada a su función de ofertas en el dispositivo. |
Un campo bid_currency en B&A |
Compatibilidad con el campo bid_currency en el servicio de ofertas y subastas |
B&A aún no admite bid_currency, aunque planeamos admitirlo a fines de enero de 2024. Consulta el cronograma aquí. |
perBuyerSignals |
¿Hay un límite de tamaño para perBuyerSignals? |
No hay límite para la cantidad de indicadores por comprador, pero enviar demasiados datos puede tener efectos perjudiciales en el rendimiento del navegador. |
| Casos de uso entre sitios | ¿Podemos usar grupos de intereses de la API de Protected Audience en varios sitios web? | Protected Audience no está diseñado para esos casos de uso, como se explica en turtledove/issues/282. |
| Solicitudes HTTP de grupo de interés | Incluye el BLOB de grupo de interés en los encabezados HTTP. | Consideramos esta solicitud y le damos la bienvenida a los demás comentarios sobre ella. |
| Control de calidad de los anuncios | Es la pérdida del control de calidad de los anuncios relacionado con la información de varios sitios. | Tenemos en cuenta estos comentarios y te damos la bienvenida a los comentarios adicionales. |
| Herramientas para desarrolladores de Chrome | Las solicitudes de red salientes de Protected Audience deben ser visibles en la pestaña Red de las Herramientas para desarrolladores de Chrome. | Estamos trabajando para habilitar esta función en la pestaña Red y te damos la bienvenida a los comentarios adicionales sobre los motivos por los que se debería priorizar. |
| Un entorno de ejecución confiable | ¿Cuándo se agregarán a la explicación de la supervisión del entorno de ejecución confiable los detalles de las métricas que afectan la privacidad (y su grado)? | Estamos en proceso de actualizar la explicación con esta información. La explicación actualizada estará disponible en noviembre de 2023. |
directFrom |
¿Por qué directFrom no se empaqueta como un paquete web? |
Compartimos los motivos de esta decisión aquí. |
| Delegación de impresiones | ¿Hay alguna manera viable de realizar la delegación de impresiones en la que el resultado de un grupo de interés seleccionado sea otra acción de segmentación? | Varias subastas anidadas no son compatibles con nuestros objetivos de privacidad por dos motivos. En primer lugar, cuando el ganador de una subasta se renderiza dentro de un marco vallado, nuestros objetivos de privacidad para Protected Audience incluyen la renderización de la creatividad resultante sin conocer el contexto: la URL de la página que lo rodea o la cookie propia constituyen una infracción de la privacidad. En ese entorno, no es viable realizar una subasta anidada. En segundo lugar, el modelo de Protected Audience indica que el ganador de cada subasta debe basarse en los datos de solo un sitio adicional. Las subastas anidadas serían una forma de combinar eso, lo que daría como resultado la posibilidad de elegir anuncios basados en un perfil de varios sitios. |
| Criterio de datos en reposo | Explica con más detalle el criterio de datos en reposo en el modelo de confianza del servicio de par clave-valor. | Los datos en el servicio de par clave-valor se cargan en la memoria y se entregan desde allí en lugar de almacenarse en caché de lectura. |
| Indicador de datos del comprador | ¿Existe un límite de tamaño definido para los indicadores buyer_data recibidos de las DSP? |
Actualmente, el navegador no impone límites para los indicadores buyer_data recibidos de las DSP. |
Mide los anuncios digitales
Attribution Reporting (y otras APIs)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Dispositivos múltiples | Planifica la compatibilidad multidispositivo de la API de Attribution Reporting. | La función multidispositivo presenta nuevos desafíos de privacidad además de las 3PC y también agrega desafíos de distribución de tecnología debido a la variedad de dispositivos y plataformas que un usuario podría usar. Estamos explorando posibles soluciones, pero nos enfocamos en los casos de uso fundamentales que actualmente admite Attribution Reporting y no tenemos planes de agregar compatibilidad con varios dispositivos antes de quitar las cookies de terceros. |
| (También se informó en trimestres anteriores) Tamaño de los datos del activador |
¿Por qué el tamaño de los datos del activador está limitado a 3 bits? | El tamaño está limitado a 3 bits y 8 valores distintos para garantizar que la cantidad de información entre sitios y varios contextos sobre un usuario sea limitada. Les damos la bienvenida a los jugadores del ecosistema a enviar comentarios para confirmar si la configuración actual de los informes a nivel del evento es suficiente. |
| Embudo de conversión | Informa sobre varios dominios que se usaron en la conversión. | Este caso de uso es posible debido a que se agregaron varios destinos. Recibiremos comentarios adicionales. |
| Mismo dominio en compatibilidad de país diferente | ¿Los Informes de atribución funcionan con sitios web que tienen el mismo dominio, pero varios TLD de países? | Este problema se debatió y resolvió con el interesado que planteó la pregunta. Si una plataforma de tecnología publicitaria necesita usar varios TLD de país, deberá tener varias inscripciones, una para cada TLD de país. |
| Público protegido y Attribution Reporting | ¿Las tecnologías publicitarias pueden acceder a las conversiones posimpresión para las subastas de Protected Audience y a las conversiones posclic para Attribution Reporting? | Sí, Privacy Sandbox debe admitir VTC y CTC en Protected Audience. |
| Demoras en los informes agregables | Reduce aún más las demoras en los informes agregables. | Recibimos comentarios recientes sobre este tema y compartimos ideas aquí. Agradecemos los comentarios adicionales del ecosistema. |
| Demoras en los informes agregables | Reducir los retrasos mediante la incorporación de la mediación del servidor | Estamos considerando esta propuesta y le damos la bienvenida a los comentarios adicionales . |
| Demoras en los informes a nivel del evento | Reduce las demoras en los informes a nivel de evento. | La propuesta flexible completa a nivel de evento, que se describe en Configuraciones flexibles a nivel de evento, puede reducir las demoras en los informes a nivel de evento hasta 1 hora con compensación de ruido. |
| Origen del informe de fuente por fuente | La limitación de la cantidad máxima de orígenes de informes de fuentes por sitio de informes de origen evita que las plataformas de tecnología publicitaria registren fuentes de diferentes orígenes de informes para un solo origen de publicador. | Esto se analizó con la parte interesada que planteó el problema, y se está probando una posible solución de usar 1 origen de informes por sitio que informa la fuente antes de probar otras posibles soluciones que incluyan redireccionamientos. También estamos dispuestos a recibir comentarios adicionales sobre el ecosistema en relación con este límite. |
| Informe de problemas | ¿Cómo podemos informar errores o problemas con la API de Attribution Reporting en Chrome? | Actualmente, recomendamos que las tecnologías publicitarias informen cualquier error de la API de Attribution Reporting que puedan encontrar como un problema en GitHub. Si tiene un problema relacionado con Chrome, te recomendamos que crees un error de Chromium. Para encontrar vínculos sobre cómo y dónde marcar cualquier problema, consulta Interactúa y envía comentarios. |
| Anulación de duplicación | ¿Cómo podemos anular las conversiones duplicadas en diferentes canalizaciones y dispositivos? | La anulación de duplicación entre dispositivos y canalizaciones de medición es un desafío conocido y actual que las tecnologías publicitarias también enfrentan en la actualidad con las 3PC. Con la API de Attribution Reporting, las tecnologías publicitarias pueden decidir cuándo registrar conversiones específicas y agregar metadatos específicos para indicar qué canalizaciones de medición usaron para realizar un seguimiento de las conversiones (en otras palabras, parte de la clave de agregación), que se pueden comparar con otras canalizaciones de medición. Nos gustaría recibir comentarios adicionales sobre el ecosistema. |
| Anulación de duplicación y prioridad | Solicita tener prioridad primero antes de la anulación de duplicación. | Consideramos esta solicitud y le damos la bienvenida a los comentarios adicionales. |
| Antifraude | Riesgo de que un usuario malicioso manipule los datos a nivel del evento | La verificación de informes no funciona para los informes a nivel del evento por los motivos descritos en ¿Por qué esta opción no admite informes a nivel del evento? |
| Tipo de conversión | ¿Cómo podemos diferenciar entre la vista completa y la navegación en los Informes de atribución? | Tenemos la siguiente opción de filtrado integrada: source_type.
Aquí encontrarás más detalles. |
Servicio de agregación
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Recuperación de presupuestos | Algunas tecnologías publicitarias solicitaron la capacidad de volver a procesar informes en casos en los que haya fallas, errores o eliminaciones de sus informes. | El equipo está explorando formas de abordar esto de una manera que preserve la privacidad. |
| Inscripción en el sitio | Varias tecnologías publicitarias solicitaron asistencia para procesar varios orígenes en la misma cuenta para casos de uso como la división de datos por ubicación geográfica o anunciante. Las tecnologías publicitarias también esperan este comportamiento, ya que la inscripción en la API del cliente ahora se basa en el sitio (y no en el origen). La migración de la inscripción de origen a la del sitio optimiza el proceso de integración de AdTech mediante la coherencia con el proceso de inscripción de clientes. | Pronto lanzaremos la migración de la inscripción de origen a la inscripción del sitio para el servicio de agregación. Agradecemos los comentarios del ecosistema. |
| Plan de lanzamiento y baja | Programa de lanzamientos y depreciación de las funciones y los parches publicados del servicio de agregación. El objetivo del plan es brindarles a las plataformas de tecnología publicitaria visibilidad sobre nuestras políticas de lanzamiento a fin de que puedan prepararse para las próximas versiones y bajas, y garantizar que ejecuten versiones estables y seguras de los servicios. | Recientemente, publicamos una propuesta para el plan de lanzamiento y baja del servicio de agregación y recibimos comentarios adicionales. |
| Coordinadores | ¿Qué sucede si los coordinadores dejan de ser parte del servicio de agregación? | Ambos coordinadores deben estar completamente disponibles para que el sistema funcione de forma correcta. La falta de disponibilidad breve se soluciona con reintentos en nuestras bibliotecas cliente. Si no se encuentra disponibilidad de alguno de los dos coordinadores, los trabajos de agregación fallarán. Los trabajos se pueden volver a ejecutar si aún no se consume el presupuesto para privacidad. En el caso de que una falla del servicio genere un consumo de presupuesto sin un informe de resumen escrito en el almacenamiento de tecnología publicitaria, actualmente recomendamos que usen informes de depuración para recuperar los resultados con la herramienta de prueba local. También estamos trabajando en funciones que permitan la recuperación del presupuesto en caso de fallas para que las tecnologías publicitarias puedan volver a ejecutar sus trabajos. |
API de Private Aggregation
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| URL del BLOB | Solicitud para admitir la URL del BLOB en el almacenamiento compartido. | Se agregó compatibilidad con la URL del BLOB en Chrome M116. |
Limita el seguimiento encubierto
Reducción del usuario-agente y User-Agent Client Hints
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| API de JavaScript | Disponibilidad de la API de JavaScript User-Agent Client Hints | No hay planes de quitar esta funcionalidad, ya que es nuestra solución principal para los socios que deseen acceder de forma activa a los datos de alta entropía más allá de los que están disponibles de forma predeterminada en la UA congelada y reducida. |
| Información sobre el dispositivo y el factor de forma | Es la capacidad para que los sitios web comprendan las entradas, salidas y otra información que el dispositivo que visita el sitio web puede admitir. | Agregamos asistencia para esta solicitud a partir de los comentarios del ecosistema. |
Protección de IP (anteriormente conocido como Gnatcatcher)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Tráfico de terceros apto | ¿A qué se refiere el “tráfico de terceros apto” en la explicación? | Comprendemos la importancia de esta pregunta y estamos trabajando activamente para identificar qué tráfico de terceros será apto y cuál no. Agradecemos los comentarios sobre este tema. |
| Auditorías de tráfico de red | Asistencia para que las empresas realicen auditorías de tráfico de red en sus redes. | Solo se verá afectado el tráfico de terceros incorporado en sitios propios, lo que debería limitar la cantidad de tráfico que se debe filtrar. Además, planeamos ofrecer a los usuarios la opción de usar o no la protección de IP y, en el caso de Chrome controlado por empresas, habrá políticas empresariales para inhabilitar la protección de IP. Por último, exploraremos qué controles (si corresponde) se proporcionarán a los operadores de red para inhabilitar la protección de IP. Agradecemos los comentarios sobre este tema. |
| Control de acceso | La protección de IP puede afectar a los servicios web que usan direcciones IP para el control de acceso. | Comprendemos la importancia de los casos de uso contra el fraude y su posible impacto en ellos. Estamos buscando comentarios sobre el ecosistema sobre cómo podemos brindar una mejor asistencia a los casos de uso contra fraudes que, por lo general, se basaban en direcciones IP. |
| Comunicación entre los proxies de 2 saltos | Cómo garantizar que no haya información entre los proxies | Estamos en el proceso de diseñar las interacciones de los proxies. Nuestro objetivo es minimizar las posibilidades de que esa información se comparta a través de medios comerciales, de procesos y técnicos. |
| Autenticación que no es de Google | Compatibilidad con autenticaciones ajenas a Google | Planeamos publicar más detalles sobre la autenticación de cuentas en el futuro, aunque compartimos algunas consideraciones iniciales. |
| Clasificación de rastreadores | ¿Cómo determinará la protección de IP qué constituye un rastreador y sus variantes? | Comprendemos la importancia de esta pregunta y estamos trabajando activamente para identificar qué tráfico de terceros será apto y cuál no. Agradecemos los comentarios sobre este tema. |
| Estadísticas | La protección de IP puede afectar la precisión de los servicios de estadísticas. | Queremos comprender mejor el impacto de la protección de IP y recibir comentarios y ejemplos adicionales del ecosistema. |
| Proxy | Si un usuario usa un proxy o lo definió de forma manual, ¿cómo funcionará la máscara de IP en este caso? | Queremos comprender el impacto que la protección de IP puede tener en otros proxies. Por el momento, no tenemos planes para compartir. Agradecemos los comentarios sobre este tema. |
| Oferta de Premium | ¿La protección de IP será una función pagada? | La protección de IP estará disponible para los usuarios de Chrome como parte de la experiencia principal del navegador. No será una función pagada. |
| Servidor proxy | ¿Se usarán los mismos servidores proxy durante las sesiones de usuario? | Una conexión HTTP/S usará un solo par de proxies y presentará una sola dirección IP enmascarada al origen. Más allá de eso, no hay restricciones estrictas para diferentes conexiones HTTP/S que tengan que usar los mismos servidores. |
| Plataformas compatibles | ¿En qué plataforma se admitirá la protección de IP? | La protección de IP estará disponible inicialmente en Chrome para Android y computadoras de escritorio. Seguimos evaluando cómo expandir la protección a otras plataformas. |
| Inhabilitar | ¿Los usuarios podrán inhabilitar la protección de IP? | Planeamos ofrecerles a los usuarios la opción de usar la protección de IP o no. |
| Anonimización | ¿Qué tipos de solicitudes se anonimizarán con la protección de IP? | Las solicitudes HTTP/S y DNS a dominios de terceros aptos se anonimizan a través de los proxies de privacidad. Proporcionaremos detalles adicionales en una próxima explicación sobre cómo determinaremos qué dominios se incluirán. El resto del tráfico (por ejemplo, el resto de las solicitudes de DNS o cualquier otro tráfico HTTP/S) no se ve afectado. |
| Visibilidad de datos | Se puede acceder a las direcciones de red durante el primer salto en la protección de IP. | En el modelo de proxy de dos saltos, el primer salto (controlado por Google) solo ve la IP del cliente de origen y una solicitud para conectarse al segundo salto, mientras que el segundo salto (controlado por una CDN externa) solo ve una tupla en el primer salto (IP + puerto del proxy) y la IP de destino. Para la respuesta desde el origen, el segundo salto puede reenviar la respuesta al primer proxy y puerto de salto asociado con la solicitud y no necesita aprender nada sobre la IP de cliente original (y el primer salto solo muestra la respuesta al cliente, sin aprender nada sobre la IP de destino). De esta manera, el primer salto solo aprende la IP de cliente y el segundo salto, mientras que el segundo salto solo aprende la IP de destino. |
| WebView | ¿La protección de IP estará disponible para WebView de Android en el futuro? | Por el momento, no tenemos planes de compartir, pero nuestra visión es proporcionar esta protección de la manera más amplia posible. |
Mitigación del seguimiento por rebote
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Seguimiento de interacciones | ¿Cómo se realiza el seguimiento de las interacciones de los usuarios? | Las mitigaciones de seguimiento por rebote hacen un seguimiento de dos tipos de interacciones del usuario:
Estas interacciones se asocian con el sitio de nivel superior en las páginas en las que se producen. Por ejemplo, si un usuario hace clic en un iframe incorporado, la interacción se asocia con el sitio de nivel superior y no con el sitio incorporado. Las interacciones se almacenan en una base de datos que contiene el etld+1 sin esquema y la hora de la interacción. Las interacciones protegen el dominio asociado de la eliminación del estado de mitigación del seguimiento por rebote durante 45 días. |
| Exenciones incluidas en la lista de entidades permitidas | ¿Se pueden excluir los dominios? | Consideramos esta solicitud y agradecemos los comentarios adicionales del ecosistema. |
Presupuesto de privacidad
No se recibieron comentarios este trimestre.
Fortalecer los límites de privacidad entre sitios
Conjuntos de sitios web relacionados (anteriormente, conjuntos propios)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Enfoque centralizado | Inquietud sobre el enfoque de repositorio centralizado para administrar conjuntos de sitios web relacionados. | Un repositorio público y de fácil acceso es clave para el diseño de RWS, ya que proporciona la responsabilidad de los envíos. En última instancia, la funcionalidad de cookies de terceros se proporciona mediante el uso de la API de Storage Access o la API de rSAFor, con la membresía de RWS que proporciona acceso otorgado automáticamente (a diferencia de lo que sucede a través de mensajes con la API de Storage Access). Creemos que un enfoque como el proceso de envío de RWS es un requisito adecuado para el acceso automático a cookies de terceros. |
| Cambiando el nombre del archivo json | Con el cambio en el nombre de la API, ¿se debe cambiar el nombre del archivo JSON alojado? | Sí, se modificaron los lineamientos de envío, y el dominio principal debe entregar un archivo JSON en /.well-known/related-website-set.json. No es necesario cambiar los conjuntos existentes de la lista de RWS, pero, si hay modificaciones enviadas a los conjuntos existentes, se debe cambiar el archivo JSON. |
| (También se informó en trimestres anteriores) Límite de dominios | Solicitud para expandir la cantidad de dominios asociados | Como se anunció en una entrada de blog el 31 de agosto, aumentamos el límite de dominios asociados a cinco dominios después de los comentarios del ecosistema. Decidimos aumentar el límite de dominios asociados a cinco dominios (más un dominio principal), que mejor coincidan con la implementación más comparable de otro navegador importante. |
| Cookies de terceros | ¿Los conjuntos de sitios web relacionados solo funcionarán con las cookies de terceros inhabilitadas? | Los conjuntos de sitios web relacionados funcionarán incluso cuando un usuario no haya bloqueado las cookies de terceros, pero no habrá ningún efecto observable, ya que las cookies relevantes están disponibles sin ninguna necesidad de usar conjuntos de sitios web relacionados ni la API de Storage Access. |
| Ediciones legítimas | ¿Cómo evita el repositorio de conjuntos de sitios web relacionados que los usuarios que no son propietarios modifiquen conjuntos? | Según las guías de envío, cualquier persona puede enviar una solicitud de extracción en GitHub para editar el archivo first_party_sets.JSON. Sin embargo, si se aprueba la solicitud de extracción (pasa validaciones técnicas, etc.), Google la combinará manualmente en lotes con la lista canónica de FPS una vez por semana (los martes a las 12 p.m., hora del este).Si una persona que actúa de mala fe intenta modificar un conjunto que no le pertenece, no debería ser un problema, ya que no podrá modificar los archivos .well-known y, por lo tanto, fallarán las validaciones. |
| Usurpación de dominios | La usurpación de dominio puede exponer los datos del dominio relacionados a terceros no autorizados. | Esto no es posible, como se explicó en este problema de Protected Audience en GitHub. |
API de Fenced Frames
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Infracción de contenido | Permitir que los usuarios denuncien anuncios sospechosos. | Los Marcos vallados no evitan que se generen informes de anuncios sospechosos. Los usuarios aún pueden interactuar con el anuncio y denunciar anuncios sospechosos a la tecnología publicitaria de la manera habitual. |
| Interacción con sitios cercanos | Permite la interacción con el sitio web circundante o de nivel superior. | Queremos comprender por qué es necesaria esta solicitud y recibir comentarios adicionales del ecosistema. |
| Publicidad nativa | Compatibilidad con Fenced Frame para la publicidad nativa | Estamos considerando admitir el caso de uso y estamos analizando posibles soluciones y soluciones posibles. |
API de Shared Storage
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Multidominio | Permite la comunicación entre dominios para el almacenamiento local. | Por el momento, este caso de uso no se alinea con las puertas de salida que preservan la privacidad del almacenamiento compartido, pero aceptamos contexto adicional a medida que desarrollamos propuestas para el almacenamiento no particionado. |
| URL del BLOB | Solicitud para admitir la URL del BLOB en el almacenamiento compartido. | Se agregó compatibilidad con la URL del BLOB en Chrome M116. |
CHIP
No se recibieron comentarios este trimestre.
FedCM
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Cookies de terceros | ¿FedCM está inhabilitado actualmente si los usuarios habilitan "Bloquear cookies de terceros" en la configuración de Chrome? | Sí, actualmente FedCM está inhabilitado. Para realizar pruebas, te recomendamos que habilites chrome://flags/#fedcm- de forma adicional.Esperamos permitir la implementación de FedCM sin cookies de terceros en el futuro. |
Combate el spam y el fraude
API de Private State Token (y otras)
| Tema de comentarios | Resumen | Respuesta de Chrome |
|---|---|---|
| Vencimiento del token | Una vez que se desinstale Google Chrome, ¿se perderá el token o se almacenará en caché? | Si el usuario desinstala Google Chrome, se perderá el token. |
| Información del token | ¿Cómo pueden las entidades emisoras mantener privada la información emitida dentro del token de estado privado? | La información siempre se mantiene privada en el token y no puede ser encriptada por terceros que no tienen las claves. |
| Error en la demostración | Se produjo un error al intentar ejecutar la demostración del token de estado privado. | Actualizamos la demostración y ahora debería funcionar correctamente. |