Esta página foi traduzida pela API Cloud Translation.

Relatório de feedback: primeiro trimestre de 2025

Relatório trimestral do 1º trimestre de 2025 que resume 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') nos parágrafos 12, 17(c)(ii) e 32(a). Este relatório aborda o progresso do Google em relação às propostas do Sandbox de privacidade, as expectativas de tempo atualizadas, explicações substantivas de como o Google levou em consideração as observações feitas por terceiros e um resumo das interações entre o Google e o CMA, incluindo o feedback do CMA e a abordagem do Google para lidar com o feedback.

O Google tem mantido o CMA atualizado 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 informações gerais sobre os principais recursos de publicidade privada e as mudanças nos cookies, além da implementação da API e informações de status. As principais atualizações são compartilhadas no blog para desenvolvedores, além de atualizações direcionadas para as listas de e-mails de cada desenvolvedor.

Glossário de acrônimos

ARA: API Attribution Reporting
CHIPS: Cookies com estado particionado independente
DSP: Plataforma de demanda
FedCM: Gerenciamento de credenciais federadas
IAB: Interactive Advertising Bureau
IDP: Provedor de identidade
IETF: Internet Engineering Task Force
IP: Endereço de Protocolo de Internet
openRTB: Lances em tempo real
Prorrogação: Teste da Origin
API PA: API Protected Audience (antes conhecida como FLEDGE)
PatCG: Grupo da comunidade de tecnologias de publicidade privada
RP: Entidade confiável
RWS: Conjuntos de sites relacionados (antigamente "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
WIPB: IP Blindness proposital

Feedback geral, sem API/tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
Escolha do usuário	Não está claro como será a abordagem atualizada do Google para elevar a escolha do usuário, como ela será apresentada aos usuários e as taxas de ativação/desativação previstas. Mais informações são necessárias para distinguir isso da descontinuação de cookies de terceiros.	Em abril de 2025, o Google publicou uma postagem no blog sobre as Próximas etapas do Sandbox de privacidade e proteções antirrastreamento no Chrome, anunciando que a empresa decidiu manter a abordagem atual de oferecer cookies de terceiros no Chrome e não vai lançar um novo comando autônomo para cookies de terceiros. Vamos enviar mais atualizações assim que estiverem disponíveis.
Técnicas de impressão digital	O Google não compartilhou informações com editores ou profissionais de marketing sobre como eles podem usar alternativas aos sistemas de anúncios do Google sem usar a identidade do consumidor mais arriscada como uma chave de correspondência comum (ou seja, impressão digital).	Destacamos vários sistemas de anúncios que não são do Google que oferecem soluções para editores e profissionais de marketing, criadas em parte com as APIs do Sandbox de privacidade. Isso inclui sistemas de anúncios que não são do Google em vários mercados e canais. Mais detalhes e estudos de caso estão disponíveis na seção "Recursos para empresas" do privacysandbox.com neste link.
Sandbox de privacidade	As APIs do Sandbox de privacidade substituem os ingredientes de dados da Internet pelos próprios produtos acabados do Google. Como a alternativa do Google é uma API, ela oferece acesso a um produto que ele possui e controla, e que está sujeito a termos e condições que o Google tem discrição. Isso não substitui os componentes usados por outras pessoas para criar os próprios produtos finais.	As APIs do Sandbox de privacidade foram desenvolvidas e implementadas após um extenso contato com reguladores e uma ampla gama de partes interessadas do ecossistema. Assim como outras tecnologias de plataforma, as APIs do Sandbox de privacidade precisam considerar que serão usadas como componentes em produtos acabados de outras pessoas. Agradecemos os esforços do ecossistema para desenvolver outras tecnologias que funcionem com as APIs do Sandbox de privacidade.
Escolha do usuário	Solicitação de informações sobre se a abordagem atualizada do Google para 3PCs no Chrome vai atender a determinados requisitos regulamentares, o que pode afetar a experiência da plataforma de gerenciamento de consentimento das partes interessadas.	Em abril de 2025, o Google publicou uma postagem no blog sobre as Próximas etapas do Sandbox de privacidade e proteções antirrastreamento no Chrome, anunciando que a empresa decidiu manter a abordagem atual de oferecer cookies de terceiros no Chrome e não vai lançar um novo comando autônomo para cookies de terceiros. Vamos enviar mais atualizações assim que estiverem disponíveis.
Cronograma e adoção do Sandbox de privacidade	As adtechs pausaram os testes da API do Sandbox de privacidade e estão procurando motivos mais fortes para reinvestir nessas tecnologias em atividades de produto e marketing. As decisões de reinvestimento são fortemente influenciadas pela necessidade de maior clareza sobre o cronograma da escolha do usuário, além das preocupações com a latência da API Protected Audience (API PA) e o roteiro de B&A. Além disso, há preocupações sobre a próxima análise dos compromissos do CMA, principalmente em relação ao papel do Google como principal impulsionador das tecnologias do Sandbox de privacidade sem depender de identificadores de terceiros e a direção geral futura da iniciativa para informar as estratégias de investimento.	Em abril de 2025, o Google publicou uma postagem no blog sobre as Próximas etapas do Sandbox de privacidade e proteções antirrastreamento no Chrome, anunciando que a empresa decidiu manter a abordagem atual de oferecer cookies de terceiros no Chrome e não vai lançar um novo comando autônomo para cookies de terceiros. Vamos divulgar mais informações assim que possível. Os leilões da API PA do Chrome são 35% mais rápidos ano a ano. Além disso, notamos um aumento significativo no uso de leilões paralelos, o que gera uma vitória ainda maior para esses leilões. Nosso roteiro atual de B&A está disponível aqui.
Cronograma do Sandbox de privacidade	O que foi atualizado na página do cronograma do Sandbox de privacidade?	Recentemente, uma visão geral da API Topics foi adicionada à página do cronograma do Sandbox de privacidade.
Sandbox de privacidade	Há algum artigo de pesquisa sobre privacidade x utilidade para ajudar a entender o impacto do Sandbox de privacidade na receita?	Os estudos de caso relevantes do mercado que abordam essas perguntas estão disponíveis aqui, e os resultados dos testes das APIs do Sandbox de privacidade estão disponíveis aqui.
Adoção do Sandbox de privacidade	Um usuário inicial relatou desafios iniciais com as APIs do Sandbox de privacidade devido à adoção lenta por empresas maiores, o que afetou os lançamentos de testes. No entanto, apesar disso, a abordagem colaborativa e a capacidade de resposta da equipe do Sandbox de privacidade foram apreciadas.	Agradecemos o feedback dos usuários iniciais. Estamos comprometidos em colaborar com os primeiros usuários e vamos continuar interagindo com o ecossistema e coletando feedback enquanto avaliamos o papel das tecnologias do Sandbox de privacidade no apoio ao ecossistema.
Testes do Chrome	Preocupação com a capacidade de continuar os testes do Sandbox de privacidade de maneira eficaz após a remoção dos rótulos de teste, destacando a diferença significativa na qualidade do tráfego entre o Chrome com 3PCs desativados (Modo B) e os usuários que desativaram o 3PC nas configurações do Chrome.	Nossa resposta é semelhante aos trimestres anteriores: A equipe do Sandbox de privacidade entende que as empresas querem continuar usando os rótulos de descontinuação de cookies. O processo para estender a disponibilidade dos rótulos é semelhante ao de estender um teste de origem. O suporte aos rótulos foi estendido em várias ocasiões. Vamos propor a extensão do suporte aos rótulos de descontinuação de cookies e compartilhar atualizações no blink-dev conforme elas forem lançadas.

Inscrição e atestado

Nenhum feedback recebido neste trimestre.

Mostrar conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Ativar/desativar	A confirmação do Google de que a Pesquisa Google não vai usar a decisão de um site de desativar a API Topics como um indicador de classificação vai impedir que o Google use a decisão de um site de ativar a API Topics como um indicador de classificação?	Nossa resposta é semelhante à dos trimestres anteriores: A equipe do Sandbox de privacidade não coordenou nem pediu à organização de pesquisa que use a classificação de páginas como incentivo para que os sites adotem a API Topics. A Pesquisa Google não vai usar a decisão de um site de oferecer suporte (ou não) à API Topics como um indicador de classificação.
Observabilidade do uso	Solicitar um mecanismo de observabilidade para uma SSP ou uma adtech geral para saber se a implementação da API Topics está sendo usada na Web.	Estamos avaliando o suporte a essa funcionalidade e agradecemos mais feedback do ecossistema se esse recurso for uma prioridade alta.
Privacidade	Perguntas sobre consentimento e potencial de reidentificação.	Estamos discutindo o problema neste link e gostaríamos de receber mais feedback.

API Protected Audience

Tema do feedback	Resumo	Resposta do Chrome
API PA e GAM/AdX	O Google não vai enviar nenhuma demanda do GAM/AdX para um editor que queira usar um servidor de anúncios de editor rival. O Google precisa permitir que editores rivais escolham vendedores de leilão de API PA de nível superior alternativos para controlar o leilão final. As informações da API PA vão estar disponíveis para o GAM, mas restritas para SSPs rivais. Como resultado, os editores não podem comparar a performance da demanda proveniente da API PA no GAM, como do AdX ou de SSPs integrados à API PA.	Resposta do Chrome: O padrão da API PA foi projetado para ser flexível e permite que diferentes partes executem o leilão de nível superior. Essa escolha depende das implementações e dos recursos específicos oferecidos pelo servidor de anúncios do editor (seja o GAM ou outro) e de outras empresas participantes do ecossistema. O design com foco na privacidade da API PA limita os relatórios granulares para todos os participantes de forma consistente. Os dados específicos relatados do leilão da API PA estão sujeitos às mesmas regras e limitações de preservação da privacidade definidas pela API para todos os participantes, incluindo SSPs. Os editores usam os relatórios agregados e que preservam a privacidade da API PA para avaliar a performance. Isso permite avaliar a contribuição geral da demanda gerada pela API PA e comparar com outros canais de demanda, de acordo com os princípios de privacidade por design da API. Resposta fornecida pelo Google Ad Manager: Os editores não precisam usar a funcionalidade do servidor de anúncios do GAM para acessar a demanda do AdX. Além disso, a API PA não tem conhecimento de quem inicia um leilão em designs de um único vendedor e de vários vendedores.
Vendedor de nível superior	O vendedor de nível superior (TLS) tem acesso a informações que nenhum dos outros vendedores de componentes tem, o que levanta preocupações sobre o acesso desigual às informações. Qualquer entidade pode ser a TLS, mas, para acessar a demanda do AdX, os editores precisam usar o GAM como servidor de anúncios do editor. Isso cria um incentivo para usar o GAM como servidor de anúncios do editor, criando uma vantagem competitiva para o Google.	Resposta do Chrome: O design da API PA não determina qual entidade pode atuar como TLS. A função TLS exige a coordenação do leilão e o acesso às informações relacionadas a ele de acordo com a estrutura da API. Resposta do Google Ad Manager: Há anos, temos um forte foco na justiça dos leilões, incluindo nossa promessa de que nenhum preço de nenhuma das fontes de publicidade não garantidas de um editor, incluindo os preços de itens de linha não garantidos, será compartilhado com outro comprador antes que ele dê lances no leilão, o que reafirmamos mais tarde nos nossos compromissos com a Autoridade de Concorrência Francesa. Para leilões da API PA, pretendemos manter nossa promessa e não compartilhar o lance de nenhum participante do leilão com outro participante antes do término do leilão em leilões com vários vendedores. Para deixar claro, não vamos compartilhar o preço do leilão contextual com nenhum leilão de componentes, incluindo o nosso, conforme explicado nesta atualização. Além disso, não usamos informações sobre configurações de leilão de componentes, incluindo indicadores fornecidos pelos compradores aos SSPs, como parte do nosso próprio leilão. Além disso, como mencionado acima, o GAM não exige que os editores usem a funcionalidade do servidor de anúncios para acessar a demanda do AdX. Por fim, como observado anteriormente no relatório do 2º e 3º trimestre de 2024 do Google, as plataformas de compra do Google, Google Ads (anteriormente AdWords) e DV360, compram impressões de trocas que não são do Google, inclusive pela API PA.
API PA e GAM/AdX	É difícil para os editores entenderem como ativar a API PA em 100% do inventário, porque o rótulo da opção não deixa claro o propósito. Para SSPs, cuja principal forma de acessar o inventário é geralmente por meio de um leilão de vários níveis com o GAM atuando como TLS, não há como realizar testes ou gerar receita pela API PA sem estar sujeito ao GAM.	Resposta do Chrome: O padrão da API PA define funções técnicas (como TLS e vendedor de componentes) e o processo de leilão, permitindo flexibilidade nas plataformas que executam essas funções. As atividades operacionais, como configuração, coordenação e acordos, são gerenciadas pelas partes responsáveis pela implementação (editores, SSPs, provedores de TLS) para facilitar a participação usando o framework da API PA. Resposta fornecida pelo Google Ad Manager: Conforme descrito na Central de Ajuda, o Ad Manager oferece aos editores um controle para ativar os testes com vendedores de componentes que não são do Google, como outros SSPs, em 100% do inventário de um editor em que a API está disponível para uso, substituindo qualquer amostragem ou limitação que o GAM possa aplicar. Se um editor ativar esse controle, sempre que um vendedor de componentes que não seja do Google fornecer uma configuração de leilão, o GAM tentará executar um leilão de nível superior com o leilão de componentes fornecido incluído, desde que o editor tenha recebido o consentimento necessário do usuário para fazer isso. O GAM deixa claro para os editores que esse controle pode afetar a performance, para que eles possam tomar uma decisão informada.
Lado do servidor x no dispositivo	As soluções do lado do servidor, como os lances e leilões (B&A, na sigla em inglês), podem resolver o problema da modelagem de tráfego, mantendo a privacidade. As soluções do lado do servidor são o único caminho viável, e o Google precisa abandonar as soluções no dispositivo.	O objetivo do Sandbox de privacidade é oferecer suporte a soluções de leilão no servidor (serviços de B&A) e no dispositivo, oferecendo opções para atender a diferentes necessidades e casos de uso de adtechs.
Segurança do leilão	Os ataques aos lances da API PA são, em princípio, desqualificados para lances e leilões no dispositivo. As partes interessadas não consideram que esse problema foi resolvido e continuam solicitando garantias técnicas para garantir que os lances da API PA não sejam adulterados, além de um modo de depuração exaustivo para detectar incidentes em tempo real e depurar de forma eficiente.	Garantir a integridade do leilão da API PA, incluindo a mitigação de possíveis ataques, é um dos principais focos do Sandbox de privacidade. O design da API incorpora medidas de integridade, e agradecemos mais discussões técnicas sobre problemas específicos. Apresentamos e discutimos uma lista detalhada de possíveis ataques à API PA e nossas mitigações durante a reunião do W3C Anti-Fraud Community Group em maio de 2024. Agradecemos mais discussões e feedback sobre quais possíveis "ataques a lances de API de PA" são preocupantes.
Tráfego sem cookies	Será possível ativar a API PA apenas no tráfego sem cookies para testes ou outras finalidades?	As adtechs podem identificar se os 3PCs estão presentes ou não. Confira mais detalhes aqui.
Código da licença	Em relação à proposta de ID do assento, o conhecimento do ID do assento é essencial para a maioria das solicitações de lance, o que gera preocupação em vincular o ID do assento ao registro do criativo. Além disso, isso se aplica apenas ao "principal" ou também aos anúncios componentes?	A proposta BuyerAndSellerReportingId aborda a preocupação com a falta do ID do assento do comprador durante o registro do criativo do anúncio principal. Esse identificador tem como objetivo comunicar o ID do assento do comprador ao vendedor. Estamos avaliando o suporte a anúncios de componentes.
Monitoramento e relatórios	Solicitação de recurso para o monitoramento em tempo real (RTM, na sigla em inglês) para (1) enviar relatórios de RTM para leilões cancelados e (2) novos buckets preenchidos pelo navegador para deixar claro o tipo de cancelamento que ocorreu.	O RTM não parece ser uma solução adequada para investigar a taxa de participação. O RTM foi projetado como uma API de monitoramento de baixa latência para detectar falhas críticas, repentinas e temporárias. Por outro lado, a taxa de participação não exige relatórios de baixa latência e não é uma interrupção temporária crítica e repentina. As dúvidas sobre as taxas de participação são respondidas de maneira mais eficaz pelos vendedores com quem os compradores colaboram, e não pelos compradores que investigam pelo navegador. Além disso, como os leilões cancelados são extremamente comuns, se o navegador gerar relatórios de RTM de cada leilão cancelado, isso pode ofuscar os relatórios de RTM para interrupções reais.
Documentação Esclarecimento	Relatório de uma discrepância na documentação da explicação da API PA que afirma que o valor de uso único precisa ser uma string UUID, mas na verdade ele retorna uma promessa.	Confira aqui uma proposta de esclarecimento.
Contexto congelado	Ao trabalhar com o contexto congelado, quais opções estão disponíveis para resolver problemas e desafios relacionados a (1) agrupamento, (2) bibliotecas externas e (3) tipos de dados sem suporte?	Respondemos a essa pergunta aqui.
Especificações	A API Private Aggregation adicionou uma operação genérica contributeToHistogramOnEvent. Como consequência, a definição na API PA se tornou uma operação sobrecarregada, e as operações do IDL da Web "não podem ser sobrecarregadas em toda a interface, interface parcial [...]". Portanto, essa definição agora é inválida.	Esse problema aponta uma inconsistência temporária entre as especificações da API PA e da agregação privada enquanto mesclamos mudanças semelhantes em ambas. Mesclamos uma solicitação de envio para resolver esse problema.
Grupos de interesse	Solicitação de orientação sobre o método recomendado e eficiente em termos de recursos para encerrar a participação em lances de um grupo de interesse (GI) quando uma campanha é interrompida.	Confira algumas sugestões: Acreditamos que o mecanismo com a menor latência, o menos permanente, mas também o menos liberador de recursos é o uso dos indicadores de lances em tempo real para informar o `generateBid()` a parar de dar lances. A segunda opção que usa menos recursos seria definir uma prioridade negativa para esse IG na resposta dos indicadores de lances em tempo real, já que isso impediria a invocação de `generateBid()`. A terceira opção, que usa ainda menos recursos, é remover os anúncios do IG. Os IGs sem anúncios não têm o `generateBid()` invocado. A quarta opção, que usa ainda menos recursos, seria remover o `biddingLogicURL` do IG. Nesse ponto, o IG ainda pode ser atualizado/reunido para ser reativado. Outras opções giram em torno de sair do IG, seja por `leaveAdInterestGroup()` ou `clearOriginJoinedAdInterestGroups()` ou pela expiração do IG. Como destacado acima, diferentes opções têm diferentes implicações de latência e consumo de recursos. As adtechs podem escolher a opção que tem a melhor compensação para seus casos de uso específicos.
Públicos-alvo	Solicitação de um mecanismo para executar operações lógicas em públicos-alvo criados (por exemplo, a capacidade de segmentar uma interseção de IG A e B)	Com a API PA, já é possível executar operações lógicas em públicos-alvo do mesmo site. No momento, não é possível usar operações lógicas de públicos-alvo em diferentes sites por motivos de privacidade, conforme explicado no nosso modelo de privacidade. Continuamos realizando pesquisas nessa área e vamos compartilhar as atualizações.
Solicitação de recurso	Proposta para remover a restrição de lances adicionais que exigem que o TLS seja conhecido com antecedência.	Estamos discutindo essa proposta aqui e agradecemos mais feedback.
Abordagem atualizada para 3PCs no Chrome	As APIs do Sandbox de privacidade, como a API PA, vão continuar disponíveis para todos os usuários do Chrome Stable ou só estarão disponíveis para usuários que recusaram os 3PCs?	Não pretendemos que a decisão de um usuário de recusar cookies de terceiros afete a disponibilidade das APIs do Sandbox de privacidade no Chrome Stable.
Sinalização aprimorada	Há planos para adicionar uma funcionalidade que indique se o TLS pretende executar um leilão da API PA?	Estamos avaliando o suporte a essa funcionalidade. Vamos compartilhar mais detalhes sobre o prazo quando estiverem disponíveis e agradecemos seu feedback sobre essa solicitação.
ID da oferta	Preocupação de que o requisito do servidor KV na proposta de ID do negócio possa ser um processo caro e demorado do lado do servidor.	A proposta de ID de transação permite que as SSPs consultem os metadados dos IDs de transação selecionados no servidor de chave-valor durante os leilões de PA, para que não precisem pré-carregar todos os metadados relacionados à transação no dispositivo. Essa proposta está sendo desenvolvida em resposta a solicitações de SSPs. Envie seu feedback sobre o ecossistema aqui. Entendemos que é necessário trabalhar para configurar o servidor de chave-valor, mas, no geral, ainda acreditamos que isso é um benefício líquido para as empresas de adtech. Continuamos recebendo feedback e sugestões para facilitar esse processo.
Limite de frequência entre contas do Instagram	Solicitação de limite de frequência entre contas do Instagram pela API PA.	O limite de frequência entre contas do Instagram tem características de privacidade desafiadoras para as quais não conseguimos encontrar soluções. Se esse recurso for uma prioridade alta, agradecemos o feedback do ecossistema.
Relatórios de IDs de transação e de licença	Solicitação de capacidade de receber IDs de assentos ou transações em relatórios agregados.	As funcionalidades de ID de relatório em que estamos trabalhando aqui vão permitir o envio de IDs de transação e assento. O selectedBuyerAndSellerReportingId é fornecido para reportResult(). Portanto, a maneira mais fácil de informar é por meio de relatórios de eventos, ou seja, codificando o ID do negócio no URL transmitido para sendReportTo(). Se os relatórios agregados forem usados, isso também poderá ser feito. No momento, o recurso de ID de relatório está ativo para 10% do tráfego do Canal Stable do Chrome. Estamos avaliando a expansão do lançamento para 100%.
Grupos de interesse	Use a mesma ordem de prioridade na seleção e avaliação do IG e use essa ordem de prioridade em todos os modos de avaliação.	Estamos discutindo isso aqui e agradecemos seu feedback.
Grupos de interesse	Sugestão de usar a ativação e a delegação de público-alvo como formas de aumentar a adoção da API do Sandbox de privacidade.	Sabemos que várias partes interessadas fizeram esse pedido e estamos pesquisando uma solução. Agradecemos o feedback do ecossistema.
Grupos de interesse	Desafios relacionados à criação de IGs da API PA, especificamente em relação à delegação e à propriedade ao agir em nome de vários compradores ou em nome de editores.	Recebemos o pedido de suporte a delegações mais avançadas de IG de várias partes interessadas e percebemos o valor agregado das SSPs que contribuem para esse processo. Estamos realizando pesquisas para encontrar a melhor solução que permita que diferentes partes participem do processo de extensão do público-alvo. Queremos receber mais feedback do ecossistema.
Performance do lado do cliente	Solicitação de orientação sobre como facilitar o armazenamento em cache do lado do cliente de trustedBiddingSignals para otimizar o custo de infraestrutura e a latência.	Estamos discutindo isso aqui e agradecemos seu feedback.

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

Tema do feedback	Resumo	Resposta do Chrome
Serviços de chave-valor	Como as solicitações do navegador para o servidor KV do vendedor são agrupadas? Para um vendedor, como será a solicitação do navegador: GET ou POST? Além disso, alguns esclarecimentos são necessários sobre os requisitos de k-anonimato.	Na v1, o Chrome envia uma solicitação GET para o serviço KV do vendedor para buscar `trustedScoringSignalsURL` com os indicadores nos parâmetros de consulta da solicitação. Os parâmetros incluem `hostname`, `renderUrls`, `adComponentRenderUrls` e `experimentGroupId`. No momento, estamos testando algumas extensões para enviar informações adicionais para a verificação de criativos, mas isso ainda não foi lançado. Ao definir `maxTrustedScoringSignalsURLLength` como 0, o Chrome pode agrupar todos os indicadores em uma única solicitação (possivelmente excedendo qualquer limite de comprimento do URL no servidor), mas isso não é garantido. No momento, o Chrome escolhe incluir solicitações no mesmo lote se elas estiverem prontas para serem enviadas em até 10 ms uma da outra, mas estamos investigando como otimizar isso. Ao trabalhar com trustedScoringSignals, é útil lembrar que o Chrome respeita os cabeçalhos de armazenamento em cache. Cabeçalhos como `Stale-While-Revalidate` "Cache-Control" podem reduzir a latência média, permitindo que o Chrome use a cópia em cache (e atualize o cache para o próximo leilão), removendo efetivamente a busca de indicadores do caminho crítico. Por fim, em relação ao k-anonimato, a seção específica do texto explicativo parece desatualizada. Originalmente, íamos exigir que os URLs de indicadores confiáveis fossem k-anônimos, mas esse requisito foi descartado. Vamos remover esta frase da explicação.
Serviços de B&A	O upgrade para a versão mais recente do B&A leva muito tempo. Tempos de build mais rápidos ou imagens pré-criadas seriam benéficos.	As adtechs podem criar os binários por conta própria e validar usando os hashes fornecidos. Vamos considerar a possibilidade de fornecer artefatos pré-criados ou melhorar os tempos de build no futuro.
Solicitação de recurso de API	Solicitação de compatibilidade com o macOS para scripts de build, imagens de contêiner e ferramentas de invocação de serviços de lances e leilões (B&A) para facilitar o desenvolvimento e o teste locais.	No momento, somos compatíveis com amd64, o que é suficiente para a implantação nas plataformas de nuvem compatíveis (GCP e AWS). No futuro, vamos investigar o suporte a outras arquiteturas.
AWS	É necessário criar papéis do IAM para builds de produção?	Sim, os papéis do IAM são necessários para as permissões adequadas e a comunicação com os coordenadores. As chaves são usadas para descriptografar o texto criptografado ProtectedAudienceInput gerado no dispositivo, conforme definido aqui. Além disso, essas funções são necessárias para transmitir o certificado do servidor/TEE de builds de produção com os mesmos coordenadores. Isso é abordado com mais detalhes no nosso guia de autoatendimento.
Bandeiras de B&A	Solicitar que as definições das flags de B&A disponíveis sejam listadas na documentação, já que hoje elas estão no código do Terraform, nos arquivos cc e proto, mas as adtechs se beneficiariam com a documentação sobre essas flags, usando-as como uma fonte de verdade para entender como personalizar as implantações.	Estamos investigando a possibilidade de documentar as descrições das flags do Terraform e agradecemos mais feedback aqui.
Serviço de lances da AWS	Procurando orientação sobre o serviço de lances na AWS e o comportamento e a configuração de registro padrão.	Para depurar seus serviços de lances no TEE (como o serviço de lances), recomendamos usar a depuração consentida de adtechs. Isso permite ativar o registro detalhado e capturar dados de solicitação/resposta para solicitações de teste específicas diretamente do cliente para ajudar na depuração.
Documentação do TEE K/V	Solicitação de esclarecimento sobre o início da aplicação do TKV, conforme indicado no site para desenvolvedores.	Vamos avisar com antecedência suficiente antes de exigir o uso de TEEs. Até lá, você pode continuar usando seu próprio servidor para indicadores de chave-valor em tempo real.
Testes e análise de B&A	A análise e os testes de B&A continuam caros e não parecem estar prontos para a produção.	Precisamos de mais informações sobre a análise de custos e os fatores que levaram à avaliação de prontidão para produção para analisarmos melhor.
Otimização de servidor confiável	Proposta de mesclagem de parâmetros específicos para vendedores de componentes em um parâmetro inputsPerSeller, usando uma string JSON como valor.	Estamos discutindo essa proposta e agradecemos o feedback aqui.
Segurança	Como os riscos de segurança do TKV são mitigados usando a B&A?	É possível impedir chamadas externas para o TKV. Esse recurso já está disponível e totalmente configurável no GCP. Para a AWS, é necessário desenvolver mais suporte devido à descontinuação do AWS App Mesh, que permitia isso anteriormente. Envie seu feedback aqui.
Serviços de B&A	Pedindo clareza sobre a narrativa/comunicação em relação ao valor do streaming HTTP para otimização de B&A.	O Sandbox de privacidade oferece suporte a recursos de streaming na transferência de dados de B&A para melhorar a latência das adtechs que optarem por usá-lo. É uma otimização de desempenho opcional no caso de modo misto.
Prebid	Pedido de atualizações sobre como contribuir com a biblioteca de código aberto Prebid para ativar os recursos de B&A da API PA para o ecossistema.	Em março de 2025, o Chrome lançou a otimização preferencial da Prebid na versão estável, conforme documentado no plano de lançamento público da B&A (consulte março de 2025).
Ajuste da programação	Solicitação de mecanismos para registrar indicadores contextuais recebidos pela B&A para entender melhor quando os IGs estão sendo ativados e melhorar a lógica de "intenção de lance" na resposta contextual. Isso permite um melhor uso dos recursos de rede para evitar "tráfego inútil" (também conhecido como modelagem de tráfego).	Estamos discutindo uma proposta aqui e agradecemos mais feedback.
Documentação Esclarecimento	É necessário esclarecer o erro "O proxy de serviço/Vsock não pode ser acessado" detectado na configuração de integração de teste de B&A.	Isso ocorre devido aos requisitos mínimos de memória.O explicador de configuração da AWS foi atualizado para refletir esse requisito.

Como medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Dados em tempo real	A falta de dados em tempo real afeta todos no setor. O atraso nos dados em tempo real é um problema sério para os anunciantes. Os compradores migram para plataformas que têm o Google Analytics, porque é o único lugar em que podem comprovar o alcance de públicos-alvo.	Os atrasos nos dados em tempo real que fazem parte da API Attribution Reporting (ARA) são implementados como mecanismos de proteção de privacidade para reduzir a capacidade das adtechs de usar relatórios de eventos para rastrear usuários em vários sites. No entanto, o ARA oferece flexibilidade na forma como os relatórios de atribuição são entregues, permitindo que os relatórios de eventos tenham uma janela mínima de 1 hora e que os relatórios agregados tenham a opção de serem enviados instantaneamente para as adtechs sem atraso.
Uso do API	Solicitação de confirmação sobre a configuração correta de um fluxo de atribuição entre apps da Web, especificamente quando a atribuição da Web para a Web e da Web para o app são operadas em paralelo.	Ao veicular campanhas Web-to-Web e Web-to-App em paralelo, a adtech precisa escolher apenas uma plataforma para registrar cada origem ou acionador, para evitar a contagem dupla. É altamente recomendável usar o sistema operacional (SO) sempre que possível, já que ele pode fazer a atribuição de Web para Web e de Web para app, desde que as fontes e os acionadores da Web tenham sido delegados corretamente. Isso significaria responder com o cabeçalho Attribution-Reporting-Register-OS-Source para fontes e Attribution-Reporting-Register-OS-Trigger para acionadores. O cabeçalho Attribution-Reporting-Support pode ser usado para identificar se há suporte no Chrome e/ou no Android. O cabeçalho "Attribution-Reporting-Info" é útil quando não há um cabeçalho "Attribution-Reporting-Support" na solicitação. Nesse caso, o navegador toma a decisão de registro da plataforma com base na disponibilidade do suporte à plataforma no dispositivo do usuário.
Especificações da API	Procurando esclarecimentos sobre o cabeçalho de solicitação HTTP Attribution-Reporting-Support definido pela API Attribution Reporting e se ele tem a intenção de conter chaves da Web e do sistema operacional, independentemente da plataforma.	O cabeçalho Attribution-Reporting-Support está sujeito à adição de parâmetros "GREASE" pelo navegador para garantir que os servidores usem um analisador de cabeçalho estruturado compatível com a especificação. Para esse cabeçalho, apenas chaves de dicionário estruturado precisam ser interpretadas. Os valores e parâmetros não estão sendo usados no momento. Confira um exemplo aqui.
Relatórios com base em 3PC	Pedir orientações sobre como resolver problemas de discrepâncias de medição entre a ARA e a 3PC em campanhas publicitárias.	A ARA oferece suporte a dois tipos de relatórios de depuração que podem ser usados para resolver problemas e depurar discrepâncias. Os relatórios de depuração de atribuição concluída podem ser usados para comparar facilmente os resultados da ARA com os resultados de outras tecnologias de medição. Já os relatórios de depuração detalhados podem ser usados para receber mais informações e resolver possíveis problemas nos registros de atribuição.
Uso do API	Durante o teste do ARA, foram descobertos alguns problemas: relatórios granulares insuficientes que levam a dados com ruídos e otimização de campanhas inflexível, limites altos que excluem anunciantes menores e dificuldade de comparar campanhas devido a indicadores de desempenho-chave inconsistentes.	A ARA oferece flexibilidade com vários parâmetros que as adtechs podem personalizar para alcançar seus casos de uso de medição específicos. Os relatórios de eventos oferecem suporte a relatórios flexíveis de eventos, o que permite que as adtechs personalizem as janelas de relatórios, o número de relatórios que podem receber e os dados de acionadores que querem medir. Isso pode mudar o impacto do ruído nos dados e permitir diferentes casos de uso. Da mesma forma, os relatórios agregados têm diferentes maneiras de personalizar as configurações das adtechs, como o número de dimensões que elas rastreiam, a frequência de agrupamento e o uso do orçamento de contribuição para mudar o impacto do ruído e alcançar diferentes casos de uso.
Especificações da API	Pergunta sobre a dependência do ARA em 3PCs, especificamente se ele permanece em uma fase de teste que exige esses 3PCs.	A ARA é ativada independentemente dos terceiros, mas eles precisam ser ativados para que os relatórios de depuração transicionais da ARA comparem os resultados da ARA com os resultados de atribuição baseados em cookies.
Uso do API	Pergunta sobre o registro de fontes para atribuição do app para a Web em versões mais antigas do Android (11, 12 e 13) usando a ARA.	No momento, o ARA tem suporte para o Android S e versões mais recentes (12+).
Uso do API	Solicite taxas de ativação e detalhes de distribuição do ARA.	Nossa resposta não mudou em relação aos trimestres anteriores: "Não temos planos de compartilhar essas informações com o ecossistema. Os desenvolvedores podem chamar as APIs em que têm o código implantado hoje para estimar a disponibilidade das APIs do Sandbox de privacidade.
Disponibilidade da API	Quando a ARA está ativada, os 3PCs estão ativados ou desativados?	Quando a ARA está ativada no navegador do usuário, ela não afeta as configurações de cookies. É possível ativar a ARA e permitir ou desativar os cookies do usuário.
Relatórios	Há uma lista predefinida de valores que podemos receber no cabeçalho "Attribution-reporting-support"?	Conforme definido em nossas orientações, o valor é um dicionário de cabeçalho estruturado, cuja única semântica definida atualmente é a presença ou ausência das chaves do SO e da Web. Todas as outras partes do cabeçalho devem ser ignoradas. Em outras palavras, a análise exige o uso de um analisador de cabeçalho estruturado, não uma simples correspondência de string.

Serviço de agregação

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso	Solicitações de recursos para o Aggregation Service: Integrações de servidor a servidor, medição em vários dispositivos, facilidade na geração de relatórios de atribuição e contribuição multitoque, atribuição omnichannel e suporte para ciclos avançados de otimização de ML (por exemplo, Treinamento de modelo privado).	Estamos avaliando essas solicitações e vamos compartilhar mais detalhes quando estiverem disponíveis. Agradecemos o feedback adicional do ecossistema sobre se essas solicitações são uma prioridade.
Solicitação de recurso	Solicitação para definir o parâmetro delete_on_termination do EBS como "True" no ambiente do Terraform, a fim de reduzir as preocupações sobre a redefinição ao atualizar o conjunto de serviços de agregação.	Estamos avaliando esse pedido e vamos compartilhar mais detalhes quando estiverem disponíveis. Envie seu feedback sobre se essa solicitação é uma prioridade aqui.
Documentação Esclarecimento	Pedir orientações sobre o que pode ser alterado (por exemplo, limites de monitoramento) e o que não pode ser alterado.	Estamos avaliando a publicação de mais documentação e orientações sobre as personalizações disponíveis para o serviço de agregação.
Implantação	Solicitação de esclarecimento sobre a nova implantação com falha no comando bazel.	A falha na implantação pode acontecer devido à versão do Bazel usada no ambiente. A documentação será ajustada para cobrir a depuração de falhas do Terraform e indicar a versão do Bazel necessária.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Uso do API	Solicitação de orientação sobre alguns desafios de implementação, como a possível perda de dados devido a limitações do Armazenamento compartilhado, dificuldades com alta cardinalidade que exigem listas de permissões complexas do serviço de agregação (é recomendado usar caracteres curinga) e testes lentos causados pela regra "sem duplicações" do serviço de agregação.	Em relação às limitações do Shared Storage, o limite de 20 contribuições (detalhado aqui) é por execução, não por mês. Além disso, os autores de chamadas de API podem substituir esse limite. O limite foi implementado para ajudar a gerenciar o custo de processamento de relatórios no serviço de agregação e não para limitar o utilitário de relatórios. Em relação às consultas com curinga, estamos avaliando esse pedido e vamos compartilhar mais detalhes quando estiverem disponíveis. Em relação à regra "sem duplicatas", para permitir testes, oferecemos suporte temporário ao modo de depuração com o objetivo de ignorar essa regra. Confira mais detalhes aqui .
Filtrar IDs e buckets	É possível solicitar ao serviço de agregação o mesmo bucket com dois IDs de filtragem diferentes em duas execuções de agregação separadas? Em outras palavras, o ID de filtragem pode funcionar como um particionamento suplementar de domínios?	Sim, esse recurso é compatível. Ao realizar uma agregação, apenas as contribuições com um ID de filtragem correspondente à lista nos parâmetros do job serão processadas. O restante vai permanecer disponível para processamento em execuções separadas.
Atribuição multitoque	Pedidos de esclarecimento sobre a implementação da atribuição multitoque (MTA): 1) Há um limite para o número de contribuições se o valor de agregação não exceder 2^16? 2) Há um limite para o número de chaves de agregação exclusivas (buckets) que podem ser armazenadas para um determinado contexto? 3) Como o serviço de agregação processa relatórios de resumo quando cada user agent (navegador) tem uma chave de agregação exclusiva, como é provável no MTA?	1) Implementamos limites de contribuição padrão, mas há opções para que o chamador da API os substitua, conforme explicado aqui. O objetivo dos limites é ajudar os autores de chamadas de API a gerenciar o custo de processamento de relatórios no serviço de agregação. 2) Não há esse limite, embora as adtechs precisem considerar a granularidade das chaves de agregação para melhorar a relação entre sinal e ruído, conforme explicado aqui. 3) Consulte estas orientações, especialmente as orientações sobre sinal para ruído abordadas acima no item 2).

