Relatório de feedback - 2º trimestre de 2025

Relatório trimestral do segundo trimestre de 2025 resumindo o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.

O Google preparou este relatório trimestral como parte dos compromissos com a Autoridade de Concorrência e Mercados ("CMA") de acordo com os parágrafos 12, 17(c)(ii) e 32(a). Este relatório aborda o progresso do Google nas propostas do Sandbox de privacidade, as expectativas de cronograma atualizadas, explicações importantes sobre como o Google considerou as observações feitas por terceiros e um resumo das interações entre o Google e a CMA, incluindo o feedback da CMA e a abordagem do Google para responder a esse feedback.

O Google tem mantido a CMA atualizada sobre o progresso das propostas do Sandbox de privacidade nas reuniões de status regulares agendadas de acordo com o parágrafo 17(b) dos Compromissos. Além disso, a equipe mantém a documentação para desenvolvedores, que oferece visões gerais dos principais recursos de publicidade privada e mudanças nos cookies, além de informações sobre implementação de API e status. As principais atualizações são compartilhadas no blog para desenvolvedores e nas listas de e-mails de desenvolvedores individuais.

Considerando observações feitas por terceiros

Glossário de siglas

ARA

API Attribution Reporting

CHIPS

Cookies com estado particionado independente

DSP

Plataforma de demanda

FedCM

Gerenciamento de credenciais federadas

IAB

Interactive Advertising Bureau

(em inglês)

IDP

Provedor de identidade

IETF

Internet Engineering Task Force

IP

Endereço de Protocolo de Internet

openRTB

Lances em tempo real

Prorrogação

Teste de origem

API PA

API Protected Audience (antiga FLEDGE)

PatCG

Grupo da comunidade de tecnologia de publicidade privada

RP

Entidade confiável

RWS

Conjuntos de sites relacionados (antigos conjuntos primários)

SSP

Plataforma de fornecimento

UA

String do user agent

UA-CH

Dicas de cliente HTTP do user agent

W3C

World Wide Web Consortium

(em inglês)

WIPB

Cegueira intencional de IP

Feedback geral, sem API/tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
Futuro do Sandbox de privacidade	Devido ao anúncio de não prosseguir com a introdução de um mecanismo de escolha do usuário para 3PCs, algumas APIs são mais úteis do que outras quando 3PCs estão presentes, e outras precisam evoluir para serem úteis. Além das APIs do Sandbox de privacidade, há outras áreas em potencial para investimento no Chrome.	Agradecemos o feedback e continuamos interagindo com as partes interessadas para avaliar a função que as APIs do Sandbox de privacidade podem desempenhar no futuro, além de explorar novas áreas para investimento futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Sandbox de privacidade	Alguns participantes do ecossistema ficaram desapontados com o anúncio de não prosseguir com a introdução de um mecanismo de escolha do usuário para cookies de terceiros, mas se orgulham do trabalho realizado, apreciam os desafios técnicos no Sandbox de privacidade e enfatizaram o valor da relação de trabalho colaborativa com o Chrome e a utilidade do Market Testing Grant.	Agradecemos o feedback e concordamos que o Chrome pode e deve colaborar com os desenvolvedores para criar tecnologias que melhorem a privacidade on-line e preservem uma Internet com anúncios.
Compartilhamento de dados do navegador	O compartilhamento de dados mediado pelo navegador é uma tecnologia atraente com potencial para resolver ineficiências de mercado e problemas de confiança. O navegador tem valor como um contexto de execução de terceiros para colaboração.	Agradecemos o feedback e concordamos que o Chrome pode e deve ajudar os desenvolvedores a criar tecnologias que aumentem a confiança entre eles e os usuários.
Tráfego do Chrome	Qual é a parcela do tráfego sem cookies no Chrome e no modo de navegação anônima?	Conforme observado pela CMA no "Aviso de intenção de divulgar compromissos", o modo Incógnito afeta apenas uma pequena fração da atividade de navegação. No Reino Unido e no EEE, o modo Incognito do Chrome representa: menos de 10% das navegações em dispositivos com o sistema operacional Android e menos de 10% das navegações em dispositivos com o sistema operacional Windows. Essas métricas se referem apenas a navegações no Chrome baseado no Chromium no Reino Unido e no EEE. Não compartilhamos dados sobre navegadores que bloqueiam cookies de terceiros. Os desenvolvedores podem determinar quando os cookies são particionados usando cabeçalhos de acesso ao armazenamento e usar as mitigações disponíveis de acordo com a situação.
Etiquetas de teste do Chrome	Qual é o plano do Chrome para 1% do tráfego sem cookies que foi ativado para testes em 2024?	No momento, não temos planos para compartilhar, mas vamos divulgar essas informações assim que estiverem disponíveis.
Teste do Chrome	A configuração atual de rótulo de teste inclui um tratamento para cenários em que os dois 3PCs estão disponíveis e as APIs do Sandbox de privacidade estão ativadas?	A configuração atual de rótulos de teste inclui o tratamento para 3PCs e APIs do Sandbox de privacidade na forma do modo A.
Sandbox de privacidade	Alguns anunciantes acham as APIs do Sandbox de privacidade complexas e estão apáticos devido a exercícios de preparação anteriores, questionando como quantificar a vantagem para os primeiros usuários e buscando informações sobre os efeitos da retargeting, da prospecção e da medição.	Agradecemos o feedback e entendemos os sentimentos sobre a complexidade tecnológica e os exercícios de preparação. Para entender a performance das tecnologias atuais do Sandbox de privacidade, os resultados dos nossos testes indicaram que a participação do ecossistema é um fator essencial para entender a performance das soluções do Sandbox de privacidade. Testes com volumes baixos não reproduzem a dinâmica e os incentivos do mercado para usar as tecnologias em grande escala.

