Relatório de feedback: 2o e 3o trimestres de 2024

Relatório trimestral para o 2º e 3º trimestres de 2024, que resume o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.

Como parte dos compromissos com o CMA, o Google concordou em apresentar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas nas propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Em 22 de julho de 2024, o Google anunciou que não iria descontinuar os cookies de terceiros (3PCs) no Chrome e, em vez disso, propôs uma abordagem atualizada para aumentar a escolha do usuário. Portanto, de acordo com o acordo da CMA, o Google não enviou um relatório público do segundo trimestre de 2024 à CMA para que tivesse tempo suficiente para que o Google e a CMA considerassem as implicações do anúncio do Google.

Esses relatórios de resumo de feedback do Sandbox de privacidade são gerados pela agregação do feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral do feedback, incluindo, entre outros: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com as partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe com prazer o feedback recebido do ecossistema e está procurando ativamente maneiras de integrar o aprendizado às decisões de design.

Os temas de feedback são classificados pela prevalência em cada API. Para isso, agregamos a quantidade de feedbacks que a equipe do Chrome recebeu sobre um determinado tema e organizamos em ordem decrescente de quantidade. Os temas comuns de feedback foram identificados analisando os tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que surgiram nas equipes internas do Google e em formulários públicos.

Mais especificamente, as atas das reuniões padrão da Web foram analisadas e, para feedback direto, os registros do Google de reuniões individuais das partes interessadas, e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público foram considerados. O Google então coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas emergentes em relação a cada API.

As explicações das respostas do Chrome ao feedback foram desenvolvidas com base nas perguntas frequentes publicadas, nas respostas reais feitas a questões levantadas pelas partes interessadas e na determinação de uma posição especificamente para os fins deste exercício de relatórios públicos. Refletindo o foco atual de desenvolvimento e teste, foram recebidas perguntas e feedback específicos em relação às APIs Topics, Protected Audience e Attribution Reporting.

O feedback recebido após o fim do período de geração de relatórios atual pode ainda não ter uma resposta considerada do Chrome.

Glossário de acrônimos

ARA

API Attribution Reporting

CHIPS

Cookies com estado particionado independente

DSP

Plataforma de demanda

FedCM

Gerenciamento de credenciais federadas

QPS

Conjuntos próprios

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 PAT

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

TEE

Ambiente de execução confiável

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
Descontinuação dos cookies de terceiros (3PCD)	Quais são os planos do Google para a 3PCD e avaliamos os efeitos de longo prazo no setor de publicidade digital?	Estamos propondo uma abordagem atualizada que aprimora a escolha do usuário. Como definido aqui, em vez de descontinuar os cookies de terceiros, vamos lançar uma nova experiência no Chrome que permite que as pessoas façam uma escolha informada que se aplica a toda a navegação na Web e que pode ser ajustada a qualquer momento. Estamos debatendo esse novo caminho com os reguladores e vamos entrar em contato com o setor antes do lançamento.
Escolha do usuário	O anúncio da escolha do usuário afetou o interesse do ecossistema em adotar as soluções do Sandbox de privacidade. Há feedbacks variados sobre o anúncio da escolha do usuário, incluindo solicitações de recursos, como recursos de monitoramento.	Com a abordagem atualizada que aumenta a escolha do usuário, ainda é importante que os desenvolvedores tenham alternativas que melhoram a privacidade aos identificadores entre sites. Ainda não temos detalhes para compartilhar sobre como será a nova experiência, mas esperamos um aumento significativo do tráfego sem cookies no Chrome. Isso significa que as APIs do Sandbox de privacidade continuam sendo essenciais para as empresas. Vamos continuar investindo nas tecnologias do Sandbox de privacidade para melhorar ainda mais a privacidade e a utilidade.
Interface de escolha do usuário	Perguntas sobre o cronograma dos recursos de desativação/consentimento, o tipo de opção do usuário que está sendo considerada e como a interface vai afetar os ambientes de teste automatizado.	No momento, não temos atualizações sobre o cronograma. Quando decidimos não seguir a 3PCD, queríamos atualizar o ecossistema o mais rápido possível. Vamos compartilhar uma atualização sobre o cronograma de escolha do usuário assim que tivermos uma.
Testes do Chrome	Solicitação de disponibilidade contínua de rótulos de teste facilitados pelo Chrome para medir a adoção no mercado e o impacto econômico da 3PCD após o primeiro semestre de 2024.	Sabemos que os testadores vão querer continuar usando grupos de navegadores marcados para testes e coordenação, mesmo que os testes facilitados pelo Chrome no primeiro semestre de 2024 tenham chegado ao fim. Estamos avaliando as próximas etapas para os rótulos com base no anúncio sobre a escolha do usuário. Enquanto isso, a equipe do Chrome publicou uma intenção de estender o suporte a grupos de navegadores rotulados até o marco 132 do Chrome, que vai até janeiro de 2025.
Sandbox de privacidade no Android	O Sandbox de privacidade no Android e no Chrome estão inextricavelmente ligados, e não podemos avaliar adequadamente o Sandbox de privacidade sem o Android. A jornada típica do cliente, que envolve aspectos multitoque e entre dispositivos, é fundamental para o Sandbox de privacidade no Chrome e no Android.	O Sandbox de privacidade no Android não está no escopo dos compromissos do Google com a CMA. Se o feedback for específico sobre os cronogramas e o lançamento do Android, não temos atualizações para compartilhar no momento, além de continuarmos a fazer progressos no Android, que é tratado como um fluxo de trabalho independente para melhorar a privacidade. Como mencionamos anteriormente, a disponibilidade das APIs do Sandbox de privacidade no Android também será determinada pela taxa de atualização dos dispositivos, que não está sob o controle do Google.
Modo B: tráfego limitado	O tráfego do leilão de anúncios disponível no modo B foi menor do que o esperado.	Há vários motivos pelos quais os volumes de leilão da API Protected Audience (API PA) podem ser menores do que o esperado. Por exemplo: - As empresas que sabemos que integraram a API PA incluíram apenas formatos de banner. - As plataformas de venda nem sempre iniciam um leilão. - Um navegador pode não ter grupos de interesse (IGs). - Pode não haver lances. No entanto, não sabemos de ninguém que tenha tentado testar a API PA e não recebeu tráfego.
Visibilidade da interrupção do serviço	Visibilidade sobre interrupções e problemas que afetam as APIs do Sandbox de privacidade.	Há uma página de status pública para as APIs do Sandbox de privacidade que têm serviços fora do navegador. A equipe do Chrome dá a maior prioridade à confiabilidade da nossa plataforma e de todas as APIs essenciais usadas pelos principais sites e serviços da Web, incluindo as tecnologias do Sandbox de privacidade. Até agora, houve apenas uma interrupção. Ele estava relacionado a uma configuração temporária para testes de 1%. Em breve, a configuração experimental envolvida nessa interrupção não será mais necessária. Portanto, temos certeza de que esse problema não vai ocorrer quando as APIs forem ativadas normalmente no Chrome.
Estudo do gráfico de cookies	Qual é a perspectiva do Chrome sobre o método CookieGraph, conforme descrito neste artigo no contexto do Sandbox de privacidade?	O artigo levanta alguns pontos interessantes sobre a detecção e a prevalência de cookies primários definidos por domínios diferentes do visitado pelo usuário. Como o documento destaca, esses cookies são extremamente úteis para reunir análises e informações sobre como os usuários interagem com um site. Esses dados são essenciais para que os desenvolvedores ofereçam uma melhor experiência de navegação aos usuários. O principal argumento do artigo é falho, porque considera os cookies de 1ª parte como um vetor de rastreamento entre sites. No entanto, isso só é verdadeiro sob as suposições muito agressivas descritas no artigo: Os usuários estão dispostos a compartilhar os PIIs com o site. Os dispositivos têm uma impressão digital estável que pode ser usada para rastrear um usuário em vários sites. Esses são vetores de reidentificação que podem ser explorados sem o uso de cookies próprios (por exemplo, pelo compartilhamento de dados no servidor) e precisam ser abordados separadamente do nosso esforço atual, que é focado em mecanismos de rastreamento com base no estado, como cookies de terceiros. Por fim, queremos apontar que o artigo equipara os cookies de análise e publicidade aos cookies de rastreamento e os cookies estritamente necessários como cookies não de rastreamento, o que pode não ser necessariamente o caso. Na verdade, as análises de 1ª parte ou os serviços de fornecedores particionados por site, como widgets de localizador de lojas, widgets de chat ou cookies de balanceador de carga, geralmente são limitados a apenas um domínio. Por outro lado, alguns cookies estritamente necessários podem ser de rastreamento entre sites para fins de combate à fraude.
Mudanças na UX	As mudanças na UX do Chrome 112 que colocam os controles de cookies de 1P na seção "Dados do site no dispositivo" das configurações do Chrome podem dificultar o bloqueio de todos os cookies.	Essa mudança foi feita como parte de um esforço para separar e elevar os controles de 3PCs (ou armazenamento não particionado) de todos os outros tipos de dados do site. Os controles de cookies de terceiros são elevados no painel "Privacidade e segurança". Já os controles de cookies primários e todos os outros tipos de dados do site, que geralmente dependem de funcionalidades críticas do site, são agrupados em "Dados do site no dispositivo". Continuaremos monitorando os feedbacks sobre esse assunto, mas acreditamos que a separação atual atinge um bom equilíbrio entre a descoberta de controles de privacidade significativos e a preservação de uma experiência de navegação funcional.
Faturamento e pagamento	As cobranças e os pagamentos não estão sendo totalmente testados, porque os testadores estão mais focados em testar outras áreas das APIs do Sandbox de privacidade.	Quando e o que os desenvolvedores e as empresas escolhem testar é uma escolha deles. As APIs estão em disponibilidade geral para testes desde setembro de 2023.
Teste	Nem todo o tráfego experimental que as DSPs recebem das SSPs é rotulado. Algumas DSPs informaram que a porcentagem de impressões experimentais não identificadas pode ser diferente entre os grupos de tratamento e de controle.	O Chrome não pode controlar se as empresas encaminham rótulos em solicitações de lances. Fornecemos um método para receber um rótulo do navegador. Cabe ao ecossistema transmitir rótulos aos parceiros se eles não conseguirem ler esses rótulos diretamente.
3PCD na WebView do Android	Solicitação de orientação sobre como ativar a flag "Test Third Party Cookie Phaseout" na WebView do Android para testar a descontinuação.	Os protocolos 3PC são bloqueados por padrão no Android WebView.
Privacidade diferencial para reduzir os riscos no treinamento de modelos	Por que a privacidade diferencial é usada no treinamento de modelos?	A privacidade diferencial, combinada com ambientes de execução confiável (TEEs, na sigla em inglês), é essencial no treinamento de modelos para evitar o vazamento de dados e proteger informações sensíveis contra ameaças. Essa abordagem garante que os pesos do modelo não revelem dados de usuários individuais.