Limitar o rastreamento oculto

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

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso	Solicitação para adicionar Sec-CH-UA-Robot às dicas de cliente do user agent (UA-CH), já que isso permitiria que os servidores identificassem o tráfego automatizado para adaptação, segurança e análise de conteúdo.	Esse é um caso de uso importante que está sendo discutido em outros grupos de padrões (confira aqui para mais detalhes). Recomendamos que as partes interessadas participem enviando feedback. No entanto, achamos que o UA-CH pode não ser a solução adequada, já que os cabeçalhos de solicitação HTTP podem ser facilmente manipulados pelo tráfego automatizado.

Proteção de IP (anteriormente Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Privacidade do endereço IP	Deixar os endereços IP disponíveis para uso pelo Google contradiz as metas de privacidade declaradas. Embora o Google diga que anonimiza os dados com a Proteção de IP, os usuários precisam estar conectados ao Chrome para usar esse recurso. Portanto, o Google ainda descobre as identidades deles.	O login é necessário para fins de proteção contra fraudes e abuso, principalmente para limitar a taxa de acesso aos proxies. Além disso, para proteger a privacidade dos usuários no contexto do requisito de autenticação, nosso design de token é assinado de forma oculta, o que significa que o token emitido durante o login é diferente do token usado durante o proxy. Portanto, os tokens emitidos não podem ser vinculados à identidade do usuário no Google mais tarde. Isso significa que o Google não sabe quem é o usuário quando o tráfego dele é encapsulado no modo de navegação anônima, apesar da exigência de autenticação por motivos de proteção contra fraudes.
Privacidade do endereço IP	O uso de IPs é uma etapa na direção errada. Eles não podem ser excluídos do navegador, como os cookies, e os usuários não têm os mesmos controles de transparência que têm com os cookies. Se os cookies forem descontinuados, o setor vai passar a usar IPs como uma solução alternativa, priorizando a autopreservação em vez da privacidade.	Como plataforma, o Chrome tem como objetivo oferecer aos usuários recursos que melhorem a experiência de navegação na Web. Para os usuários do Chrome que escolhem navegar no modo de navegação anônima, isso significa oferecer proteções aprimoradas contra o rastreamento entre sites, limitando a disponibilidade de informações de endereços IP em contextos de terceiros.
Lista de domínios mascarados	Quais são os critérios de seleção na lista de domínios mascarados (MDL, na sigla em inglês)?	O Chrome desenvolveu critérios para identificar quais domínios devem estar no MDL e, portanto, receber endereços IP mascarados em um contexto de terceiros. O Google fez parceria com o Disconnect.me, um importante líder em privacidade na Internet que também colabora com outros navegadores da Web. O Chrome vai usar o Disconnect.me para identificar domínios que se alinham aos critérios estabelecidos pelo Chrome. Além disso, o Chrome desenvolveu uma metodologia para identificar funções JavaScript amplamente usadas que fornecem saídas consistentes de APIs da Web estáveis e de alta entropia e, portanto, podem ser usadas para criar identificadores probabilísticos de alta entropia. Essas funções são detectadas quando são carregadas em sites em um contexto de terceiros, resultando em uma lista de domínios que veiculam scripts com essas características que se tornam parte do MDL e, portanto, são proxy. O pipeline de detecção que procura esses padrões de uso indevido de API considera todos os domínios, incluindo os próprios domínios do Google.
Prevenção contra fraudes	Feedback sobre os tokens de revelação probabilística (PRTs, na sigla em inglês) de que o atraso de revelação de 24 horas e as taxas de revelação propostos impedem a detecção de fraudes em tempo real. Solicite atrasos mais curtos (1 hora) e taxas mais altas (pelo menos dois dígitos). Outras sugestões incluem ativar taxas diferenciadas com base em indicadores de risco (VPNs, navegadores automatizados) e permitir a exibição segmentada de tokens específicos.	A maioria dos desenvolvedores com quem conversamos envia relatórios de hora em hora aos clientes e atualiza várias listas de bloqueio de IP ao longo do dia. Um período de atraso mais curto permite atualizações mais frequentes e, em menos de uma hora, reativa a medição de IVT nas estatísticas por hora, mas também aumenta a probabilidade de reidentificação dos usuários. Estamos abertos a reduzir os períodos de espera e mudar a taxa de revelação com base em estudos do ecossistema e no feedback das partes interessadas. Clique aqui para enviar mais feedback.
Lista de domínios mascarados	Pergunta sobre a inclusão do domínio no MDL, apesar de não ter um caso de uso de publicidade. A preocupação é que isso possa permitir que a "ponte de IP" crie perfis com base em endereços IP.	Reconhecemos a importância de implementar um processo de contestação para nossa abordagem baseada em listas. As contestações permitem que as empresas afirmem que o domínio no MDL não atende aos critérios de inclusão e deve ser removido, permitindo que o domínio continue recebendo os endereços IP originais dos usuários em um contexto de terceiros no modo de navegação anônima. Agora lançamos o processo de contestação para que os proprietários de domínio tenham tempo suficiente para contestar e receber uma decisão antes do lançamento da Proteção de IP no modo de navegação anônima no Chrome estável. Confira mais detalhes sobre o processo de contestação neste link.
Lista de domínios mascarados	Feedback de que os editores estão investigando as implicações da inclusão dos parceiros no MDL. Eles foram tranquilizados pelas disposições de GeoIP na explicação sobre proteção de IP.	O Chrome reconhece a importância de oferecer suporte a casos de uso com base na localização. O proxy vai atribuir endereços IP que representam a localização aproximada do usuário, incluindo o país. Saiba mais na explicação sobre a geolocalização de IP.
Lista de domínios mascarados	Pergunta sobre a MDL se a segmentação por país ainda está disponível.	O Chrome reconhece a importância de oferecer suporte a casos de uso com base na localização. O proxy vai atribuir endereços IP que representam a localização aproximada do usuário, incluindo o país. Saiba mais na explicação sobre a geolocalização de IP.
Detecção de fraude	Preocupações sobre o impacto da Proteção de IP nos sistemas de detecção de fraudes. Os usuários vão ver IPs de proxy ou um cabeçalho? Os SSPs e DSPs vão ter acesso ao mesmo endereço IP de proxy para um determinado uso? As inconsistências podem afetar a detecção de fraude e o OpenRTB.	Os usuários que navegam no modo de navegação anônima com a Proteção de IP ativada e fazem solicitações para domínios no MDL recebem um endereço IP de proxy com base em um geofeed definido. As organizações podem solicitar que os PRTs sejam transmitidos como um cabeçalho adicional no tráfego de proxy, em que uma pequena amostra de IPs originais pode ser revelada após um período de atraso. Suspeitamos que muitas SSPs vão transmitir o endereço IP do proxy nas solicitações de lances do lado do servidor para os parceiros de demanda, mas não há garantia de que as DSPs vencedoras vão ver o mesmo endereço IP do proxy no momento da impressão.
Detecção de fraude	Perguntas sobre a frequência de atualização do arquivo de geolocalização de IP, o tempo de atualização para detalhes sobre como denunciar comportamentos fraudulentos e PRTs e como a adtech precisa detectar atividades fraudulentas.	A explicação sobre as PRTs está ativa, assim como a lista de endereços IP de proxy e as regiões geográficas mapeadas. Recomendamos que você verifique periodicamente se há atualizações e mudanças nesse arquivo, já que os endereços IP vão mudar com o tempo. O endereço de e-mail público para denunciar abuso será anunciado mais perto do lançamento.
Geolocalização	Solicitação de lista pública de endereços IP usados para proxies.	O arquivo que mapeia endereços IP para locais aproximados para a Proteção de IP está disponível aqui. Esse arquivo é atualizado periodicamente.
Uso do API	Afirmação de que a proteção de IP parece estar ativada por padrão e os usuários não têm a opção de desativar.	A Proteção de IP vai estar disponível para usuários no modo de navegação anônima do Chrome nas plataformas Android e para computador. Os usuários poderão desativar a Proteção de IP. Nas versões do Chrome gerenciadas pela empresa, a Proteção de IP pode ser ativada, mas ela fica desativada por padrão.
Uso do API	Consulta sobre a disponibilidade de uma flag de experimento para ativar e testar a proteção de IP nas versões Beta e Canary do Chrome.	No momento, não temos uma flag de experimento disponível para testar o recurso completo de Proteção de IP. Os experimentos funcionais que estamos realizando se referem apenas ao tráfego de proxy para domínios do Google.
Privacidade do endereço IP	Como as configurações de solicitação de 3PC funcionam quando um navegador muda para o modo de navegação anônima?	Os cookies de terceiros são bloqueados por padrão no modo de navegação anônima.
Modo de navegação anônima	Procurando esclarecimentos sobre se a Proteção de IP funciona no modo de navegação anônima quando o usuário não está conectado ao Chrome.	A Proteção de IP não é ativada se o usuário não tiver feito login no Chrome antes de iniciar o modo de navegação anônima. Isso é feito para evitar fraudes e abusos, principalmente para limitar o acesso a proxies. A Proteção de IP vai usar a autenticação do cliente para limitar a capacidade de usuários de má-fé de aproveitar os proxies para amplificar ataques a serviços no MDL. Portanto, a Proteção de IP só estará disponível para usuários autenticados usando a Conta do Google com a qual eles fizeram login no navegador Chrome antes de abrir uma nova janela anônima.
Modo de navegação anônima	Solicitações para avaliar o impacto da Proteção de IP antes do lançamento, incluindo: (1) Proposta para usar uma flag de estado do navegador ou relatórios agregados da API para quantificar o uso do modo de navegação anônima; (2) Envio de um cabeçalho de Proteção de IP por um período antes de ativar o recurso; e (3) Envio do recurso para uma pequena porcentagem conhecida de tráfego para extrapolação.	Entendemos o interesse do ecossistema em entender e medir a escala e o impacto da proteção de IP. No entanto, o Chrome trabalha para tornar a escolha de um usuário de navegar no modo de navegação anônima particular. O Chrome não expõe um método para detectar usuários navegando de forma anônima e tomou medidas para limitar outros indicadores que podem revelar o modo de navegação do usuário. Estamos considerando maneiras de facilitar esse teste sem afetar a privacidade dos usuários que navegam no modo de navegação anônima e agradecemos o feedback adicional do ecossistema.

Mitigações de rastreio

Tema do feedback	Resumo	Resposta do Chrome
Conformidade	A relutância do Google em autorizar o uso da técnica de mitigação de rastreamento de rejeições (BTM, na sigla em inglês) que está em conformidade com a legislação de proteção de dados não tem base legal e torna o processo de contestação do Sandbox de Privacidade sem sentido.	Como explicamos no nosso relatório de feedback anterior, o status de compliance não tem relação com a aplicação do BTM, e o Google não toma decisões sobre compliance na implementação do BTM. O BTM, assim como outras proteções de privacidade do Chrome, tem como foco aumentar o controle dos usuários sobre se e como os dados deles são compartilhados. O processo de contestações gerenciadas por terceiros mencionado no relatório do segundo e terceiro trimestres da CMA é específico para áreas em que o Google está tomando decisões sobre a inclusão ou exclusão de empresas individuais em listas.
Conformidade	Discussão sobre como os navegadores garantem a conformidade com ações consentidas legalmente no contexto do GDPR, destacando cenários em que os navegadores podem suprimir ações (como redirecionamentos ou configuração de cookies) que os usuários consentiram explicitamente, criando um conflito entre o consentimento legal e as configurações de privacidade do navegador.	O navegador não tem visibilidade sobre a natureza da relação entre um usuário e um site. Além disso, com o comportamento atual do BTM, já existem soluções alternativas para que um usuário dê consentimento explícito para o acompanhamento de rejeições em um determinado site. Mais informações sobre compliance estão disponíveis nas Perguntas frequentes sobre compliance relacionado à privacidade.
Sites de uso duplo	Você quer saber se as transições da WebView ou do app para a Web (Chrome) serão consideradas "sites de uso duplo" no BTM?	O navegador não tem visibilidade sobre se uma cadeia de rejeições começou com uma transição da WebView ou do app. Por isso, a BTM não dá nenhum tratamento especial a esses fluxos. Em vez disso, ele interpreta o fluxo como uma rejeição entre sites, começando em "about:blank", e continua com o comportamento padrão.

Reforçar os limites de privacidade entre sites

Conjuntos de sites relacionados (antes chamados de "conjuntos primários")

Tema do feedback	Resumo	Resposta do Chrome
Uso do API	Preocupações sobre o possível abuso do RWS em conjunto com a Proteção de IP. A exposição de endereços IP a organizações em um conjunto de RWS pode incentivar as organizações a participar de vários conjuntos de RWS para ter acesso a dados portáteis de endereços IP para rastrear usuários anônimos.	Os requisitos definidos para sites associados, sites de serviço e conjuntos como um todo, aplicados por validações automáticas, reduzem o incentivo a tentar unir vários conjuntos. A junção da atividade do usuário em vários conjuntos por endereços IP exigiria a inclusão de um domínio MDL em um conjunto, o que requer coordenação entre o proprietário do conjunto e o proprietário do domínio. Esse mesmo risco se aplica a sites únicos (ou seja, sem RWS envolvidos) que coordenam com domínios de MDL. Respondemos a essa pergunta com mais detalhes aqui.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
Publicidade nativa	Feedback de que os frames cercados, como projetados atualmente, são incompatíveis com o modelo de negócios de publicidade nativa, que exige que os anúncios se adaptem com flexibilidade ao conteúdo ao redor.	Continuamos avaliando as necessidades do ecossistema e a oferta atual de Frames limitados. De qualquer forma, conforme declarado anteriormente, os frames cercados serão obrigatórios a partir de 2026.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Bug de API	Relatório que o Chrome registra um erro quando o mecanismo de alocação de recursos da API Shared Storage impede a execução da operação selectURL, mesmo que esse seja o comportamento esperado. Peça para o Chrome rebaixar o nível de registro de erro para aviso ou informação, já que o erro não pode ser usado pelo autor da chamada.	A mudança foi implementada e incluída no Chrome M134, disponível desde 4 de março de 2025.

CHIPS

Tema do feedback	Resumo	Resposta do Chrome
Documentação da API	É necessário esclarecer as proteções de segurança oferecidas pelos cookies particionados em comparação com os cookies SameSite=Lax/Strict. Sugestão de que a documentação deve declarar explicitamente que os cookies particionados não oferecem o mesmo nível de proteção contra ataques XSS e CSRF que os cookies SameSite=Lax/Strict.	Vamos atualizar a explicação e a especificação para esclarecer a semântica e as proteções oferecidas pelos cookies particionados.

FedCM

Tema do feedback	Resumo	Resposta do Chrome
Interface e segurança	Feedback de que a interface do FedCM é muito semelhante ao login anterior de um toque do Google, é difícil quantificar o desempenho do FedCM devido à falta de rastreamento passivo da apresentação e uma recomendação para uma linguagem de documentação mais forte em relação ao PKCE.	Estamos interagindo com as partes interessadas para resolver o problema. As áreas de discussão em andamento incluem maneiras de fornecer métricas melhores aos provedores de identidade para que eles possam acompanhar o desempenho da FedCM e possíveis melhorias para abordar novos casos de uso da FedCM em relação a casos de uso de assinatura.
Uso do API	Quando um usuário atualiza a página e chama navigator.credentials.get para fazer login, uma janela pop-up aparece, exigindo que o usuário clique para continuar, o que causa um atraso que afeta a experiência do usuário. As partes confiáveis (RPs) podem armazenar em cache o token retornado por navigator.credentials.get para melhorar a experiência do usuário?	Os RPs podem usar os próprios cookies para armazenar o token. Os RPs podem verificar os próprios cookies para determinar se um usuário fez login antes de invocar navigator.credentials.get. Discutimos isso em mais detalhes aqui.
Seleção de vários provedores de identidade	Como o navegador mostraria as opções de login para vários provedores de identidade (IdPs) na FedCM?	A documentação para desenvolvedores tem informações sobre como vários provedores de identidade seriam exibidos. As partes interessadas podem testar essa funcionalidade ativando a flag fedcm-multi-idp em chrome://flags.
Navegadores e provedores de identidade	É possível que um navegador, como o Chrome, atue como um IdP? Os navegadores podem usar os dados armazenados da conta e do perfil como uma fonte confiável de autenticação.	Como os navegadores podem ser modificados (por exemplo, com extensões), não é possível confiar em nenhuma reivindicação de verificação de e-mail feita diretamente pelo navegador sem uma verificação adicional baseada em servidor. Portanto, uma solução puramente baseada no cliente não é recomendada. Discutimos esse problema em mais detalhes aqui.
Especificações da API	Discussão sobre se o parâmetro do algoritmo IdentityCredential.disconnect() precisa ser obrigatório ou opcional.	Isso já foi corrigido Veja mais detalhes aqui.
Segurança da API	Preocupações com vazamento de tokens no processo de login do FedCM se um RP tiver uma vulnerabilidade XSS. Um invasor pode executar navigator.credentials.get em código malicioso para conseguir o token.	O FedCM não cria novos riscos de XSS. Esses riscos são inerentes aos aplicativos da Web e aos protocolos de autenticação atuais. Para reduzir esses riscos, os RPs precisam verificar a declaração de aud nos tokens de ID e aceitar apenas as declarações emitidas na própria origem. Como discutido aqui, existem práticas recomendadas amplamente estabelecidas para proteger essa troca de tokens que já existem e estão disponíveis para uso com o FedCM. Além disso, a API Storage Access pode ser usada com o FedCM, e as chamadas da API Storage Access são concedidas automaticamente quando há uma chamada FedCM anterior. Isso ativa o fluxo de redirecionamento incorporado discutido no problema do GitHub.
Especificações da API	O client_metadata_endpoint é um campo obrigatório na resposta do endpoint de configuração para o FedCM. Um objeto vazio é uma resposta válida, e o Chromium ignora silenciosamente uma resposta 404, sugerindo que o endpoint é tratado como opcional na prática.	Concordamos que a especificação pode ser alterada para refletir isso e tornar o client_metadata_endpoint um campo opcional.
Uso do API	Preocupações sobre a dificuldade de testar implementações do FedCM devido a interfaces de usuário controladas pelo navegador que não são acessíveis pelo DOM.	Oferecemos suporte às APIs de automação do navegador para testes de regressão, que podem resolver essas questões. Essas APIs estão documentadas aqui.
Especificações da API	O parâmetro "login_url", que é uma parte obrigatória da resposta do endpoint de configuração, não foi documentado na seção 3.2 da especificação.	Enviamos uma atualização à documentação para incluir o parâmetro "login_url" na seção 3.2.
Especificação da API	Preocupação com um possível vetor de rastreamento no FedCM. Um IdP pode inserir IDs como parâmetros de caminho nos endpoints especificados na resposta do endpoint de configuração (accounts_endpoint, client_metadata_endpoint) e usar esses IDs para correlacionar as solicitações de metadados da conta e do cliente.	Embora não tenhamos evidências de que os IdPs estão inserindo IDs nesses endpoints, estamos considerando medidas para resolver esse problema aqui.

Combater spam e fraudes

API Private State Tokens (e outras APIs)