Inscrição e certificação

Nenhum feedback recebido neste trimestre.

Mostrar conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Performance e utilidade de interesse na API Topics com melhorias	O feedback das partes interessadas do lado do comprador indica que a API Topics é um indicador valioso e resulta em dados de custo por impressão (CPM) competitivos com os de públicos-alvo de 3PC para campanhas de anunciantes. Alguns editores consideram o indicador da API Topics de maior qualidade do que os indicadores padrão da Web aberta. Com base nesse feedback sobre a utilidade da API Topics, as partes interessadas estão pedindo melhorias, como aprimorar a fidelidade e a consistência da taxonomia e expandir os controles do editor para impulsionar uma adoção mais ampla.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Utilidade para diferentes tipos de partes interessadas	Como o classificador de temas usa apenas o nome do host da página para definir os temas correspondentes, sites grandes com conteúdo diversificado contribuem com temas genéricos, enquanto sites pequenos contribuem com temas de nicho com mais valor de publicidade.	Nossa resposta é semelhante aos trimestres anteriores: Assim como acontece com os cookies de terceiros, há uma diferença no valor das informações fornecidas por diferentes sites. Os sites de interesse de nicho são inconsistentes na contribuição de valor: nem todos têm conteúdo comercialmente valioso e, portanto, contribuem com menos valor. Esses são os sites que vão se beneficiar da API Topics. Consideramos a possibilidade de classificações no nível da página em vez do site, mas há várias preocupações significativas de privacidade e segurança com essa classificação.
A taxonomia de tópicos não é granular o suficiente	A API Topics não oferece granularidade suficiente para editores de notícias com diversas seções de conteúdo em um único domínio, o que pode limitar a utilidade da API para segmentação de anúncios.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Melhoria do classificador	Permite que os editores concedam ao Chrome permissões para classificar temas com base no conteúdo da página (por exemplo, cabeçalho, corpo).	Estamos considerando essa solicitação e aceitamos mais feedback aqui.
Política	Pedido de esclarecimento sobre as diretrizes relacionadas ao uso da API Topics em conjunto com informações de 3PC.	Não há dificuldades em usar a API Topics e os cookies de terceiros, já que a API Topics oferece um subconjunto das funcionalidades dos cookies de terceiros.
Cabeçalho "Observe-Browse-Topics"	Pedido de esclarecimento sobre a implementação do cabeçalho Observe-Browse-Topics, especificamente se o retorno contínuo do cabeçalho causaria problemas.	Retornar continuamente o cabeçalho Observe-Browse-Topics: ?1 não causa problemas técnicos. O navegador processa esse indicador de maneira eficiente, apenas observando que a visita à página está qualificada para o cálculo de temas sem causar duplicação ou erros. Embora não seja obrigatório em todas as páginas, enviá-lo como um cabeçalho padrão em todos os documentos de nível superior é uma estratégia válida e simples.
Categorias de taxonomia	Solicitação para atualizar a taxonomia de tópicos mais recente com novos tópicos.	Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema aqui.
Valores nulos	Solicitação de orientação sobre como melhorar a performance da API Topics e entender os motivos por trás das respostas nulas, como filtragem ou sensibilidade.	Para fins de esclarecimento, null ou respostas vazias da API Topics são um recurso de privacidade esperado, não um erro. Uma resposta null pode ser causada por: • Regras de privacidade:uma chance aleatória de 5% de null ou porque seu script não "observou" o usuário em sites relacionados a esse tópico. • Estado do usuário:histórico de navegação insuficiente, uso do modo de navegação anônima ou desativação nas configurações de privacidade de anúncios do Chrome. • Erros técnicos:os sites de editores precisam enviar o cabeçalho Observe-Browse-Topics: ?1, e todos os iframes de chamada exigem a permissão allow="Browse-topics". Para investigar, use a página de depuração chrome://topics-internals para saber quais tópicos seu navegador calculou e por quê. Embora os recursos de privacidade impeçam uma taxa de preenchimento de 100%, é possível melhorar a performance ao: • Trabalhar com editores:garanta que seus parceiros enviem corretamente o cabeçalho Observe-Browse-Topics: ?1 nos sites deles. • Verificação do seu código:se você usa iframes, confirme se a política allow="Browse-topics" está em vigor.