Inscrição e certificação

Tema do feedback	Resumo	Resposta do Chrome
Registro	Solicitação de esclarecimento sobre como o registro de atestado funciona entre a origem registrada e a origem da adtech com o subdomínio www.	A adtech só precisa ser integrada ao https://example.com. Quando o usuário coloca o atestado em https://example.com/.well-known/privacy-sandbox-attestations.json, o https://www.example.com é coberto, já que é um subdomínio.
Especificações da API	Sugestão de adicionar um esquema JSON para o arquivo de atestado ao repositório.	Estamos avaliando essa sugestão e agradecemos o feedback aqui.

Mostrar conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Ponderação de temas	O mais importante na API Topics é a raridade de um determinado indicador. O design atual precisa evoluir para permitir a adição de um valor de peso ao lado de cada tema observado. O peso seria o peso relativo de um determinado tópico para um navegador em comparação com todos os navegadores que usam o tópico.	Gostaríamos de entender melhor por que a raridade de um indicador é o indicador mais importante. Agradecemos o feedback do ecossistema sobre a utilidade desse caso de uso aqui.
Confiabilidade dos tópicos	O Google precisa oferecer garantias mais fortes sobre a confiabilidade dos Tópicos ao longo do tempo.	As mudanças nas nossas APIs vão continuar sendo feitas com base no feedback do ecossistema e serão discutidas publicamente antes das mudanças. Nossa proposta de uma estrutura de governança revisada forneceria garantias adicionais.
Classificador	Os sites dos editores geralmente são classificados incorretamente ou recebem temas muito genéricos para servir a propósitos significativos.	Conforme definido em nosso explicador sobre a classificação de tópicos, os sites são classificados por uma combinação de uma lista de substituição feita por humanos, que contém os sites mais populares, e um modelo de aprendizado de máquina no dispositivo. O Chrome continua avaliando opções para que os sites contribuam com a classificação de temas. Quaisquer melhorias nos utilitários precisam ser avaliadas em relação aos riscos de privacidade e de abuso. Por exemplo, alguns dos riscos incluem: - sites que usam autoclassificação como um método para codificar significados diferentes (e potencialmente sensíveis) em tópicos; e - sites que atacam tópicos para reduzir a utilidade deles para outras pessoas (por exemplo, spam nos tópicos do usuário com informações sem sentido). O público pode inspecionar esses componentes, com ferramentas disponíveis em chrome://topics-internals ou esta colab. Com a realização de testes, esperamos que a classificação melhore com o tempo, e aceitamos feedback de exemplos de sites que possam ter sido categorizados incorretamente.
Pergunta sobre a API	Preocupações de que a API Topics oferece benefícios persistentes e anticompetitivos para SSPs que monetizam conteúdo inadequado.	Assim como nos protocolos 3PC, o navegador não depende de quem retorna tópicos, desde que a entidade esteja registrada e atestada.
(Também informado nos trimestres anteriores) Utilidade para diferentes tipos de partes interessadas	Como o classificador de temas atualmente usa apenas o nome do host da página para definir os temas correspondentes, sites grandes com conteúdo diversificado estão contribuindo com temas genéricos, enquanto sites pequenos contribuem com temas de nicho com mais valor publicitário.	Nossa resposta é semelhante a dos trimestres anteriores: Assim como nos 3PCs, há uma diferença no valor das informações enviadas por diferentes sites. Os sites de nicho têm uma contribuição de valor inconsistente: nem todos têm um contexto 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 de no nível do site. No entanto, há várias questões importantes de privacidade e segurança com essa classificação.
Classificador	Sites menores geralmente recebem uma classificação imprecisa ou nenhuma classificação, o que impede a participação na troca de valor.	Em relação aos supostos danos, os sites que são potencialmente classificados incorretamente não são mais prejudicados do que outros sites, já que as informações contextuais de um site sempre estarão disponíveis para leilões, o que forneceria informações comparáveis ao tema correto, mesmo no caso de classificação incorreta. Os temas geralmente são usados para coletar informações de publicidade potencialmente úteis de sites externos, em vez dos próprios sites.
Versão da taxonomia	Como podemos acessar a versão da taxonomia para garantir a compatibilidade com versões anteriores?	A versão da taxonomia faz parte do cabeçalho da solicitação enviado com uma solicitação de busca ativada por temas. Por exemplo, se o cabeçalho for "(1 2);v=chrome.1:2:5, ();p=P000000000", a versão será chrome.1:1:2. Em que chrome.1 é a versão da configuração, 2 é a versão da taxonomia e 5 é a versão do modelo. Isso está descrito na especificação e também foi adicionado à explicação.
Dados de temas	Pedido de esclarecimento sobre como os dados do Google Trends são atualizados.	A atualização da taxonomia não foi especificada. Isso oferece aos fornecedores de navegadores flexibilidade na implementação. Dito isso, aqui estão as heurísticas da atualização da taxonomia do Chrome da V1 para a V2: - Uma única árvore de taxonomia é mantida para os tópicos da V1 e da V2. : o mesmo ID do tópico representa o mesmo significado. - A árvore só cresce, adicionando novos tópicos ou conexões, nunca diminuindo. - No entanto, alguns tópicos ou links podem estar "inativos" em uma versão, o que pode dar a impressão de exclusão ou reorganização. Exemplos: - "Pickup Trucks" agora tem "Trucks, Vans & SUVs" como pai intermediário. - "Estudo de língua estrangeira" agora tem "Educação" como um segundo pai, e o pai original "Referência" fica inativo. Impacto dos temas "inativos": esses temas não serão usados para novas classificações. No entanto, eles ainda são considerados ao aplicar bloqueios de usuários: se um usuário bloqueou um tema na V1, os temas secundários vão permanecer bloqueados na V2 (mesmo que o tema secundário apareça sob um tema diferente na V2).
Classificador	Procuramos entender as causas e as opções corretivas disponíveis em relação às classificações incorretas.	Primeiro, gostaríamos de esclarecer que a determinação dos temas de um site pelo Chrome é apenas para ser usada como entrada no algoritmo de temas para determinar os interesses de um usuário para fins de publicidade. Ele não foi desenvolvido para outros fins de classificação mais gerais. Nosso interesse é a precisão geral do modelo de classificação, e tentamos melhorar a precisão/recall sempre que possível, mas no nível global, e não no nível de classificação individual do site. Isso acontece porque a classificação incorreta, quando ocorre, não prejudica o site individual que foi classificado incorretamente, mas reduz a qualidade do indicador de tópicos ao selecionar um anúncio em outros sites. Ao selecionar anúncios no site classificado incorretamente, os tópicos reais do site já são conhecidos por ele e podem ser usados como entrada para consultas de publicidade. Envie seu feedback aqui.
Teste de API	É possível testar a API Topics e, em geral, as APIs do Sandbox de privacidade com o Chromium?	A API Topics não é enviada com o Chromium, mas com o Chrome.
Autor da chamada da API Topics	Pedido para melhorar o valor agregado dos tópicos que usam serviços de TEE para adtechs, de modo a suportar o custo da análise avançada de acordo com a privacidade.	Respondemos a um feedback semelhante aqui. Consideramos a frequência inversa e, depois de modelar a frequência inversa, descobrimos que ela não se correlacionava bem com o valor do tópico de acordo com o valor fornecido por compradores e vendedores. Envie seu feedback aqui.
Especificações da API	A configuração de coorte de interesse do navegador pode bloquear a API Topics?	Respondemos a esse feedback aqui. A API Topics é uma evolução do FLoC e respeita a política de permissões do FLoC. Conforme definido na explicação: "Observação: a Permissions-Policy: interest-cohort=() antiga do FLoC também impede o cálculo de temas."
Classificação de tópicos	Ao receber os "5 principais tópicos", a frequência das visitas ao site é contabilizada com base em cada autor da chamada qualificado ou sempre com base em todo o histórico de visitas do navegador? Além disso, os temas são classificados separadamente para cada autor da chamada?	Ele é baseado na frequência de um subconjunto de históricos de navegação. Uma entrada do histórico de navegação (uma página) só pode participar se tiver pelo menos um autor de chamada da API Topics. Para mais detalhes sobre o armazenamento do histórico de tópicos, clique aqui. Como informado no comunicado sobre as melhorias na API Topics, a classificação depende da frequência e também de um nível de prioridade binária. Confira mais detalhes neste link e neste link. No entanto, ele não depende da frequência dos autores de chamadas. Isso não significa que todos os autores da chamada vão receber os cinco principais tópicos na próxima época. Conforme definido na explicação, "Somente os autores de chamadas que observaram o usuário visitar um site sobre o tema em questão nas últimas três semanas vão poder receber o tema". O navegador precisa rastrear quais autores de chamadas observaram os cinco principais tópicos (correspondentes aos cinco principais tópicos com domínios de autor de chamada na especificação). Envie seu feedback sobre o problema aqui.