API Protected Audience

Tema do feedback	Resumo	Resposta do Chrome
Adoção da API PA prejudicada por custo e complexidade	Os adotantes estão reduzindo a prioridade ou revertendo as integrações da API Protected Audience (PA API) devido a custos operacionais, falta de demanda dos anunciantes e baixo volume de inventário das exchanges. Alguns feedbacks incluíram benefícios do potencial da API PA, como a capacidade de oferecer públicos-alvo duráveis e alcance superior devido a uma alta taxa de correspondência.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Funcionalidade multiplataforma	A funcionalidade multiplataforma precisa ser compatível com o uso da API PA em todas as plataformas para desbloquear mais recursos de retargeting e segmentação por público-alvo. O Google precisa permitir que os grupos de interesse (IGs) registrados no Chrome sejam acessíveis ao veicular anúncios em ambientes nativos ou em webviews, e os grupos de interesse registrados no Android precisam estar disponíveis nos leilões do Chrome.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
directFromSellerSignals	Ao limitar a quantidade de informações disponíveis no leilão contextual, os participantes sempre são encaminhados pelo servidor de anúncios do Google. Um editor precisa primeiro chamar todos os parceiros de troca, depois o Google Ad Manager (GAM) para realizar o leilão contextual e, por fim, permitir que o GAM invoque leilões da IG. Sem saber o resultado do leilão contextual em tempo real, nenhum concorrente pode orquestrar uma decisão de alto nível de maneira justa. O recurso directFromSellerSignals na API PA pode não ter transparência em relação às informações do leilão, o que pode dificultar o acesso aos dados necessários. O Google precisa remover directFromSellerSignals ou atualizar para que não possa ser usado para ocultar o preço de compensação do leilão do servidor de anúncios. Por exemplo, o preço contextual pode ser transmitido pelo Chrome usando um campo transparente, imutável e assinado que todos os participantes do leilão (e o editor) podem acessar e verificar.	Nossa resposta não mudou em relação aos trimestres anteriores: Resposta do Chrome: As informações transmitidas para runAdAuction() não são conhecidas como provenientes do vendedor, a menos que ele chame runAdAuction() do próprio iframe. Em um leilão com vários vendedores, é impossível que todos criem o frame que chama runAdAuction(). O directFromSellerSignals resolveu esse problema carregando conteúdo de um pacote de subrecursos carregado da origem de um vendedor. Isso garante que a autenticidade e a integridade das informações transmitidas a um leilão pelas configurações de leilões do vendedor não possam ser manipuladas. Se os publishers quiserem usar a API PA para entender as informações que os provedores de tecnologia estão transmitindo aos leilões de PA, eles podem pedir essa funcionalidade aos provedores. Resposta do Google Ad Manager: Há anos, mantemos um foco forte na justiça dos leilões, incluindo nossa promessa de que nenhum preço de qualquer uma das fontes de publicidade não garantidas de um publisher, incluindo preços de itens de linha não garantidos, será compartilhado com outro comprador antes que ele faça um lance no leilão. Depois, reafirmamos isso em nossos compromissos com a Autoridade de Concorrência da França. Para leilões com Protected Audience, pretendemos manter nossa promessa usando directFromSellerSignals e não compartilhar o lance de nenhum participante do leilão com outro antes da conclusão do leilão em leilões de vários vendedores. Para deixar claro, não vamos compartilhar o preço do leilão contextual com nosso próprio leilão de componentes, conforme explicado nesta atualização.
Relatórios	Solicitação para adicionar uma entidade de análise/relatório e ativar a geração de relatórios centralizada.	Estamos discutindo essa solicitação aqui e aceitamos mais feedback.
K-anonimato em buyerReportingId	Capacidade de descartar lances com base na k-anonimidade do "buyerReportingId" para facilitar a seleção de público-alvo e as obrigações de relatórios com provedores de dados terceirizados.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Depuração aprimorada no script generateBid	Solicitar um mecanismo para identificar rapidamente a etapa ou o "ponto de interrupção" específico no script generateBid em que o processo está falhando.	Sabemos do uso desejado das medições em tempo real como um mecanismo de definição de pontos de interrupção para leilões no dispositivo. Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Listeners de eventos para monitorar o estado runAdAuction	Proposta para adicionar suporte a listener de eventos à função navigator.runAdAuction da API PA para melhorar o monitoramento do ciclo de vida do leilão de anúncios.	Estamos avaliando essa solicitação e aceitamos mais feedback do ecossistema aqui.
Uso do API	Solicitação para esclarecer como a API PA e a API Attribution Reporting (ARA) podem oferecer suporte a casos de uso de publicidade na Web na ausência de cookies de terceiros, principalmente para usuários que desativaram os cookies de terceiros, mas não as APIs do Sandbox de privacidade, e em cenários que envolvem falhas na sincronização de cookies e WebView.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Latência	A latência associada à API PA pode dificultar a adoção, já que os editores podem desativar a API PA se a latência for muito alta.	Várias melhorias na latência do dispositivo foram feitas nos últimos trimestres. A criação e o escalonamento dos serviços de lances e leilões (B&A) continuam conforme necessário. Nosso guia de práticas recomendadas de latência foi atualizado para incluir mais informações sobre como aproveitar esses recursos. Também estamos desenvolvendo novas melhorias de latência, algumas das quais podem ser consultadas aqui.
Comportamento de geração de registros no B&A (teste x produção)	Esclarecimento sobre as diferenças no comportamento de geração de registros entre os modos de teste e de produção para serviços de B&A. Especificamente, a disponibilidade de registros em nuvem e o impacto do modo de produção no registro.	Primeiro, é importante distinguir entre builds de produção e não produção e o parâmetro TEST_MODE separado, que simplesmente ativa uma chave de criptografia de teste codificada. A explicação abaixo se concentra nos tipos de build. Em builds não de produção, os servidores de B&A têm um nível de detalhamento configurável para geração de registros. Esses registros detalhados são gravados nos fluxos stdout/stderr padrão. No Google Cloud, eles podem ser acessados pela interface de geração de registros nativa. Na Amazon Web Services, eles podem ser encontrados nos registros do console anexado. Para builds de produção, o comportamento de geração de registros é mais restrito. O nível de detalhamento é fixo e não pode ser alterado. Embora alguns registros não relevantes para a privacidade, como mensagens de inicialização do servidor e a maioria dos erros de falha, ainda sejam impressos em stdout/stderr, nenhum registro específico da solicitação está disponível por esse canal. Os únicos registros por solicitação de um build de produção são para solicitações que contêm um token de depuração consentido, e eles são exportados exclusivamente pelo OpenTelemetry. É importante usar a depuração consentida com moderação, já que um tráfego intenso pode prejudicar o desempenho do servidor e causar falhas na verificação de integridade. Em relação às métricas, todas são exportadas pelo OpenTelemetry. As métricas não sensíveis à privacidade são sempre exportadas como estão, sem qualquer ruído. Por outro lado, as métricas sensíveis à privacidade são sempre "ruidosas" quando exportadas de um servidor em execução no modo de produção. A configuração específica de telemetria determina se essas métricas sensíveis à privacidade são exportadas com ruído, sem ruído ou ambos.
Incluir o caminho da página inteira nos indicadores de lances confiáveis para brand safety	Solicitação de uma atualização da API PA para incluir o caminho completo do URL da página de nível superior, além do nome do host, na solicitação de busca de trustedBiddingSignals. O principal caso de uso é ativar controles de brand safety mais granulares. Muitas vezes, os anunciantes precisam bloquear a exibição de anúncios em seções específicas de um domínio (por exemplo, news-site.com/politics), mas não têm problemas com o domínio em geral. Como essas listas de bloqueio podem ter milhões de entradas, elas precisam ser avaliadas no lado do servidor. A especificação atual, que envia apenas o nome do host, impede que o servidor trustedBiddingSignals faça essa avaliação necessária no nível do caminho, limitando os recursos de brand safety.	Estamos discutindo esse problema aqui, após extensas discussões anteriores, que podem ser consultadas aqui, e aceitamos mais feedback. No entanto, queremos esclarecer que só vamos considerar adicionar essas informações quando a busca de trustedBiddingSignals for para um servidor executado em um ambiente de execução confiável (TEE).