API Protected Audience (antes conhecida como FLEDGE)

Tema do feedback	Resumo	Resposta do Chrome
(Também informado em trimestres anteriores) Custos	É mais caro executar TEEs em nuvens públicas em vez de data centers de adtechs locais?	Nosso modelo de segurança de TEE atual se beneficia das práticas de implementações de nuvem pública. Saiba mais na explicação sobre os requisitos de TEE de nuvem pública (em inglês). Por exemplo, os TEEs atuais baseados em hardware não protegem contra todos os ataques físicos. Nossos provedores de nuvem pública, AWS e GCP, criaram e implementaram mitigações para riscos de acesso físico, inclusive de funcionários. Embora algumas adtechs tenham mencionado que a execução de serviços em nuvem é mais cara do que os data centers de adtechs locais, outras adtechs são executadas em nuvens públicas, seja por custo ou outros benefícios. Continuamos avaliando opções para expandir nosso suporte a TEE, inclusive fora de nuvens públicas. Como parte disso, estamos pesquisando data centers locais e interagindo com o ecossistema para encontrar soluções que ofereçam esse suporte. No estágio atual da pesquisa, não podemos garantir que isso resultará em uma solução viável para o ecossistema.
API PA e Google Ad Manager (GAM)	O GAM não consegue alcançar um resultado justo no mercado. O GAM não veicula anúncios em tempo hábil, informa quantos anúncios foi veiculado usando a API PA e não oferece configuração de qual método vai selecionar para veicular um anúncio, por exemplo, desativando a API PA para determinados slots.	Resposta do Google Ad Manager: O GAM trabalha e vai continuar trabalhando para otimizar a latência ao veicular anúncios pela API PA, de modo que o ganho de receita extra do editor com a demanda da API PA supere os custos incorridos devido à latência adicional do leilão da API PA. Nossos testes iniciais indicam que os editores têm um benefício na receita líquida com a API PA no tráfego sem cookies de terceiros. Isso indica que a demanda extra da API PA supera eventuais custos em função da latência. Confira mais detalhes sobre nossa abordagem nas Perguntas frequentes. Além disso, o GAM oferece relatórios sobre anúncios veiculados pela API PA. Isso inclui anúncios veiculados quando o GAM é um vendedor de componentes e anúncios veiculados por outros vendedores de componentes quando o GAM é um vendedor de nível superior. Confira mais detalhes sobre como fazer denúncias na Central de Ajuda. Por fim, o GAM permite que os editores ativem ou desativem o uso da API PA no tráfego por meio de um controle na interface. Consulte nossa Central de Ajuda para mais detalhes. Estamos abertos a feedbacks sobre outros controles que os editores podem querer e vamos priorizar as solicitações de recursos de acordo com nosso processo padrão de priorização de recursos.
API PA e GAM/AdX	Parece que o Google assumiu uma posição de simplesmente não comprar impressões de API da PA para as quais o GAM não toma a decisão final de venda, assim como o Google AdWords só faz compras internas. Isso parece um abuso da posição de mercado, já que o GAM/AdX pode enviar uma configuração de leilão de componentes para um vendedor de nível superior alternativo, como qualquer outra troca.	Resposta do gerente da plataforma do Google Ads: Essa não é a posição do Google. As plataformas de compra do Google (Google Ads e DV360) compram impressões de trocas que não são do Google. Isso vale para impressões da API PA e de outras APIs.
Resposta do mercado	As preocupações da Mozilla: A API Protected Audience do Google protege os anunciantes (e o Google) mais do que você.	Agradecemos a avaliação do Mozilla e continuaremos a interagir com os comentários do Mozilla em fóruns públicos de padrões. Um dos temas da avaliação é que a implementação atual da API PA ainda não aplica todas as proteções planejadas. Nossa abordagem de lançamento da API PA buscou encontrar o equilíbrio certo entre incentivar a adoção e implementar proteções de privacidade assim que possível. Como parte disso, estabelecemos um cronograma para impor restrições de privacidade ao longo do tempo, a fim de facilitar a integração com as APIs e ter tempo para coletar mais feedback que possamos incorporar às proteções futuras (por exemplo, recursos VAST em frames cercados). Também agradecemos as comunicações mais recentes da Mozilla sobre a própria abordagem em relação à privacidade e à publicidade digital: "Uma Internet livre e aberta não deve ser feita às custas da privacidade" e "Melhoria da publicidade on-line com produto e infraestrutura".
(Também informado em trimestres anteriores) Resultados do leilão	Solicitar que um único leilão retorne vários URLs de renderização com a pontuação correspondente, facilitando a eliminação de duplicação e a prevenção de problemas de UX e latência na publicidade nativa.	Nossa resposta é semelhante aos trimestres anteriores: Consideramos compartilhar vários renderURLs e a pontuação deles de um único leilão da API PA, mas não implementamos devido a questões de privacidade. Entendemos o desejo de evitar a exibição do mesmo anúncio várias vezes para um usuário em uma única página e estamos avaliando essa solicitação. Agradecemos o feedback do ecossistema aqui sobre o suporte adicional necessário na API PA para oferecer suporte ideal ao caso de uso de publicidade nativa.
Desempenho	Preocupações com a latência que afeta a API PA.	Recebemos preocupações sobre a latência e, por isso, desenvolvemos vários recursos na API PA que permitem que as SSPs definam limites na latência do DSP e façam melhorias que podem diminuir a latência. Recentemente, atualizamos nosso guia de práticas recomendadas sobre latência, que inclui mais informações sobre como aproveitar esses recursos. Também estamos desenvolvendo novas melhorias de latência, algumas delas podem ser conferidas aqui.
Vendedores de nível superior	O Google precisa permitir que os editores escolham vendedores de leilões de API PA de nível superior alternativos.	A API PA independe de quem inicia um leilão nos designs de um único vendedor ou de vários vendedores. As escolhas de cada empresa em relação à forma como apoiarão os leilões de API da PA são próprias.
(Também informado em trimestres anteriores) Segmentação negativa	Solicitar uma solução para um caso de uso em que um anunciante não quer veicular anúncios para um determinado público-alvo.	Oferecemos suporte à segmentação negativa do Instagram com lances adicionais (contextuais), o que resolve as necessidades em que um anunciante não quer veicular anúncios para um determinado público-alvo. Confira os detalhes em este artigo e neste problema do GitHub. Também estamos estudando soluções para oferecer suporte à segmentação negativa do IG para lances da API PA. Agradecemos mais feedback aqui.
(Também informado em trimestres anteriores) Publicidade nativa	Solicitação de suporte a frame limitado para publicidade nativa.	Estamos considerando oferecer suporte a esse caso de uso e discutindo possíveis soluções alternativas e soluções aqui.
WebView	Buscando esclarecimentos sobre o cenário em que o IG entrou no Chrome não estava disponível para o leilão realizado na WebView.	Queremos oferecer suporte a esses casos de uso assim que houver infraestrutura de privacidade suficiente disponível. Não temos mais anúncios no momento, mas aceitamos mais feedback aqui.
IGs negativos	Pedido para que o processamento de updateURL ofereça suporte a IGs negativos pelo recurso de cabeçalho nascente.	Estamos avaliando esse pedido e aceitamos mais feedback aqui.
Filtragem de diversidade	Peça orientação sobre como implementar a filtragem de diversidade ao veicular publicidade nativa na API PA com vários vendedores e vários leilões.	Estamos discutindo essa solicitação aqui e agradecemos seu feedback.
(Também informado nos trimestres anteriores) Filtros de bloqueio	Solicitação de orientação sobre como aplicar as regras de "bloqueio do editor" (filtros) ao veicular publicidade nativa na API PA com vários vendedores.	Compartilhamos orientações aqui e agradecemos seu feedback.
Restrições	Solicitar a permissão de restrições no nível do domínio, e não do subdomínio.	As restrições no nível do subdomínio ou da origem seguem o modelo de segurança básico da Web, que é nosso design padrão. Discutimos isso com mais detalhes aqui e aqui.
Lances confiáveis	Solicitação de dicas de user agent e de clientes relacionados em solicitações de indicadores de lances confiáveis.	Estamos rastreando essa solicitação de recurso e queremos receber mais feedback aqui.
(Também informado em trimestres anteriores) Vários IGs	Use vários IGs no mesmo lance.	Isso não é compatível com a API PA no momento, porque resultaria em uma mudança no modelo de privacidade. Acesse este link para mais informações.
(Também informado em trimestres anteriores) Performance	Transferir mais lógica para o cliente pode prejudicar a performance da página e a UX, o que pode prejudicar as pontuações de SEO do site.	Estamos discutindo esse problema e queremos receber mais feedback aqui.
Dinâmicas do leilão	A API PA reduz as informações sobre a dinâmica do leilão (por exemplo, quem participa, quem ganha cada componente leiloado etc.), o que reduz os editores de rastreabilidade e dificulta saber se as transações estão sendo mantidas.	Propomos uma solução para o rastreamento de transações aqui. Planejamos modificar alguns campos atuais e criar alguns novos no objeto IG para armazenar DealID e SeatID e permitir que eles sejam propagados de generateBid para scoreAd ou saída por meio de relatórios no nível do evento. Isso deve fornecer o suporte adequado para o caso de uso da oferta. Agradecemos o feedback sobre outros metadados que as adtechs consideram essenciais para a dinâmica do leilão e para manter essa rastreabilidade para os editores. Incentivamos as adtechs a fornecer exemplos específicos dos metadados a que se referem e de qual parte para qual parte eles precisam fluir.
GAM	Preocupações com a exigência de usar o GAM como servidor de anúncios do editor para acessar a demanda do AdX.	Resposta do Google Ad Manager: O GAM não exige que os editores usem a funcionalidade do servidor de anúncios para acessar a funcionalidade da troca.
(Também informado em trimestres anteriores) Leilão de componentes	Os vencedores do leilão do componente da API da PA vão ficar visíveis para o GAM, o que levanta preocupações sobre o acesso desigual à informação.	Nossa resposta permanece a mesma dos trimestres anteriores: 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 em nossos compromissos com a Autoridade de Concorrência da França. 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. Na verdade, gostaríamos de mudanças na API PA que permitam que os vendedores de componentes especifiquem as configurações de leilão de componentes de uma forma ofuscada do vendedor de nível superior."
GAM	O GAM vai solicitar a participação na receita pela execução/geração de relatórios de leilões de nível superior se o GAM não tiver participado da criação do IG ou do leilão de componentes da API PA?	Resposta do Google Ad Manager: Quando os editores escolhem usar o GAM como servidor de anúncios, ele executa o leilão de nível superior e cobra uma taxa de veiculação de anúncios pela funcionalidade do servidor de anúncios (a mesma taxa de veiculação de anúncios que se aplica fora dos leilões da API PA). No entanto, se o anúncio vencedor vier de um vendedor de componentes que não seja do GAM, ou seja, o GAM não participou da criação do IG nem do leilão de componentes da API PA, o GAM não vai gerenciar o faturamento nem cobrar uma porcentagem da taxa de mídia.
Sensibilidade ao clique	O registro dos eventos de clique está sujeito à mesma privacidade diferencial?	No momento, não há planos de que esse recurso esteja sujeito às restrições do "k-anonimato", porque a "contagem de cliques" só estará disponível como um browserSignal na função generateBid(). Ela não está disponível como um novo atributo nos relatórios de eventos.
Desempenho	Altos custos de saída devido à resposta incondicional a solicitações de lance contextual.	Não podemos fornecer informações diretamente sobre quais DSPs têm IGs devido a questões de privacidade. No entanto, estamos buscando soluções alternativas que podem fornecer insights e preservar a privacidade.
Anúncios nativos e out-stream	Solicitação de atualizações sobre a perspectiva do Chrome em relação a anúncios nativos e outstream.	A posição do Chrome depende do caso de uso em questão. No vídeo, a posição do Chrome é que nosso trabalho é incentivar o ecossistema a convergir em soluções de vídeo in-stream viáveis usando nossas APIs. Até agora, a única proposta concreta que conhecemos é a proposta do GAM. No caso de anúncios nativos, estamos coletando feedback aqui e planejamos envolver as adtechs com mais etapas de descoberta em breve.
Monitoramento em tempo real (RTM)	O tráfego rotulado não envia relatórios de RTM.	Estamos cientes dessa lacuna e estamos trabalhando para oferecer uma solução. Vamos compartilhar uma atualização aqui quando ela estiver disponível.
Compatibilidade com a extensão de público-alvo	Solicitação de atualização sobre o suporte à extensão de público-alvo/públicos-alvo selecionados pelo vendedor na API PA.	Estamos trabalhando para oferecer uma solução para esse caso de uso. Estamos coletando feedback do ecossistema sobre o que precisamos criar e apoiar. Vamos compartilhar uma atualização quando ela estiver disponível e adoraríamos receber mais feedback aqui.
Depuração	Na ferramenta para desenvolvedores do Chrome, não há um painel para monitorar o desempenho detalhado da API PA. Por exemplo, o desempenho geral pode ser afetado pelo número de IGs ou pelo número de compradores.	Esse feedback específico está relacionado aos recursos da interface das Ferramentas para desenvolvedores do Chrome para auxiliar no monitoramento. No entanto, em 7 de outubro, anunciamos a possibilidade de as adtechs configurarem eventos personalizados que podem ser usados como base para monitoramento e alerta. Confira mais detalhes aqui. Esperamos que esta atualização resolva uma parte significativa deste feedback. Agradecemos qualquer outro feedback sobre esse recurso, seja relacionado aos pontos de dados compatíveis ou à experiência do desenvolvedor na discussão correspondente do GitHub aqui.
Indicadores	Preocupações sobre se as DSPs podem ou não garantir que os perBuyerSignals sejam enviados para SSPs independentemente dos resultados do leilão contextual.	O leilão contextual tem apenas um lance vencedor de um DSP, ou melhor, um lance para tentar vencer um leilão subsequente da API PA. Para o fluxo da API da PA, o SSP decide convidar todas as DSPs que querem ver se têm demanda (na forma de um IG no dispositivo) para enviar. É totalmente possível e muito provável que uma DSP que perdeu o leilão contextual seja "convidada novamente" para participar do leilão da API PA. Nesse "reconvite" é quando a DSP, se decidir aceitar, encaminharia para o SSP os sinais que o Verificador de anúncios gostaria de garantir que a DSP considere, se houver alguma para a campanha em questão. Em outras palavras, no leilão da API PA, sempre há uma maneira de a DSP enviar perBuyerSignals para a SSP, independentemente do que aconteceu no leilão contextual.
Indicadores	A solicitação para adicionar prevClicks ao objeto browserSignals foi transmitida para generatedBid().	Essa solicitação pode ser resolvida com nossa proposta de suporte a indicadores de cliques. Anunciamos esse recurso na nossa postagem recente do blog e na explicação correspondente. Se você quiser enviar mais feedback sobre a proposta, acesse este link.
(Também informados nos trimestres anteriores) Modelagem de indicadores	Solicitação para aumentar o número de bits de sinais de modelagem de 12 bits para 30 bits.	Respondemos a esse feedback com uma contraproposta aqui. Estamos engajados com o setor para entender as opiniões sobre nossa proposta e avaliamos os benefícios para o setor em relação ao impacto nos usuários do Chrome e outras partes interessadas.
Documentação	Solicitação de orientação sobre como usar servidores de chave-valor (K/V) e TEEs.	Confira orientações sobre o uso de TEEs no contexto de K/V nos detalhes de design do modelo de confiança de serviço K/V neste link.
Ciclo de vida de IGs negativas	Pedido para estender a duração de IGs negativas para 365 dias.	Os IGs negativos são usados para impedir a exibição de anúncios, mas usuários de má-fé ainda podem usá-los para revelar informações sobre os usuários, resultando em riscos de reidentificação (por exemplo, uma maneira de atacar usuários de má-fé é simplesmente dar lances altos com IGs negativos repetidamente para saber se um usuário visitou ou não determinados sites). Se mantivermos um TTL de 365 dias, os agentes mal-intencionados terão muito mais dados sobre IGs negativos, o que resulta em riscos de privacidade significativamente maiores. Por isso, não podemos atender a essa solicitação para proteger a privacidade do usuário.
Especificações da API	O que pode ser inserido como valores para serem transmitidos como parte de perBuyerSignals? Isso pode ser definido arbitrariamente pelo vendedor?	A perBuyerSignals é o local em que os vendedores oferecem aos compradores todas as informações que eles querem disponibilizar durante o leilão. O ecossistema decide o que quer inserir, mas aqui você pode encontrar mais informações.
Substituições de macro de tamanho de anúncio	Procurando orientações sobre a substituição de macros de tamanho de anúncio que não funciona.	Vamos compartilhar mais detalhes publicamente em breve.
Substituição da macro de SSP pós-lance: URL de nível superior de spoofing	Quais mecanismos o Chrome pode adotar para permitir que os fornecedores de verificação confirmem o URL de nível superior na estrutura do Sandbox de privacidade? Há pontos de dados ou indicadores alternativos que podem ser usados em frames restritos para garantir a precisão do URL de nível superior fornecido pelo SSP?	Estamos discutindo esse feedback adicional aqui.
Solicitação de recurso	Solicitação para fornecer UACH de baixa entropia em busca de updateURL e em postbacks de relatórios em tempo real.	Esses pedidos estão em discussão aqui, e queremos receber mais feedback aqui e aqui.
Solicitação de recurso	Solicitação para ativar o design de depuração com consentimento do servidor confiável quando um determinado cliente for acionado para enviar relatórios de nível de evento com amostragem reduzida para forDebuggingOnly.reportAdAuctionWin() e forDebuggingOnly.reportAdAuctionLoss().	Essa é uma solicitação ativa que estamos acompanhando e vamos enviar uma atualização para o ecossistema quando ela estiver disponível. Envie seu feedback aqui.
Uso do API	Solicite orientação sobre como contar o alcance de usuários únicos e o alcance da impressão.	Estamos discutindo uma proposta para ler IGs em um worklet de armazenamento compartilhado, que pode ser usado para enviar relatórios agregados privados. Confira mais detalhes neste link. Agradecemos o feedback sobre a proposta e a utilidade dela para o ecossistema.
Uso do API	Falta de clareza sobre o que os editores devem testar, quais APIs são importantes, quais devem ser ativadas e o que está por vir.	Estamos trabalhando para oferecer mais suporte aos editores e suas funções no ecossistema.
Uso do API	É possível adicionar listeners de eventos aos eventos do worklet do leilão de anúncios?	Isso não é possível com eventos normais, mas os eventos do protocolo do Chrome DevTools vão resolver parcialmente esse caso de uso. Os eventos regulares provavelmente afetam as propriedades de isolamento/privacidade, mas os detalhes estão disponíveis aqui.
K-anonimato	Procurando esclarecimentos sobre os requisitos de renderização de anúncios (por exemplo, pelo menos 50 pessoas teriam visto o anúncio se ele fosse permitido).	A documentação para desenvolvedores oferece uma visão geral das nossas expectativas para futuros desenvolvimentos. Ele explica especificamente que o limite inicial de k-anonimato é k=10 pessoas. A lista de e-mails blink-dev fornece atualizações sobre o que está acontecendo no Chrome. Conforme definido na conversa da lista de e-mails sobre k-anonimato (em inglês), estamos aplicando experimentalmente o requisito de k-anonimato a cerca de 1% do tráfego estável do Chrome, nunca aplicando-o às frações explicitamente marcadas ("Modo A" e "Modo B").
Atrito	É possível remover ou reduzir temporariamente o chaffing K/V do TEE para que não seja necessário chamar todos os fragmentos N, mas apenas uma quantidade que equilibre a proteção de privacidade com a utilidade (por exemplo, Desempenho/custo de K/V)?	Esses tipos de solicitações são tratados apenas para instâncias de não produção em que o chaffing pode ser controlado. Para instâncias de produção, o chaffing ainda é necessário. Vamos avaliar a situação assim que recebermos o feedback do uso não relacionado à produção.
Atrito	Solicitação para adicionar flag para desativar o chaffing do binário K/V de depuração/não produção.	Essa sinalização é fornecida com a versão 1.0.0.
Bug de API	A API parou de funcionar após a atualização para o Chrome 126, mesmo que ela tenha sido ativada nas configurações.	Esse problema foi relacionado à flag "enable-fenced-frames" do Chrome, que foi ativada pelos usuários para fins de desenvolvimento. Redefinir essa flag para o padrão vai resolver o problema.
Relatórios	Solicitação para que a ativação da API Reporting em tempo real não seja dependente do vendedor para os compradores.	Essa solicitação está sendo analisada aqui. A solução de RTM foi lançada recentemente, e gostaríamos de receber feedback, em especial das adtechs que já adotaram o recurso.
Relatórios	Solicitação de relatórios de terceiros: embora as DSPs e SSPs recebam notificações de impressão do Chrome, os provedores técnicos de camada intermediária não recebem por padrão.	Estamos discutindo esse pedido e aceitamos mais feedback aqui.