Leilão protegido (serviços de lances e leilões)

Tema do feedback	Resumo	Resposta do Chrome
Testar a disponibilidade	Informações sobre a disponibilidade da versão 2 de chave/valor (KV) para testes em ambientes do Chrome e de B&A.	A KV v2 está disponível no B&A e no Chrome. Confira mais orientações aqui.
Implementação do servidor KV	Solicitação de esclarecimentos sobre o uso do servidor KV, especificamente em relação ao mapeamento de URLs de renderização de criativos para dados de solicitação, a necessidade de coordenação entre SSPs e DSPs para definir parâmetros no URL de renderização e a disponibilidade de documentação que descreve a coordenação e o armazenamento de dados necessários no modo KV.	O serviço KV usa o renderURL como uma chave. Se o URL for novo, ele será armazenado. Se ele existir, o valor será retornado para uso em "scoreAd". O formato de retorno depende da configuração: "Traga seu próprio servidor" (BYOS) permite qualquer valor, enquanto o serviço Trusted KV exige uma função definida pelo usuário. Embora nem sempre seja necessário, a coordenação com as DSPs é essencial para recursos como a substituição de macros (por exemplo, ${AD_WIDTH}) no renderURL, que permite a personalização e verificação dinâmica de anúncios. Recomendamos começar com um teste simples com uma DSP para determinar o nível de coordenação necessário. Também estamos atualizando nossa documentação de KV e vamos compartilhá-la publicamente assim que estiver disponível.
BYOS para B&A	Por que a B&A não oferece um modo BYOS semelhante ao da KV?	A B&A exige um TEE, impedindo um modelo BYOS, porque processa combinações de dados altamente sensíveis que exigem a aplicação de mecanismos de privacidade, conforme explicado abaixo. Para DSPs: a B&A processa o contexto do editor (potencialmente o URL completo se enviado explicitamente pelo vendedor via auctionSignals / perBuyerSignals) combinado com dados detalhados do IG do usuário. O TEE é essencial para processar essa combinação com segurança e evitar a reidentificação potencial do usuário. No BYOS de KV, não é possível enviar o URL completo. Para SSPs: Mesmo apenas saber a combinação de IGs participantes (e os proprietários de DSPs deles) em um leilão pode gerar uma assinatura de identificação. É aqui que entra a solução de chaffing, que exige o uso de um TEE. Portanto, o tratamento seguro desses indicadores sensíveis combinados e a aplicação de mecanismos de privacidade exigem o ambiente controlado e comprovado de um TEE.

Como medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Política de ruído	A implementação da ARA foi valiosa para alguns participantes do mercado, e o Google deve continuar mantendo os relatórios no nível do evento. O Google precisa flexibilizar a política de ruído em cenários em que a ARA e os 3PCs estão disponíveis. Os anunciantes de performance estão usando cada vez mais a implementação atual do campo "valor" do evento flexível da ARA, e uma política de ruído menos restritiva ajudaria a reduzir atrasos e relatórios imprecisos.	Esse mecanismo é uma parte fundamental do design da ARA, que visa proteger a privacidade do usuário ao impedir o rastreamento individual. Estamos considerando o feedback sobre os desafios de geração de relatórios causados por ruído. Continuamos avaliando a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, bem como possíveis melhorias futuras, à luz do anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Mapa de ação e suporte de longo prazo	Solicitar uma estratégia de produto para a ARA, bem como a confirmação de investimento e suporte de longo prazo, considerando o anúncio de não prosseguir com a introdução de um mecanismo de escolha do usuário para 3PC.	A equipe do Sandbox de privacidade está interagindo com o ecossistema para entender o papel que as APIs vão desempenhar no futuro e avaliar investimentos futuros.
Medição cross-environment (app para Web)	Solicitação de uma solução que envolva o uso da ARA para facilitar a medição entre ambientes, oferecendo um fluxo de dados mais limpo e confiável e aumentando a capacidade de conectar interações do usuário em diferentes plataformas.	O ARA já oferece suporte ao recurso app-to-web no mesmo dispositivo. Saiba mais sobre a solução de medição cross-app e na Web aqui e aqui.
Atribuição cross-browser	Uma abordagem unificada e entre navegadores da ARA melhoraria muito a capacidade de medir o ROI na Web aberta e ofereceria uma alternativa estável antes de possíveis mudanças regulatórias. O Chrome precisa colaborar com a equipe do Safari em uma solução como essa.	Já estamos estudando uma API interoperável com outros fornecedores de navegadores nos grupos PATCG e PATWG da W3C. Como esse trabalho é preliminar, as partes interessadas podem consultar nosso progresso aqui.
Medição off-line/em dispositivos diferentes	A incapacidade de oferecer suporte à medição de conversões em dispositivos diferentes no ARA é uma limitação significativa. A medição de conversões on-line para off-line também é muito importante, e o navegador pode colaborar com os fornecedores de medição.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Atribuição multitoque	Solicitação para permitir que os anunciantes usem dados do Sandbox de privacidade como uma "verdade fundamental" imparcial para validar e calibrar os modelos de atribuição atuais. Isso pode ser feito usando os dados fornecidos pelo navegador da ARA como um sinal de calibragem confiável, criando um valor de referência de verdade.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Medição de tráfego sem consentimento/desativada	Uma solução que preserva a privacidade, como a atribuição privada interoperável, permite a medição do tráfego sem consentimento. Isso permitiria uma compreensão mais abrangente da performance da campanha, incluindo dados de usuários que desativaram o rastreamento, resolvendo uma grande lacuna na medição criada pelos requisitos de consentimento.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Atribuição de servidor para servidor	Solicitação para permitir que adtechs com infraestrutura sofisticada do lado do servidor se integrem à ARA de maneira mais flexível, acomodando casos de uso difíceis de gerenciar apenas no lado do cliente, sem prejudicar a privacidade do usuário.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Registro em vários domínios	Pedir esclarecimentos sobre limitações e ressalvas ao registrar vários domínios com a ARA, principalmente em relação ao serviço de agregação e à atribuição entre origens.	Confira abaixo as principais limitações ao usar a ARA com vários domínios: • A atribuição é limitada a uma única origem. Não é possível corresponder um clique de um dos seus domínios a uma conversão em outro. A atribuição é isolada na mesma origem para a fonte e o acionador. • O serviço de agregação não é compatível com o agrupamento de várias origens. Os relatórios de origens diferentes precisam ser agrupados e processados separadamente. Estamos estudando maneiras de oferecer suporte a isso no futuro. Em resumo, embora vários domínios possam ser registrados em uma entidade, todas as funções da ARA, como atribuição e agregação, precisam ser processadas por origem.