Serviços de leilão protegidos

Tema do feedback	Resumo	Resposta do Chrome
TEEs	A exigência do Google de integração manual de acordo com os padrões técnicos é uma restrição forte à escolha do fornecedor de nuvem. Os padrões técnicos aplicados podem ser seguidos sem uma visita ao Bureau of Cloud Providers, como o Google parece ter em mente. O atraso no lançamento de provedores alternativos em 2025 (no mínimo) é inaceitável porque vai introduzir efeitos de rede que incentivam a gorjeta nas soluções do Google.	O serviço de agregação é o único serviço necessário para executar em um serviço de TEE para atender a alguns casos de uso de adtech. O serviço de agregação oferece suporte à Amazon Web Services (AWS) e ao Google Cloud Platform (GCP). Com base no feedback das adtechs, acreditamos que esse suporte é adequado neste momento. Em outros provedores de nuvem, o Google publicou critérios detalhados para TEEs em provedores de nuvem pública. O objetivo é garantir que a solução do TEE atenda aos objetivos de privacidade e segurança do Sandbox de privacidade. Especificamente, os servidores TEE do Sandbox de privacidade processam dados não criptografados do usuário entre sites (por exemplo, dados dos sites do editor e do anunciante para o serviço de agregação). Eles precisam ser seguros para atender aos objetivos de privacidade do usuário das APIs. Um ambiente seguro também é necessário para garantir que as APIs continuem protegendo as informações comerciais confidenciais das empresas, por exemplo, impedindo que outros participantes do leilão da API PA acessem os dados comerciais exclusivos de um comprador. Até onde sabemos, não existe uma tecnologia TEE que proteja totalmente os dados do usuário contra um operador potencialmente adversário. Portanto, incluímos vários requisitos para validar a confiabilidade do provedor de nuvem. Não sabemos ao que se refere "Bureau of Cloud Providers", e ele não faz parte dos requisitos. Seu feedback sobre os requisitos é muito bem-vindo. Também continuamos avaliando o suporte a novos provedores, inclusive com base em pedidos enviados usando o processo definido na explicação. Até agora, só recebemos uma solicitação de suporte ao Azure, que está sendo avaliada.
B&A	É difícil avaliar a complexidade técnica e a viabilidade do serviço de B&A, já que o design continua evoluindo.	Para resolver essas questões, disponibilizamos explicações detalhadas no GitHub sobre o design da B&A, cronogramas de disponibilidade e um mapa de percurso de recursos que oferecem suporte à API PA. Estamos apoiando as adtechs que buscam implantar a B&A e coletando feedback do ecossistema no GitHub.
B&A	Procurando orientações e uma maneira melhor de calcular o custo do uso do TEE para B&A para começar a usá-lo ou migrar para ele no dispositivo.	Recentemente, publicamos o Guia de dimensionamento de instâncias de servidor K/V, que inclui ferramentas para medir os custos com mais precisão.
Servidor K/V	O verificador de anúncios solicita a permissão para usar o URL da página completa no servidor K/V para realizar a verificação de anúncios.	No momento, estamos avaliando a possibilidade de fornecer o URL completo da página ao servidor K/V em execução em um TEE para fins de verificação de anúncios. O URL da página completa não estará disponível no BYOS do K/V.
Segurança do leilão	Procurando recursos de segurança de leilão para garantir que usuários de má-fé não acessem dados sensíveis ou ajam como imitadores: quais recursos protegem o leilão contra ataques de repetição e como as proteções de segurança podem ser implementadas?	O modelo de segurança atual da B&A pode proteger a integridade do leilão. O B&A é executado em um TEE que protege a confidencialidade dos indicadores e do código das adtechs contra agentes maliciosos. Na arquitetura de B&A, um payload de solicitação de B&A criptografado (texto criptografado de solicitação) flui do cliente por um servidor de anúncios não confiável para o serviço SellerFrontEnd (SFE, executado por SSPs no TEE). O texto criptografado da solicitação contém um ID de geração baseado em carimbo de data/hora. O SFE vai examinar o carimbo de data/hora da solicitação e rejeitar todas as solicitações repetidas que não estiverem dentro de +/- n segundos do horário do servidor. Além disso, a B&A pode retornar um payload de resposta de tamanho fixo preenchido para comunicação entre servidores. Essas soluções podem ajudar a mitigar ataques de repetição no sistema quando um agente malicioso tenta reproduzir o mesmo payload de solicitação para saber mais sobre o conteúdo. A B&A está documentando e atualizando os modelos de segurança nas explicações.
Sinais via servidor K/V	Solicitação para incluir perBuyerSignals enviados pelo serviço K/V como parte da solicitação de indicadores de lances confiáveis do Chrome.	Estamos avaliando a viabilidade de incluir informações de perBuyerSignals, transferidas para o servidor K/V em execução em um TEE, incluindo o URL completo da página.
Servidor K/V	Solicitação de um cronograma de adoção mais em fases para restrições de privacidade em K/V e B&A.	Entendemos o desejo de uma abordagem mais gradual para a adoção do TKV e agradecemos suas solicitações específicas sobre K/V e B&A. No entanto, após uma avaliação cuidadosa, decidimos não flexibilizar as proteções de privacidade nessas APIs por enquanto. Acreditamos que essas medidas, como a chaffing, são essenciais para proteger a privacidade do usuário e manter a confiança no Sandbox de privacidade.
Servidor K/V	Procurar orientação sobre como escalonar o armazenamento K/V usando uma configuração compatível.	O Guia de dimensionamento de instâncias de servidor K/V publicado recentemente pode ajudar. A ferramenta vai informar o QPS (indicado como "RPS" na explicação) em cada combinação de parâmetros.
Servidor K/V	Adicionamos informações do vendedor à solicitação do servidor K/V.	Estamos discutindo isso e aceitamos mais feedback aqui.
Serviços de B&A + K/V	Pedido para esclarecer o cronograma de lançamento ou o roteiro para K/V e B&A.	Para K/V e B&A, temos estágios e cronogramas: Para o servidor K/V em conjunto com leilões de API de PA no dispositivo (em comparação com B&A), o cronograma público está disponível aqui. Para saber como a "disponibilidade geral" é definida para K/V, consulte a seção do roadmap, que define o conjunto de recursos para Beta e GA. Para B&A, consulte a linha do tempo pública aqui e o roadmap aqui. Definimos o teste de escala como "teste estável completo e em escala de produção". Consulte este link para conferir o conjunto de recursos específico nesta fase. O B&A também tem estágios Alfa e Beta, portanto, o teste de escala inclui o superconjunto de recursos dos estágios anteriores. Para K/V e B&A, informe se essas definições de estágio ajudam a esclarecer o que estaria disponível e quando. Se ainda houver lacunas, entre em contato. Vamos deixar as informações mais específicas para ajudar no planejamento.