Serviço de agregação

Nenhum feedback recebido neste trimestre.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Limites e níveis de ruído	Preocupações relacionadas a limitações nos tamanhos das chaves e nos valores de agregação na API Private Aggregation.	Os tamanhos da chave e do valor de agregação foram escolhidos para ter alta granularidade e limitar os custos de rede e armazenamento. Também recomendamos usar hash ao atribuir chaves para maximizar a flexibilidade. Embora existam outros fatores que protegem os dados do usuário, a adição de ruído é uma parte importante das proteções de privacidade da API Private Aggregation. Estamos considerando o feedback e vamos continuar avaliando as opções de parâmetros adequadas, além de analisar o papel que as APIs do Sandbox de privacidade vão desempenhar daqui para frente, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.
Privacidade x utilidade	A abordagem do Sandbox de privacidade pode priorizar a privacidade em vez da utilidade, o que pode dificultar a adoção. Sugestão para permitir um compartilhamento de dados mais granular com o consentimento do usuário para melhorar a medição e a personalização de anúncios.	Os tamanhos da chave e do valor de agregação foram escolhidos para ter alta granularidade e limitar os custos de rede e armazenamento. Também recomendamos usar hash ao atribuir chaves para maximizar a flexibilidade. Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, considerando o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.

Limitar o rastreamento oculto

Redução do user agent/dicas de cliente HTTP do user agent

Tema do feedback	Resumo	Resposta do Chrome
Detecção de spam	Se a primeira solicitação de um site que usa um sistema de detecção de spam depender de dicas do cliente, o sistema de rastreamento ou detecção poderá não identificar ou categorizar corretamente a solicitação.	Os casos de uso que dependem do acesso a dicas de cliente HTTP do user agent (UA-CH) na primeira solicitação precisam usar dicas de cliente críticas.
Feedback sobre a API	Considere descontinuar o Sec-CH-USA-Wow64, já que ele não é mais relevante para a Web moderna.	Estamos considerando essa solicitação e aceitamos mais feedback aqui. Também recebemos feedback de que seria útil estender o wow64 além do Windows.

Proteção de IP (antigo Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Controles	Solicitação para ativar/desativar a proteção de IP para que os sites usem seletivamente fora do modo de navegação anônima.	Agradecemos o feedback e aceitamos mais informações sobre esse problema aqui.
Conduta imprópria	Os tokens de revelação probabilística (PRTs, na sigla em inglês) que resultam em um valor NULL impedem a identificação do perpetrador quando a polícia solicita a divulgação do endereço IP por má conduta na plataforma?	Se um domínio for usado exclusivamente para detecção de fraude e abuso, é provável que ele não seja incluído na lista de domínios mascarados (MDL, na sigla em inglês) e, portanto, não seja afetado pela proteção de IP. Consequentemente, as PRTs não seriam necessárias para esses domínios. Se um domínio estiver incluído na MDL, os PRTs serão a única maneira de saber o endereço IP original de uma solicitação por proxy. Como os PRTs foram projetados especificamente para oferecer suporte à análise agregada, e não à identificação individual, é verdade que eles não contêm um endereço IP na maioria dos casos. Esperamos que isso tenha um impacto limitado no cenário descrito, já que a Proteção de IP se aplica apenas no contexto de terceiros. Isso significa que os editores vão continuar recebendo endereços IP não proxy para interações próprias, como usuários que visitam o site de uma plataforma on-line.
Antifraude	Quais são os detalhes das medidas antifraude do Google para a proteção de IP, incluindo detalhes sobre o acesso limitado a proxies e a emissão de tokens de autenticação? Quais são os casos de uso específicos para PRTs?	Confirmamos que a limitação de taxa e os tokens de autenticação na Proteção de IP foram projetados para impedir que bots cometam fraudes de anúncios acessando proxies em excesso, conforme detalhado na estratégia antifraude e antispam. Outros casos de uso para PRTs estão descritos na documentação explicativa aqui.
Modo de navegação anônima	A proteção de IP no modo de navegação anônima ainda está planejada para o terceiro trimestre?	No momento, não há mudanças no cronograma do terceiro trimestre para o lançamento da Proteção de IP no modo Incognito.

Mitigações de rastreio

Tema do feedback	Resumo	Resposta do Chrome
Feedback sobre a API	O Chrome deve bloquear o acesso a cookies/armazenamento em vez de particioná-los ao aplicar mitigações de rastreamento de rejeição (BTM, na sigla em inglês), citando comportamento não intencional e confusão do método de "particionamento" do Safari.	Agradecemos a sugestão. No momento, o BTM não envolve o particionamento de cookies/armazenamento. Em vez disso, ele exclui os dados após um período de carência. Se houver designs posteriores para a BTM que envolvam ação imediata em relação aos cookies, vamos preferir o bloqueio em vez do particionamento.

Reforçar os limites de privacidade entre sites

Conjuntos de sites relacionados (antigos conjuntos primários)

Nenhum feedback recebido neste trimestre.

API Fenced Frames

Nenhum feedback recebido neste trimestre.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso da API	Solicitação para anexar visualizações de anúncios e cliques no armazenamento compartilhado.	Estamos considerando esse feedback ao avaliar a função que as APIs do Sandbox de privacidade vão desempenhar no futuro, de acordo com o anúncio do Google de abril de 2025 de que a abordagem atual para oferecer aos usuários a opção de cookies de terceiros no Chrome será mantida.

CHIPS

Tema do feedback	Resumo	Resposta do Chrome
Pergunta sobre API	Solicitação de esclarecimentos sobre como os controles de 3PC do Chrome interagem com CHIPS, especificamente se os cookies não particionados são convertidos em particionados quando os 3PCs são desativados e se os cookies particionados permanecem ativos.	Cookies não particionados não serão armazenados, recuperados ou enviados em um contexto de terceiros quando os 3PCs estiverem desativados. No entanto, os cookies particionados vão continuar sendo armazenados, recuperados e enviados em um contexto de terceiros, já que a funcionalidade deles não é afetada pelas configurações do navegador que desativam os 3PCs.
Problema de privacidade	Preocupação de que uma parte incorporada com um identificador persistente, como para o logon único, ainda possa permitir que tanto a incorporação quanto as partes incorporadas ganhem um identificador digital global, mesmo com cookies particionados.	Embora uma parte incorporada possa ter um identificador persistente, esse identificador, quando armazenado em um cookie particionado, só fica acessível no site em que o cookie foi definido pela incorporação. A junção entre sites desse identificador exigiria uma ação de login, que já permite a troca de um identificador na forma de um token de autenticação, mesmo sem o uso de cookies particionados.

FedCM

Tema do feedback	Resumo	Resposta do Chrome
Uso do API	A mediação silenciosa falha para usuários com várias contas sem um erro específico.	O comportamento da mediação silenciosa é um recurso por design, já que é destinado a um caso muito específico com apenas uma conta disponível. Recomendamos usar a mediação "opcional". Nela, a FedCM volta a apresentar ao usuário um seletor de contas se a mediação silenciosa não for possível.
Uso do API	navigator.credentials.get retorna erros genéricos, impedindo a captura de motivos específicos de rejeição, como dispensa do usuário ou períodos de espera.	A incapacidade dos desenvolvedores de distinguir entre o usuário dispensando a caixa de diálogo do FedCM, um erro de rede ou o FedCM estar em um "período de espera" porque o usuário já dispensou a caixa de diálogo também é um recurso de design, destinado a preservar a privacidade do usuário. A preocupação é que essa capacidade permitiria que sites inferissem o estado de login do usuário em diferentes provedores de identidade (IdPs).
Login	Foi observado um comportamento inconsistente na seleção de contas com várias contas conectadas.	Não está claro se a incapacidade intermitente de selecionar uma conta específica em um cenário de várias contas conectadas é um bug intermitente na FedCM ou algum problema envolvendo o sistema de teste. Estamos trabalhando com o jornalista para resolver esse problema e pedimos mais detalhes para entender melhor a situação.
Uso do API	Se o usuário dispensar a caixa de diálogo durante a autorização com a FedCM, o fato de ele estar no estado de espera não será informado por um erro capturável.	Sim, esse seria o caso, e isso produziria o código de erro genérico para preservar a privacidade do usuário.
Uso do API	Por que a FedCM entra em um período de silêncio de 10 minutos após uma "reautenticação automática" bem-sucedida?	Como a reautenticação automática acontece sem uma ação iniciada pelo usuário, se ele quiser voltar ao site, mas fazer login com uma conta diferente, será necessário um período em que o FedCM não faça a reautenticação automática. O "período de espera" dá aos usuários a oportunidade de fazer login manualmente com outra conta. Esta postagem do blog tem mais detalhes sobre esse "período de silêncio".
FedCM leve	Preocupações de que a proposta da Lightweight FedCM introduza mais complexidade para os IdPs devido à necessidade de oferecer suporte a duas implementações incompatíveis (FedCM x Lightweight FedCM).	O Lightweight FedCM é compatível com o FedCM tradicional. Os IdPs podem escolher qual método de implementação usar e não precisam oferecer suporte aos dois. O Lightweight FedCM é um mecanismo de push para o FedCM. Se um IdP optar por usar esse recurso, ele poderá enviar as informações da conta para o navegador quando o usuário fizer login. Assim, quando uma parte confiável (RP) invocar o FedCM, a conta será recuperada do navegador, em vez do endpoint de contas do IdP.
FedCM leve	Preocupações com a exposição de dados pessoais do usuário, como nome, e-mail e foto do perfil, ao RP na proposta Lightweight FedCM.	A proposta para a FedCM leve foi atualizada desde que recebemos esse feedback para remover o nome, o e-mail e a imagem de perfil da resposta do método.
FedCM leve	Gerenciar várias contas conectadas parece ser muito rígido na proposta do Lightweight FedCM. No momento, a proposta não oferece suporte a tempos de vida de sessão individuais ou estados de login diferenciados por conta.	No momento, a expiração está vinculada ao IdP no objeto credentials. Registramos a expiração por conta como uma questão em aberto e vamos considerar esse feedback para desenvolvimentos futuros.
FedCM leve	A distinção entre "conectado" e "disponível para seleção" não está claramente definida, o que pode afetar a experiência do usuário na proposta da Lightweight FedCM.	No momento, não é possível distinguir se uma conta está conectada ou desconectada na interface do usuário (UI) do FedCM. As contas desconectadas não devem ser listadas. Se uma conta estiver desconectada e listada, e um usuário selecionar a conta que não está conectada, a API Continuation poderá ser usada para que o usuário faça login novamente.
Uso do API	Inconsistência entre o campo given_name em getUserInfo e o uso dele na interface do FedCM.	Esse problema foi discutido com a Mozilla neste link para alinhar como o given_name deve ser tratado no getUserInfo.
Uso do API	Nem todos os campos usados na interface de IdentityProviderAccount são fornecidos para getUserInfo, especificamente tel e username, sugerindo uma necessidade de sincronização.	A discussão com a Mozilla e outros membros do FedID Community Group está progredindo sobre a questão de conciliar quais campos de IdentityProviderAccount são enviados para getUserInfo..
FedCM para empresas	Solicitação de suporte da FedCM para casos de uso de IdP empresarial.	O principal problema é a necessidade de um mecanismo confiável para que os IdPs sinalizem aos navegadores que os administradores deram consentimento prévio para permitir que o usuário acesse RPs específicos que não podem ser imitar e/ou abusados por rastreadores da Web. Isso foi discutido na reunião do FedID CG de 22 de abril. Confira as observações da reunião. Combinações de extensões do navegador e políticas empresariais (para dispositivos gerenciados) foram apresentadas como possíveis soluções. Aceitamos mais feedback sobre esse problema aqui.

Combater spam e fraudes

API Private State Token (e outras APIs)

Nenhum feedback recebido neste trimestre.