Como medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Resposta do mercado	A exigência de que os sistemas de atribuição concorrentes usem apenas relatórios de evento e de resumo/agregado em limites rígidos é uma restrição arbitrária à concorrência. Isso impede a nova segmentação e atribuição em tempo real específicas do dispositivo no nível do evento, mesmo que haja salvaguardas em vigor para garantir a conformidade com a proteção de dados (por exemplo, desidentificação).	O design mencionado é baseado nas metas de privacidade da API, por exemplo, proteger informações entre sites que são transmitidas de um site para outro. Por exemplo, a ARA oferece suporte à atribuição no nível do evento por meio de relatórios de eventos. Os relatórios de eventos têm um atraso mínimo de uma hora, o que é necessário para dificultar a associação do relatório de evento à identidade do usuário no site do anunciante, usando ataques de canal lateral de tempo, conforme documentado aqui. Além disso, existem outras maneiras de fazer a atribuição, além da ARA, como coletar informações diretamente dos usuários que fornecem dados de identificação conscientemente. Estamos abertos a feedback sobre casos de uso que não podem ser alcançados com os limites de privacidade atuais das APIs do Sandbox de privacidade.
Multissuperfície	Solicitação de confirmação se as APIs ARA e Shared Storage oferecem suporte a casos de uso em várias plataformas e onde isso é evidenciado.	No momento, a ARA e o Shared Storage não oferecem suporte à atribuição de várias plataformas (entre dispositivos). A atribuição entre apps e da Web no mesmo dispositivo (via ARA) é aceita.
(Também informado em trimestres anteriores) Entre dispositivos	O ARA é compatível com conversões em dispositivos diferentes?	Nossa resposta é semelhante aos trimestres anteriores: A integração entre dispositivos apresenta novos desafios de privacidade além do 3PC e também adiciona desafios de distribuição de tecnologia devido à variedade de dispositivos e plataformas que um usuário pode usar. Estamos estudando possíveis soluções, mas nos concentramos nos casos de uso críticos atualmente compatíveis com a ARA e, no momento, não temos um cronograma para suporte entre dispositivos.
Escalonamento	Questões sobre se a API Attribution Report (ARA) está configurada no momento e se pode ser implantada e dimensionada de maneira confiável para atender a todos os usuários do Chrome.	No momento, a ARA está disponível para todos os usuários do Chrome e funcionando normalmente. Além disso, continuamos a testar e monitorar a confiabilidade e escalonabilidade à medida que o número de empresas de adtech que testam a ARA aumenta. Envie seu feedback sobre o ecossistema neste link.
(Também informado em trimestres anteriores) Eliminação de duplicação	Preocupações sobre como a ARA propõe restringir o mecanismo de atribuição em dispositivos para que os editores não consigam executar de maneira eficaz a lógica pós-atribuição para relatórios de resumo, incluindo a eliminação de duplicação de várias conversões do mesmo tipo para o mesmo clique no anúncio.	Nossa resposta permanece inalterada em relação aos trimestres anteriores: A eliminação de redundâncias em dispositivos e pipelines de medição é um desafio conhecido e atual que as adtechs também enfrentam hoje com os 3PCs. Com a ARA, as adtechs podem decidir quando registrar conversões específicas e adicionar metadados específicos para indicar quais pipelines de medição usaram para rastrear as conversões (ou seja, parte da chave de agregação), que podem ser comparados com outros pipelines de medição. Receba mais feedback do ecossistema sobre isso neste link.
Acompanhamento de conversões	Solicitação para operar com conversões de vários domínios.	Estamos discutindo essa solicitação aqui e agradecemos o feedback sobre o ecossistema.
Relatórios	O navegador espera pelo menos dois dias e até 30 dias para enviar a conversão, o que pode ser motivo de preocupação, já que a maioria dos anunciantes interessados são anunciantes de desempenho, que trabalham quase em tempo real.	As janelas de relatórios padrão para relatórios de eventos são de 2, 7 e 30 dias. Com os relatórios flexíveis de eventos, as adtechs podem mudar o número e a duração das janelas de relatórios dos valores padrão. Os períodos de relatório podem ser alterados para um mínimo de uma hora, o que pode ajudar nos casos de uso do anunciante de performance. Envie seu feedback sobre o ecossistema neste link.
Atribuição on-line para off-line	Haverá opções de implementação de publicidade on-line para off-line na ARA ou haverá outras sugestões para medir a atribuição off-line para on-line?	No momento, não há planos para incluir casos de uso de medição on-line para off-line na ARA. Há desafios significativos de privacidade e segurança que precisam ser considerados para esse tipo de suporte. Receba mais feedback do ecossistema sobre os casos de uso desse suporte neste link.
Relatórios de depuração	Como armazenar e/ou recuperar o ID de publicidade de forma que ele possa ser acessado para registros do Chrome (fonte/gatilho) para atribuição de app para a Web?	Para ativar os relatórios de depuração, a adtech precisa provar que já pode se conectar ao usuário no app e na Web. Isso é feito para garantir que nenhuma nova informação seja revelada nos relatórios de depuração. A adtech pode comprovar a combinação fornecendo uma chave de combinação exclusiva para cada usuário. Essa chave de mesclagem pode ser o AdID ou uma chave de mesclagem de 1º. Se a adtech usar o ID de publicidade, o Chrome não vai oferecer suporte nativo ao acesso ao ID de publicidade no navegador, e a API espera que cada adtech tenha o próprio método de transmissão do ID de publicidade durante o registro na Web.
Granularidade do bucket	É possível usar estratégias de agrupamento diferentes por anunciante?	Recomendamos testar diferentes abordagens de escala de orçamento de contribuição para encontrar a ideal para seus casos de uso. A ARA foi criada para ser flexível e personalizável e atender a diversos casos de uso de adtechs. Portanto, recomendamos testar diferentes estratégias de agrupamento por anunciante ou por categoria. O uso de diferentes estratégias de agrupamento pode ser útil quando os anunciantes têm diferenças nos valores de medição que querem acompanhar e no volume desses valores.
Documentação	Solicitação de documentação adicional para implementar app<>Web para ARA.	Lançamos a documentação sobre app<>Web para ARA aqui.
Desempenho	O número de solicitações relacionadas à ARA pode representar uma carga pesada nos servidores de um editor em relação ao número de solicitações de sinal de atividade necessárias para alimentar esse site. Agrupar eventos de origem em uma única solicitação pode ajudar a reduzir a carga em um servidor. Uma ideia possível é permitir uma matriz de objetos codificados em JSON.	É possível agrupar eventos de origem com base em uma lógica específica usando a lógica do JavaScript em combinação com a API. Estamos avaliando esse pedido e aceitamos mais feedback do ecossistema aqui.
Solicitação de recurso	Sugestão de uma proposta de solução alternativa devido à falta de suporte à integração entre servidores.	No momento, não planejamos implementar compatibilidade com a integração de servidor para servidor na ARA. Há muitos desafios de privacidade que precisam ser considerados para permitir a integração de servidor para servidor. Agradecemos o feedback do ecossistema sobre outros casos de uso de suporte de servidor para servidor neste link.
Documentação	Solicite um guia de "início rápido" que explique as principais partes da ARA/como começar a usar com alguns casos de uso simples.	Confira um guia de início rápido para a ARA aqui. Estamos trabalhando para melhorar essa documentação ainda este ano. Agradecemos o feedback sobre casos de uso ou cenários específicos que exigem mais documentação aqui.
Uso do API	Solicitar recomendações sobre o escalonamento de contribuições para muitos valores pequenos.	Recomendamos testar diferentes abordagens de escalonamento do orçamento de contribuição para encontrar a que funciona melhor para seus casos de uso. Para o cenário de muitos valores pequenos, recomendamos experimentar diferentes valores de epsilon para identificar pontos de inflexão em que o ruído de epsilon pode ser aceitável para seu caso de uso. Confira mais detalhes no nosso artigo de pesquisa sobre otimização de relatórios de resumo na ARA .
Nível de evento flexível	Quando a configuração flexível no nível do evento (especificações de gatilhos múltiplos) será implementada?	Atualmente, o nível flexível de evento oferece suporte à personalização dos seguintes aspectos de configuração de registro: o número de relatórios que podem ser gerados por origem, o número e a duração das janelas de relatórios e a cardinalidade dos dados do acionador. No momento, estamos coletando mais feedback do ecossistema sobre melhorias flexíveis no nível do evento, mas não planejamos implementar nenhuma delas. Agradecemos mais feedback sobre casos de uso que podem se beneficiar de algumas das melhorias flexíveis no nível do evento listadas aqui.
Processamento de bucket	Pedido para considerar o limite de contribuições agregadas para buckets, além de extensibilidade futura e compatibilidade com versões anteriores.	Estamos discutindo esse pedido e aceitamos mais feedback aqui.
Epsilon	O que acontece com o intervalo de epsilon quando a ARA muda para a disponibilidade geral?	A ARA alcançou a disponibilidade geral no Chrome no terceiro trimestre de 2023. No momento, não há planos para modificar a janela de valor de epsilon. Nossa proposta de uma estrutura de governança revisada daria garantias adicionais quando houver modificações.
Relatórios	Os relatórios de gatilho de erro desconhecido não contêm atributos de origem no corpo do relatório.	Conforme definido na especificação, não é necessário que outros campos estejam presentes no corpo do relatório para trigger-unknown-error. Sabemos que a tabela que descreve os campos no corpo do relatório pode ser enganosa, já que os campos relacionados à origem podem ou não estar presentes dependendo da causa do erro. Por exemplo, um erro interno pode ocorrer antes da lógica de correspondência de origem, o que significa que nenhum dado de origem está disponível para preencher o relatório de depuração. A documentação foi atualizada para esclarecer isso.
Uso do API	Ao trabalhar com duas metas de medição, contagem e valor, a indicação é dividir o orçamento de contribuição e o valor epsilon?	Ao trabalhar com duas metas de medição, recomendamos dividir o orçamento de contribuição entre elas.
Relatórios	O ARA oferece suporte à atribuição multitoque ou relatórios de assistência (também conhecidos como relatórios de contribuição)?	No momento, a ARA não oferece suporte a atribuição multitoque ou relatórios de assistência. No momento, não planejamos implementar essa mudança. Envie seu feedback sobre casos de uso e a prioridade deles aqui.
Bug da API	Para a ARA, a documentação indica que a operação XOR é usada para combinar as partes das chaves de agregação de origem e acionador, mas, na prática, a operação OR é usada. Essa discrepância gera confusão e possíveis erros na implementação.	A documentação foi atualizada para refletir que isso é um erro.

Serviço de agregação

Tema do feedback	Resumo	Resposta do Chrome
Jobs de agregação	Pedido para permitir vários prefixos em jobs de agregação.	Estamos investigando esse feedback e postamos uma proposta aqui. Seu feedback sobre a proposta é bem-vindo aqui.
Solicitação de recurso	Solicitação para mudar o script do Terraform para que, se service_account_token_creator_list não estiver definido (ou estiver vazio), a modificação da política de IAM da conta seja ignorada.	Estamos investigando o problema neste link e queremos receber mais feedback sobre o ecossistema.
Uso do API	É necessário esclarecer que o plano do Terraform sempre mostra mudanças.	Esse problema foi corrigido na versão 2.8 do AgS.
Uso do API	Procurando recomendações para configurar configurações por anunciante para a frequência de agregação com filtragem flexível de contribuição.	No momento, é possível agrupar por anunciante com o ARA. A filtragem de contribuição flexível pode ser usada para casos mais avançados em que uma adtech quer segmentar ainda mais as contribuições de um relatório por diferentes frequências. As adtechs podem saber mais sobre o envio em lote aqui e o uso de IDs de filtragem com o ARA aqui. Também estamos trabalhando em mais documentação para a filtragem de IDs.
Solicitação de recurso	Solicitar suporte para "log_sum_exp" no serviço de agregação (AgS).	Entramos em contato com essa pessoa para saber mais detalhes sobre o caso de uso. Vamos enviar uma atualização assim que tivermos mais detalhes.
Solicitação de recurso	Solicitar acesso a mais registros/insights/outras métricas sempre que houver problemas no AgS e possíveis problemas em um AgS implantado.	Publicamos atualizações na nossa documentação para incluir mais erros, mitigações e descrições neste link. Agradecemos o feedback sobre erros/métricas/registros etc. que não estão documentados ou disponíveis e quais detalhes seriam úteis aqui.
Testes de API	Qual será o valor final do épsilon após o período de teste?	No momento, não há planos para modificar a janela de valor de epsilon. Incentivamos os testadores a testar diferentes parâmetros e enviar feedback.
Relatórios	O relatório está sendo gerado, mas ainda recebe PRIVACY_BUDGET_AUTHORIZATION_ERROR no código de retorno.	Para evitar esse erro, oferecemos orientações sobre como especificar a origem correta dos relatórios e os relatórios agregáveis. Envie mais feedback sobre o problema, principalmente se houver erros recorrentes.
Descoberta de chave	Quais são os planos para a proposta principal de descoberta?	Ainda não temos um cronograma para o lançamento da proposta de descoberta de chaves, mas estamos solicitando feedback do ecossistema sobre a proposta aqui.
Personalização	Procurando opções de personalização disponíveis para o serviço de agregação.	As personalizações do serviço de agregação não são possíveis no TEE, mas são possíveis para alguns componentes fora do TEE. Isso ocorre devido aos padrões de privacidade e segurança que precisamos manter no TEE. Estamos trabalhando na atualização da nossa documentação para ajudar as adtechs a entender a arquitetura e quais componentes são personalizáveis. Não podemos oferecer suporte a determinadas personalizações. Por isso, recomendamos que as adtechs usem nossas configurações padrão sempre que possível.
Instâncias spot x sob demanda	O sistema foi testado usando instâncias spot em vez de instâncias sob demanda? Existem desvantagens específicas no uso de instâncias spot, além da possível indisponibilidade temporária?	Não priorizamos o teste em instâncias spot porque recomendamos que as adtechs usem instâncias sob demanda. A desvantagem das instâncias spot é o job ser interrompido durante o consumo de orçamento. Se o orçamento for consumido e o job for interrompido antes que a adtech receba o relatório de resumo, ela não poderá simplesmente tentar o job novamente, mas precisará solicitar a recuperação de orçamento. A recuperação de orçamento é recomendada apenas para falhas catastróficas para preservar a privacidade. Recomendamos que as adtechs configurem o escalonamento automático para minimizar os custos. Selecionar 0 para o escalonamento automático significa que não haverá instâncias em execução até que um job seja solicitado. Isso pode aumentar a latência, já que as instâncias serão iniciadas no momento de uma solicitação.
Erros conhecidos e soluções	Esclarecimento necessário sobre o job do serviço de agregação mostrando "Erro de serviço"	Esse problema foi resolvido aqui. Também atualizamos algumas das nossas mensagens de erro para torná-las mais descritivas. Por exemplo, começamos a gerar erros de permissão/autenticação mais específicos na AWS. Atualizamos a documentação sobre códigos de erro e etapas de mitigação aqui. Envie seu feedback sobre erros que não estão documentados ou disponíveis e sobre quais detalhes seriam úteis.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Design de chave	Solicitar orientações sobre o design da chave de agregação privada	Embora não tenhamos um guia específico para a agregação particular, o framework de teste de carga do serviço de agregação e o guia avançado de gerenciamento de chaves podem ser usados como recursos.
Orçamento de contribuição	Em que nível o orçamento de contribuição é calculado e limitado?	O orçamento de contribuição é 2^16 em uma janela contínua de 10 minutos e 2^20 em uma janela contínua de 24 horas.

Limitar o rastreamento oculto

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

Nenhum feedback recebido neste trimestre.

Proteção de IP (anteriormente Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Android	Qual é o plano para lançar a Proteção de IP no Android?	Embora estejamos estudando a possibilidade de trazer recursos de rastreamento anti-coberto para o Android, incluindo a Proteção de IP, não temos planos formais para compartilhar no momento.
Uso do API	Você tem dúvidas sobre se há ou haverá uma exceção antifraude para a proteção de IP?	Nós nos empenhamos para encontrar um equilíbrio entre proteger os usuários contra rastreamento na Web com base em seus endereços IP e, ao mesmo tempo, minimizar interrupções nas operações normais dos servidores, incluindo o uso de endereços IP para combate ao abuso. Não podemos fornecer mais detalhes no momento, mas esperamos fazer isso em breve. Vamos continuar a discussão.
Identificação de usuários de má-fé	Preocupações sobre a eficácia das medidas de segurança tradicionais contra endereços IP maliciosos.	A proteção de IP não fará proxy de solicitações próprias, portanto, esperamos que a maioria dos sistemas de detecção de intrusões não seja afetada. Planejamos fornecer mais detalhes no futuro para lidar com problemas de antifraude e quebra de sites para usuários anônimos.
Mascaramento de endereços IP	Se o site da empresa de notícias (1P) usar o mesmo domínio que o site de publicidade (3P), o endereço IP será mascarado para ambos? Caso contrário, como diferenciar os dois?	Atualmente, a Proteção de IP propõe uma abordagem baseada em lista para identificar qual tráfego de terceiros passa pelos proxies. No entanto, mesmo que uma origem esteja nessa lista, ela não vai ser usada como proxy se for acessada em um contexto de 1ª parte. Estamos finalizando os detalhes sobre quais domínios de terceiros específicos serão priorizados inicialmente e como vamos definir com precisão contextos próprios e de terceiros para a proteção de IP.
Mascaramento de endereços IP	Preocupação com a proteção de IP e o impacto dela nos sistemas antifraude.	Os 1Ps não são afetados pelos nossos planos de proteção de IP. Portanto, sites como fóruns precisam ter acesso a endereços IP para resolver disputas. Planejamos fornecer mais detalhes no futuro para resolver problemas de fraude na publicidade.
Mascaramento de endereços IP	O IP está mascarado no cabeçalho dos domínios afetados?	Os usuários serão atribuídos a uma área geográfica com base no endereço IP pré-proxy que representa a localização atual deles. Veja mais detalhes aqui.

Mitigação de rastreio por redirecionamento

Tema do feedback	Resumo	Resposta do Chrome
Especificações da API	É necessário esclarecer o comportamento do Chrome ao processar a navegação estendida quando uma guia é fechada.	Resolvemos esse problema aqui e atualizamos a especificação.
Rastreamento de navegação	Discussão sobre uma abordagem de mitigação de rastreamento que envolve um conjunto finito de links para reduzir a entropia em solicitações entre sites.	Continuamos debatendo esse assunto com outros fornecedores de navegadores neste link. Receba mais feedback e propostas específicas do ecossistema sobre esse problema.

Orçamento de privacidade

Conforme observado na explicação sobre o GitHub e no site para desenvolvedores, o orçamento de privacidade não está mais sendo considerado ativamente
como parte das propostas do Sandbox de privacidade.

Reforçar os limites de privacidade entre sites

Conjuntos de sites relacionados (antes chamados de conjuntos próprios)

Tema do feedback	Resumo	Resposta do Chrome
(Também relatado em trimestres anteriores) Limite de domínio do conjunto de sites relacionados (RWS, na sigla em inglês)	Pedido para aumentar o limite de domínios associados no RWS	Nossa resposta é semelhante a dos trimestres anteriores: No momento, não esperamos aumentar o limite numérico. O limite foi estabelecido com base nas considerações de privacidade do usuário, no feedback de partes interessadas do ecossistema no W3C e na consideração de implementações semelhantes em outros navegadores. Para mais informações, consulte nossas postagens do blog (1, 2). Recomendamos examinar os casos de uso que exigem o acesso a cookies entre sites além do limite numérico e considerar aproveitar nossas orientações para casos de uso de identidade, incorporações autenticadas e casos de uso de publicidade. Se as sessões do usuário estiverem vinculadas a ações de login, recomendamos usar a API Federated Credential Management (FedCM) para manter a funcionalidade. Envie seu feedback sobre outros casos de uso que podem ser necessários aqui.
Processamento de cookies entre sites	Os cookies entre sites definidos por um subdomínio não são transmitidos em solicitações subsequentes do domínio principal. O problema persiste mesmo com as configurações adequadas de CORS e credenciais.	Fornecemos orientações aqui sobre o uso correto da API requestStorageAccessFor, que precisa especificar a origem completa (ou seja, incluir subdomínios) para que os cookies entre sites sejam enviados em solicitações de busca subsequentes.
Escolha do usuário	Solicitação de mais informações sobre o método requestStorageAccessFor usado pelo RWS após o lançamento da escolha do usuário, em particular, como o gesto do usuário implícito ou explícito, que atualmente permite o acesso a 3PCs, vai funcionar no novo sistema.	Esperamos que o comportamento do RWS em qualquer modo de escolha do usuário (ou seja, independentemente de os usuários terem escolhido manter ou limitar os 3PCs) seja consistente com o comportamento atual/envio no Chrome com 3PCs permitidos em comparação com 3PCs bloqueados com o RWS ativado (configuração "Permitir que sites relacionados vejam sua atividade no grupo"). Recomendamos invocar hasStorageAccess primeiro para verificar se a incorporação já tem acesso a cookies não particionados entre sites antes de invocar requestStorageAccess. O método hasStorageAccess vai retornar verdadeiro se o usuário tiver permitido o 3PC. Atualmente, o requestStorageAccessFor não exige um gesto do usuário se o 3PC estiver permitido. Abrimos um novo problema no GitHub para discutir e especificar qual é o comportamento correto nesse caso. Também aceitamos mais feedback do ecossistema.
Uso do API	Preocupações sobre a falta de clareza em relação ao uso de RWS para fins "comerciais", dificultando a adoção. A parte interessada indicou interesse em agrupar publicações para publicidade segmentada.	O uso pretendido do RWS é oferecer suporte à funcionalidade principal do site e às jornadas principais do usuário. Recomendamos o uso das nossas APIs de publicidade criadas para casos de uso relacionados à publicidade segmentada.
Uso do API	Relatório de um problema com o requestStorageAccess em que os dados do localStorage podiam ser definidos, mas não os cookies.	O problema foi causado por um erro de digitação no atributo SameSite. Verifique a ortografia e defina explicitamente como "Nenhum" para 3PCs.
Especificações da API	Discrepâncias nos esquemas JSON em todo o repositório, como o posicionamento incorreto do campo "contato" e sugestões de melhorias, incluindo o uso da palavra-chave "oneOf" para garantir a consistência.	Estamos investigando esse feedback e vamos analisar a possibilidade de fazer essas melhorias no esquema em breve. Envie seu feedback aqui.
Acesso de terceiros (3P) ao RWS	Com o consentimento do usuário, permitir que uma plataforma indique os domínios de terceiros que também terão acesso aos dados da API RWS.	Permitir que terceiros combinem dados não particionados próprios com dados do site RWS vai prejudicar as proteções contra rastreamento entre sites do Sandbox de privacidade. No entanto, estamos considerando o potencial de permitir que terceiros mantenham os dados particionados em um RWS e queremos receber feedback sobre o design dessa solução neste link.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
Pergunta sobre a API	Preocupações sobre como os frames cercados sem acesso à rede podem prejudicar a brand safety e a proteção contra fraudes para os anunciantes.	Estamos acompanhando essa questão no contexto do nosso plano de aplicar as molduras restritas. Em breve, vamos começar a procurar soluções compatíveis com a aplicação de quadros delimitados e compartilharemos as propostas mais relevantes.
Pergunta sobre a API	A API Fenced Frames ainda está programada para 2026?	Conforme declarado no nosso anúncio público, os frames cercados serão obrigatórios a partir de 2026.
Bug da API	Quando reportEvent() envia dados de clique de um subframe de origem cruzada, setReportEventDataForAutomaticBeacons() não substitui os dados do frame superior.	Estamos discutindo esse problema e gostaríamos de receber mais feedback aqui.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Publicidade de apps	Não há um equivalente da API Shared Storage no Sandbox de privacidade do Android.	Estamos avaliando soluções no Android com base nas necessidades do caso de uso e nas restrições da plataforma. No momento, não temos planos para compartilhar, mas adoraríamos receber mais feedback do ecossistema sobre esse problema.
Uso do API	Confusão com relação à necessidade de um worklet JavaScript adicional para a implementação da API Shared Storage.	Estamos investigando esse feedback e planejamos atualizar nossa documentação para explicar a necessidade de outros scripts de worklet para a API Share Storage.
Falta de confiabilidade	A API Shared Storage pode mudar significativamente ou ser descartada com base nas críticas de privacidade, tornando-se uma base não confiável para desenvolvimento.	Não temos planos de mudar ou eliminar significativamente a infraestrutura de armazenamento compartilhado. As principais mudanças anunciadas são no portão de saída do URL selecionado, em que os frames restritos serão necessários, e nos relatórios de eventos, que serão descontinuados. No entanto, essas mudanças não vão entrar em vigor até pelo menos 2026.

CHIPS

Tema do feedback	Resumo	Resposta do Chrome
Cookies particionados	Ao contrário do Firefox, o Chrome não diferencia chaves de partição com base nos ancestrais dos frames.	O Chrome adotou o "bit da cadeia ancestral" para resolver a preocupação com a segurança e a discrepância com o comportamento do Firefox. Explicamos isso em mais detalhes aqui.
Cookies particionados	Os iframes incorporados com diferentes níveis de acesso ao armazenamento compartilham e substituem o mesmo cookie particionado, causando inconsistências nos estados de autenticação.	Para essa configuração específica, recomendamos o uso de cookies não particionados com uma invocação da API Storage Access. Veremos mais detalhes sobre isso neste link.
Cookies particionados	Os jars de cookie particionados serão apagados quando os protocolos 3PC forem desativados? Há uma maneira de testar esse comportamento?	Não temos planos para compartilhar no momento. No entanto, os desenvolvedores podem testar essa funcionalidade excluindo manualmente cookies particionados pelo painel "Application>Cookies" das ferramentas do Chrome.

FedCM

Tema do feedback	Resumo	Resposta do Chrome
Escopo de registro do provedor de identidade (IdP) e seletor de organização	Pergunta sobre a extensão do registro do provedor de identidade da política de mesma origem atual para uma política de mesmo site. Essa mudança permitiria um gerenciamento de identidade mais amplo e flexível, como permitir que a página de boas-vindas de uma universidade registre vários provedores de identidade baseados em subdomínios sem precisar de registros separados específicos da origem. Feedback sobre como melhorar a capacidade de depuração, processar clientes aprovados para mediação silenciosa, esclarecer o comportamento do cookie, permitir a personalização do texto do pop-up e resolver problemas de tempo limite.	Recebemos esse feedback e estamos considerando como um seletor de organização pode ser incorporado ao FedCM. Envie seu feedback sobre o ecossistema aqui enquanto continuamos a refinar essa abordagem.
Cookies do provedor de identidade	Discussão sobre o impacto da implementação de cookies de sessão de curta duração como parte da proposta de credenciais de sessão vinculadas ao dispositivo (DBSC, na sigla em inglês). Há preocupações sobre a experiência do usuário no FedCM, em que os cookies do IdP expirados exigem um modal visível para o usuário renovar.	O DBSC proposto deve permitir a renovação de cookies sem interação do usuário, garantindo uma experiência contínua. Discutimos esse problema em mais detalhes aqui.
Especificações da API	Pergunta sobre a adequação do uso de "NetworkError" na especificação da API FedCM quando o tamanho da matriz "providers" não é igual a 1.	Concordamos que "TypeError" seria mais apropriado para essa situação, porque reflete um erro de codificação, e não um problema de rede. Vamos considerar essa mudança e analisar a possibilidade de remover essa restrição em atualizações futuras à medida que avançamos para o suporte a vários IdPs. Envie seu feedback aqui.

Combater spam e fraudes

API Private State Tokens (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Teste de descontinuação e modo B	Preocupações sobre o teste de descontinuação, o teste do Modo B, a possível descontinuação dos Private State Tokens (PSTs) e a possibilidade de uma nova API mais adequada para o caso de uso antifraude.	O teste de descontinuação e o teste do Modo B permanecem inalterados. Vamos informar as atualizações no blog para desenvolvedores. Não temos planos de descontinuar os PSTs e estamos discutindo o desenvolvimento e as atualizações de recursos no GitHub. Não anunciamos nenhuma nova API, mas queremos saber como os PSTs podem atender melhor os casos de uso antifraude.
Feedback sobre a API	Solicitar a capacidade de revogar tokens para resolver um caso de uso de proteção contra fraudes.	Embora o emissor possa revogar todos os tokens mudando as chaves que ele usa, a revogação de tokens individuais é inviável com a API, porque seria necessário permitir que o emissor associasse a emissão e o resgate de tokens, o que viola o modelo de privacidade do PST de impedir o rastreamento entre os dois eventos.