Relatório de feedback – 1o trimestre de 2024

Relatório trimestral do primeiro trimestre de 2024 com um resumo do feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.

Como parte dos compromissos com a CMA, o Google concordou em disponibilizar 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). 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 de feedback, incluindo, mas não se limitando a: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe o feedback recebido do ecossistema e está explorando ativamente maneiras de integrar os aprendizados às decisões de design.

Os temas de feedback são classificados por prevalência por API. Isso é feito agregando a quantidade de feedback que a equipe do Chrome recebeu sobre um determinado tema e organizando em ordem decrescente de quantidade. Os temas de feedback mais comuns foram identificados pela revisão dos tópicos de discussão das reuniões públicas (W3C, PatCG, IETF), do feedback direto, do GitHub e das perguntas mais frequentes que surgiram pelas equipes internas do Google e formulários públicos.

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

As explicações sobre as respostas do Chrome ao feedback foram desenvolvidas a partir de perguntas frequentes publicadas, respostas reais feitas às questões levantadas pelas partes interessadas e pela determinação de uma posição específica para os fins deste exercício de relatório público. Refletindo o foco atual de desenvolvimento e teste, as perguntas e o feedback foram recebidos, principalmente em relação às APIs Topics, Protected Audience e Attribution Reporting.

É possível que o feedback recebido após o final do período do relatório atual ainda não tenha uma resposta do Chrome considerada.

Glossário de siglas

ARA

API Attribution Reporting

CHIPS

Cookies com estado particionado independente

DSP

Plataforma de demanda

FedCM

Gerenciamento de credenciais federadas

QPS

Conjuntos primários

IAB

Interactive Advertising Bureau

IdP

Provedor de identidade

IETF

Força Tarefa de Engenharia da Internet

interno

Endereço Protocolo de Internet

openRTB

Lances em tempo real

Prorrogação

Teste de origem

API PAT

API Protected Audience (antiga FLEDGE)

PatCG

Grupo da comunidade de tecnologia de publicidade privada

RP

Parte confiável

RSD

Conjuntos de sites relacionados (antigos conjuntos primários)

SSP

Plataforma de fornecimento

TEE

Ambiente de execução confiável

UA

String do user agent

UA-CH

Dicas de cliente do user agent

W3C

Consórcio World Wide Web

DESENVOLVIMENTO

Daltonismo voluntário de IP

Feedback geral, sem API ou tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
Governança	Interesse em um período de comentários públicos para atualizações de governança do Sandbox de privacidade.	Estamos abertos a feedback razoável das partes interessadas sobre qualquer desenvolvimento significativo relacionado ao Sandbox de privacidade, incluindo a governança futura desse recurso.
testes	Outras fases de teste para 3PCD, além dos testes facilitados pelo Chrome de 1%.	Não pretendemos oferecer testes facilitados pelo Chrome além do atual 1% do tráfego do Chrome ativado desde o início de janeiro.
Da Web para o app	A 3PCD em dispositivos móveis não deve acontecer antes que a interoperabilidade completa entre a Web e o app seja alcançada.	Concordamos que é desejável oferecer suporte à interoperabilidade entre apps e Web, lançamos a medição de atribuição entre apps e na Web e estamos explorando soluções de segmentação da Web para o app. No entanto, não pretendemos atrasar a 3PCD na Web para dispositivos móveis. Não temos uma meta de 100% de cobertura ao final dos 3PCDs. Em vez disso, esperamos que a compatibilidade no Android para a medição entre apps e na Web seja razoavelmente alta em 3PCD e aumente com o tempo, à medida que os usuários atualizarem os smartphones.
Função do navegador	O Chrome parece estar assumindo o papel de um servidor de anúncios ou SSP.	O Chrome não está assumindo o papel de um servidor de anúncios ou SSP. Com a API PA, o Chrome oferece um contêiner para que servidores de anúncios, SSPs, DSPs e outras adtechs usem a própria lógica de lances e pontuação.
Orientações para casos de uso	Orientações mais claras sobre quais casos de uso vão ser compatíveis com as APIs do Sandbox de privacidade.	No início do projeto do Sandbox de privacidade, a documentação do desenvolvedor se concentrava principalmente em trazer os desenvolvedores aos processos de discussão e feedback para todas as propostas. Isso significa que o conteúdo foi, de modo geral, estruturado para entender a motivação e os conceitos por trás do projeto, seguidos por detalhes dos detalhes iniciais de desenvolvimento e teste de cada proposta. Isso foi eficaz na criação de uma colaboração de ecossistema real no desenvolvimento das propostas, mas, à medida que as APIs evoluíram para a disponibilidade geral, há um novo público de desenvolvedores que está aqui principalmente para desenvolver as APIs em vez de contribuir para seu desenvolvimento subjacente. Recentemente, atualizamos a navegação de Data developer.google.com/privacy-sandbox para casos de uso recentes do IAB para casos de uso do Sandbox de privacidade, o Tech Force e as categorizações do IAB sobre casos de usos semelhantes do IAB.google.com foram atualizados. Essa abordagem baseada em casos de uso para documentação é algo que vamos continuar no futuro.
Ambiente de desenvolvimento local	Como continuamos a desenvolver e testar nosso front-end localmente em http://localhost quando o cookie é SameSite=Secure e o back-end é liderado por uma CDN?	Estamos discutindo esse problema aqui e queremos receber mais feedback do ecossistema.
Mitigação de 3PCDs	Existe uma maneira programática de saber se os 3PCs estão bloqueados ou quando a heurística está ativa?	No Chrome, tanto a detecção de recursos quanto o document.hasStorageAccess chamado em um iframe permitem que o desenvolvedor saiba se a origem no iframe tem acesso a dispositivos de terceiros.
Teste de vídeo	No momento, não é possível testar anúncios em vídeo no Sandbox de privacidade.	O Chrome postou uma discussão e uma demonstração de várias maneiras possíveis de realizar um vídeo com a API PA hoje (consulte 242 e 254 no nosso repositório de demonstrações no GitHub). Eles não são um exemplo de código que as adtechs adotariam no atacado, mas como uma prova de conceito e uma demonstração das técnicas que oferecem suporte à renderização de vídeo VAST com a API PA. Ao longo desta discussão, também ficou claro que, embora a renderização de vídeo já seja possível hoje, o Chrome pode fazer mudanças que simplificariam a implementação com a API PA. Por exemplo, atualizações na substituição de macros (discutidas aqui), que já estávamos planejando resolver com base no feedback sobre os casos de uso de brand safety do verificador de anúncios de terceiros, também abordariam o feedback no caso de uso de vídeo, em que o comprador procura quais macros do vendedor usar na renderização. Até agora, a maior parte das discussões tem se concentrado na renderização de anúncios em vídeo VAST. A renderização de anúncios nativos pode usar as mesmas abordagens, além de ser muito mais fácil. A publicidade nativa parece estar recebendo menos atenção do que o vídeo, mas essa é apenas uma questão de priorização do setor de tecnologia de anúncios, e não de qualquer barreira técnica para a implementação.
Medição não relacionada a anúncios	Os 3PCDs podem afetar as soluções de medição de público-alvo não relacionadas a anúncios.	As APIs de medição não exigem que o caso de uso seja relacionado a anúncios. Embora a ARA seja mais específica para uma jornada de publicidade típica,a agregação privada é de uso geral. Esses dois elementos básicos podem ser usados para lidar com uma grande variedade de atividades de medição.
Criadores de conteúdo	O Sandbox de privacidade está estruturado para incentivar os criadores de conteúdo a produzir mais para o YouTube e menos nos próprios sites.	O foco da iniciativa do Sandbox de privacidade é manter a privacidade das atividades das pessoas em uma Internet aberta e sem custo financeiro. Sabemos que os editores dependem de anúncios para produzir conteúdo e disponibilizar esse conteúdo o mais amplamente possível. Os anunciantes ajudam as pessoas a descobrir novos produtos ou ofertas. Os recursos do Sandbox de privacidade permitem que sites de todos os tipos, incluindo aqueles que trabalham com criadores de conteúdo, mostrem anúncios úteis com base nas atividades com partes diferentes, sem revelar a identidade do usuário.
Cronogramas mais claros	Programações de lançamento mais claras e detalhadas para as tecnologias do Sandbox de privacidade.	A documentação da API do Sandbox de privacidade inclui o status e as páginas de disponibilidade da API. Estas páginas listam os próximos recursos e os respectivos cronogramas (por exemplo, API PA, ARA). Acesse uma visualização central desses status aqui.
Machine learning	As adtechs não conseguem treinar adequadamente os modelos de aprendizado de máquina até que a 3PCD se estenda além de 1%.	A expansão do 3PCD para mais navegadores para testes não garante que as APIs teriam mais uso, o que provavelmente é o que as adtechs estão procurando para treinar ainda mais os modelos de aprendizado de máquina. Se as adtechs não querem aumentar o uso do ecossistema para treinar ainda mais os modelos de aprendizado de máquina, não há motivo para expandir os 3PCDs, porque uma adtech que quer treinar modelos com mais tráfego pode fazer isso hoje sem um aumento nos 3PCDs. Isso pode ser feito sem que o Chrome aparentemente avançar no 3PCD antes do fim da inatividade.
Caso de uso sem suporte	Os casos de uso de DSP de autoatendimento não estão sendo considerados no momento.	Existem várias DSPs de autoatendimento que fornecem regularmente feedback público sobre as APIs. Várias dessas DSPs que fornecem feedback público regular também se listaram como testadores. Além disso, o Chrome está se envolvendo ativamente em tópicos comuns de DSP de autoatendimento, como servidores de anúncios de terceiros e de vídeo. As chamadas semanais recentes da API PA abordam esses tópicos.
Teste de origem	Solicitação de OT para sites que querem uma expansão mais agressiva e cobertura de teste para 3PCD.	O Chrome está desenvolvendo um OT próprio, que vai permitir que as origens ativem o comportamento de desativação do uso de 3PCs. As origens de nível superior registradas nesse teste e usam tokens de implantação têm os três PCs bloqueados, como se o dispositivo do usuário tivesse a proteção contra rastreamento ativada. Essa OT vai oferecer uma oportunidade valiosa para os sites realizarem testes mais amplos de alternativas de longo prazo aos 3PCs, antes da eventual desativação dos 3PCs, programada para ocorrer após a consulta com a CMA. Ainda estamos trabalhando para finalizar o cronograma de lançamento do OT.
Relatório do IAB Tech Lab	Feedback sobre o Sandbox de privacidade recebido do relatório do IAB Tech Lab.	Respondemos ao relatório do IAB Tech Lab em detalhes neste link. Também reconhecemos que "o relatório levanta questões sobre documentação fragmentada, requisitos comerciais, auditorias de terceiros, certificação do setor, escalonabilidade, transparência e governança futura. Nós envolveremos o ecossistema e atualizaremos nossas perguntas frequentes públicas de acordo com isso". Já abordamos a documentação fragmentada. Os requisitos comerciais em "Garantias de dados" estão listados neste link, e alguns produtos de anúncios do Google compartilharam abordagens. Abordamos auditorias de terceiros em "Garantia de integridade do algoritmo" neste link. Em relação ao credenciamento, esperaríamos que essas entidades continuem a creditar produtos, incluindo o uso de tecnologias, em vez das tecnologias sozinhos. Em relação à escalonabilidade, continuamos abertos a dados de desenvolvedores que demonstram problemas. Em relação à transparência e governança, continuamos desenvolvendo abertamente no GitHub e em fóruns como o W3C enquanto trabalhamos com a CMA no âmbito dos Compromissos.
Login do Google	Os logins do Google levariam à possibilidade de o Google usar dados de login de identificação cruzada de maneira contrária aos compromissos.	O Login do Google não permite que o Google use dados contrários aos Compromissos.
Compatibilidade	Quais são os planos para o suporte às APIs do Sandbox de privacidade e a compatibilidade com versões anteriores / futuras?	Quando o Chrome lança um recurso para disponibilidade geral, pretendemos manter a compatibilidade com ele. É claro que nem sempre é possível manter a compatibilidade com versões anteriores. Nesses casos, temos um processo claro para descontinuação e remoção de recursos, conforme descrito aqui. Esperamos continuar adicionando mais recursos às APIs do Sandbox de privacidade ao longo do tempo, em resposta ao feedback do ecossistema sobre os casos de uso que poderiam se beneficiar de um suporte aprimorado. Nesses casos, tendemos a incluir algum tipo de técnica de detecção de recursos, para que uma adtech interessada em testar um novo recurso possa perguntar diretamente ao navegador se o recurso é compatível. Isso é melhor do que pedir aos desenvolvedores para verificar se há um determinado número de versão do Chrome, já que alguns recursos podem não ser lançados para todos os usuários do Chrome ao mesmo tempo. Por exemplo, nosso trabalho de detecção de recursos para a API PA pode ser encontrado aqui.
Implementação do servidor	Em vez de se vincular à própria implementação, o Chrome precisa especificar os comportamentos que uma implementação satisfatória de um servidor de indicadores confiáveis, de um servidor de agregação e de qualquer outro componente necessário que não seja do navegador precisa atender. Isso permitiria inovação dentro de limites de privacidade aceitáveis.	Valorizamos e aceitamos o desejo de inovação de partes externas. Para todas as APIs e serviços, nosso objetivo é oferecer às adtechs flexibilidade para implementar a funcionalidade delas. Por exemplo, permitimos que as adtechs usem informações comerciais confidenciais ao criar a lógica de lances para leilões. Além disso, interagimos continuamente com o feedback de adtechs e, quando justificado, incorporamos isso aos nossos designs. Para permitir que outras pessoas executem o próprio código em ambientes de execução confiável, o Sandbox de privacidade precisa revisar o código (e as mudanças) para confirmar se ele atende às garantias de privacidade. Isso vai exigir um esforço significativo da equipe do Sandbox de privacidade. Portanto, gostaríamos de entender quais benefícios a parte interessada está buscando alcançar, que não são atendidos por nós hoje.
Heurística	Quais são os planos de longo prazo para a heurística?	Alinhados com o que outros navegadores indicaram, pretendemos eventualmente retirar essas heurísticas à medida que soluções alternativas se tornarem amplamente utilizadas, sujeitas a análises de viabilidade adicionais. Compartilhamos isso aqui.
Teste de volume	Diferentes volumes de tráfego ao comparar dimensões diferentes.	Os critérios de exclusão de 1% do experimento levam a diferenças na qualificação entre grupos diferentes de clientes do Chrome. Por exemplo, o experimento exclui usuários do Chrome Enterprise, então é esperado que a fração do tráfego com rótulos de experimento seja maior nos fins de semana. Espera-se observar porcentagens diferentes de tráfego em diferentes frações de dados (como localização geográfica, data e plataforma), e isso está de acordo com o que estamos vendo nos dados do Chrome.
Reativar computadores de terceiros manualmente	Os sites vão poder saber quantos usuários (%) reativaram manualmente os cookies depois que o 3PCD foi aplicado?	Os usuários poderão reativar o acesso a 3PC no nível do site com a opção "Ignorar pelo usuário" se houver falhas. Os dispositivos de terceiros também podem ser reativados por outras medidas, como a API Storage Access. Existem medidas técnicas, como hasStorageAccess(), que permitem aos sites detectar se os 3PCs estão ativados ou desativados. No entanto, o Chrome não oferecerá aos sites uma maneira de saber os motivos da reativação.
Proteção antirrastreamento	Por quanto tempo o recurso de interface de Proteção antirrastreamento do Chrome ficará disponível?	Espera-se que a interface da Proteção antirrastreamento na barra de endereço fique após o fim do uso dos 3PCs.
(Também informado nos trimestres anteriores) Suporte a vários navegadores	Outros fornecedores de navegador que adotam as APIs do Sandbox de privacidade.	Outros fornecedores de navegadores, como Apple, Mozilla e Microsoft, são participantes ativos dos fóruns públicos em que os princípios de privacidade e abordagens baseadas em navegador estão sendo discutidos. Somos incentivados pelas discussões colaborativas em fóruns como a recente reunião anual do TPAC do W3C e os fóruns do PATCG do W3C, onde vemos sinais de convergência. Por exemplo, o Microsoft Edge anunciou recentemente o plano que "visa maximizar a compatibilidade sintática" com a API PA e ARA, além de oferecer recursos adicionais para desenvolvedores.
Opção de substituição para incorporações incompatíveis após o 3PCD	Forneça ganchos de API para detectar se um iframe / incorporado de terceiros é compatível ou não com 3PCD.	Estamos discutindo a solicitação aqui e esperamos receber feedback adicional do ecossistema.
testes	Solicitar mais sinalizações em instâncias gerenciadas do Chrome que desativam temporariamente os comportamentos personalizados.	Estamos considerando essa solicitação de instâncias gerenciadas do Chrome e aceitamos novas informações do ecossistema, caso essa sinalização seja útil.

Registro e atestado

Tema do feedback	Resumo	Resposta do Chrome
Verificação de atestado	Como o Google vai garantir a autenticidade dos atestados?	Todos os responsáveis pelo registro precisam manter o arquivo de atestado no local ao usar as APIs. O Google valida que o arquivo está no lugar e a sintaxe está correta, mas não valida o comportamento da adtech em relação à linguagem de atestado.
Processo de inscrição da API Private agregação	Existe uma maneira de verificar o status do registro da API Private Aggregate?	Todos os inscritos aprovados são notificados por e-mail da equipe de suporte à inscrição assim que a inscrição é validada. Se o responsável pelo registro tiver alguma dúvida durante o processo, ele poderá entrar em contato com a equipe de suporte (que está conectada ao enviar o formulário de inscrição). A equipe de suporte responderá às perguntas e fornecerá as orientações adicionais necessárias.

Mostre conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
(Também informado nos trimestres anteriores) Cronograma e documentação do classificador	Deve haver algum mecanismo para revisar a classificação ou pelo menos mais transparência sobre como o modo de classificação determina as categorias.	Nossa resposta não mudou em relação aos trimestres anteriores: "A classificação incorreta de sites pode fazer com que o indicador da API Topics seja um pouco menos útil como um indicador em geral, mas os sites específicos classificados incorretamente não são mais nem menos prejudicados do que qualquer outro site. Isso ocorre porque as informações contextuais de um site sempre estarão disponíveis para leilões, o que forneceria informações comparáveis ao tópico correto, mesmo em caso de classificação incorreta. Clique aqui para receber feedback sobre esse assunto.
Google Ad Manager	O Google Ad Manager já está incorporado à maioria dos sites e terá informações muito mais amplas sobre os tópicos dos usuários do que os concorrentes que estão presentes em menos sites.	O requisito de observação existe para garantir que a API Topics não resulte no compartilhamento de dados do usuário com mais entidades do que as tecnologias que a API está substituindo (incluindo 3PCs). Outras soluções do setor, como o Prebid, funcionam com 10 mil sites e permitem que os participantes do mercado chamem a API Topics usando a tecnologia. Além disso, vale a pena ressaltar que o limite de até cinco tópicos principais por semana pode ter um efeito de equalização, já que participantes do mercado presentes em muitos sites que podem ser capazes de aprender mais de cinco tópicos equivalentes usando 3PCs serão limitados a cinco.
(Também informado nos trimestres anteriores) Utilidade para diferentes tipos de partes interessadas	Preocupações sobre o valor criado e a distribuição desse valor para sites, dependendo do nível de tráfego ou da especialização do conteúdo.	Reconhecemos que os sites especializados têm mais chances de contribuir com tópicos mais específicos do que domínios de interesse geral. No entanto, nem todos os sites especializados contribuem com tópicos valiosos. Além disso, essa dinâmica reflete o status quo e é totalmente independente do fim do suporte para 3PCs no Chrome. Ainda no ambiente atual, alguns sites oferecem mais valor do que outros em sistemas de relevância de anúncios baseados em 3PC. Além disso, os tópicos entre sites especializados podem ser mutuamente benéficos entre si, já que anunciantes diversos podem veicular campanhas em diversos conjuntos de tópicos, e a lógica de lances pode observar o valor em uma ampla variedade de tópicos.
Nomes de host x URLs completos	A classificação com base em nomes de host de sites é suficientemente eficaz e reduz o risco de privacidade em comparação com os URLs completos?	Consideramos usar URLs ou títulos de páginas, além dos nomes do host, e determinamos que os possíveis benefícios seriam compensados pelos riscos à privacidade e à segurança do usuário. Um exemplo de riscos de privacidade do usuário inclui a classificação de informações sensíveis incluídas no URL ou no título da página nos tópicos do usuário.
Tópicos como um indicador	Peça orientação sobre como combinar a API Topics com outros indicadores e quais outros indicadores poderiam ser úteis.	As soluções de adtech podem oferecer os melhores resultados combinando todas as ferramentas disponíveis, como aprendizado de máquina e indicadores com proteção da privacidade de APIs que preservam a privacidade, além de dados contextuais, de criativos e dados próprios. Mais orientações sobre isso estão disponíveis aqui.

API Protected Audience (antigo FLEDGE)

Tema do feedback	Resumo	Resposta do Chrome
Testar o volume de tráfego	Os testadores relataram baixo volume de resposta do lance para o leilão da API PA.	1. A densidade de lances está relacionada à participação do ecossistema na API PA, que vai continuar aumentando ao longo de 2024 em diante. Em última análise, cabe aos anunciantes, às agências e aos provedores de tecnologia deles determinar como alocar os orçamentos das campanhas. É esperado que alguns participantes do ecossistema atrasem seu investimento em várias soluções "sem cookies", incluindo a API PA, para depois do 3PCD. No momento, esperamos que ela aumente a alocação do orçamento da campanha para essas soluções. 2. O volume de solicitações de lance nos leilões da API PA pode ser afetado por (1), já que os editores e os provedores de adtech podem decidir não iniciar esses leilões se acharem que a demanda está baixa. Cabe aos editores determinar a prioridade de atualização das páginas e da participação. Por esses motivos, os editores podem precisar de tempo para testar e aumentar o tráfego gradualmente. Este relatório também inclui uma resposta do Google Ad Manager sobre os controles do editor para a participação na API PA.
(Também informado nos trimestres anteriores) Fraude / Abuso	Como o ecossistema pode reduzir os riscos e impedir que usuários de má-fé ou compradores se posicionem como um público-alvo desejável?	Atualmente, os mecanismos de geração de relatórios dos anúncios da API PA retêm as informações usadas para distinguir pessoas do tráfego de bots. Além disso, as técnicas atuais de inclusão ou exclusão de domínios podem ser usadas na API PA. Isso é descrito com mais detalhes na nossa resposta ao relatório do IAB Tech Lab sobre o Sandbox de privacidade.
Mesma restrição de origem para o proprietário do IG e o URL da lógica de lances	Com o requisito da mesma origem, os endpoints de um proprietário do Instagram serão forçados a passar pelo mesmo balanceador de carga, o que pode levar à rejeição dos redirecionamentos.	O requisito de mesma origem para o carregamento de scripts é uma proteção de segurança importante. Confira aqui alguns detalhes sobre uma solução proposta que equilibra o feedback do ecossistema e outras considerações.
Leilão privado de vários slots	Há um grande espaço para permitir leilões privados com vários slots dentro dos limites de privacidade usando ruído e maior integração com as práticas atuais dos anúncios.	Estamos considerando esse feedback e avaliando a solicitação de leilões de várias tags em relação ao aumento da complexidade e dos riscos de privacidade associados a esse recurso. Discutimos esse problema em mais detalhes durante um grupo da comunidade de incubadoras da Web (WICG, na sigla em inglês) da API PA.
Vendedores de alto nível	A estrutura atual da API PA fornece aos vendedores de nível superior muito mais dados e compreensão do valor relativo das impressões do que os editores ou vendedores de componentes.	Em um leilão de vários vendedores, cada vendedor terá um melhor lance. Além disso, aprendemos com o ecossistema que os editores podem querer considerar a demanda de venda direta ao lado dos melhores lances de cada vendedor com quem trabalham. É necessário analisar todas essas oportunidades de monetização em potencial para determinar qual anúncio será veiculado. Essa situação, em que é necessário que algum agente veja o conjunto completo de opções para escolher um anúncio para veiculação, é anterior à API da PA. A API PA busca apoiar os leilões de vários vendedores e o desejo dos editores de considerar o melhor lance de cada vendedor ao lado de campanhas publicitárias de venda direta, quando aplicável. Isso significa que é preciso haver um mecanismo para você escolher uma das oportunidades de monetização como existe hoje. Não acreditamos que o papel do navegador era selecionar o anúncio a ser veiculado. Assim, o conceito de vendedor de alto nível é necessário para selecionar um anúncio vencedor entre muitas possibilidades. A lógica desse vendedor de nível superior precisa ser capaz de considerar os melhores lances de cada vendedor com quem o editor opta por trabalhar. E a lógica desse vendedor pode optar por fornecer informações sobre as campanhas de venda direta do editor, quando esses dados estiverem disponíveis. Todas essas informações podem ser consideradas na lógica de seleção de anúncios de nível superior. Isso significa que a lógica de nível superior identifica os melhores lances do leilão da API PA e, quando aplicável, as opções de anúncios de venda direta do editor para determinar o vencedor. O Google Ad Manager detalha a implementação da API PA como um vendedor de nível superior neste relatório sob o tema "Acesso às informações".
Separação de anúncios da concorrência	Solicitação de separação competitiva de anúncios, como impedir que anúncios de marcas concorrentes sejam exibidos lado a lado.	Não conhecemos uma maneira de garantir a separação competitiva no ecossistema de publicidade digital de vários vendedores programático, com lances e de vários vendedores. No entanto, a API PA permite que os vendedores busquem outros indicadores em tempo real com base em uma combinação de renderURL e nome do host (representando o domínio do editor) que podem ser usados durante scoreAd() ao pontuar criativos. Pode ser usado por vendedores para impedir que anúncios de marcas concorrentes sejam exibidos lado a lado, supondo que o editor queira aplicar essa regra.
Informações limitadas	A API PA reduz as informações disponíveis para os editores, como valor do anúncio, nome do comprador do componente, nome do anunciante, URL da página de destino, tamanho do criativo, tempo de resposta e taxa de lances, além de lances perdedores.	Sugerimos algumas possíveis soluções aqui e aceitamos o feedback adicional do ecossistema.
Relatórios no nível do evento	Os editores não têm acesso a informações suficientes sobre o anúncio veiculado após a descontinuação da API PA de relatórios de eventos.	Estamos cientes dos diferentes casos de uso de geração de relatórios que precisaremos continuar a oferecer suporte quando os relatórios de eventos forem desativados. Por isso, definimos que a data de desativação dos relatórios de eventos não seria anterior a 2026. Nesse período, convidamos a participação ativa à medida que nos envolvemos com o ecossistema por caminhos duradouros que possam incluir novas ideias para conseguir informações de forma a preservar a privacidade.
Várias SSPs	O valor agregado por ter várias SSPs será muito baixo para os editores.	Não acreditamos que essa informação esteja correta e receberia feedback do ecossistema para entender a lógica dessa afirmação.
Atividades de curadoria	Não é possível realizar atividades de curadoria com a API PA.	Recebemos feedback sobre a capacidade dos vendedores de usar a API PA para fornecer informações sobre o público-alvo aos compradores na Web (também conhecida como extensão de público). Acreditamos que isso é possível atualmente, usando a funcionalidade de delegação da PA junto com os contratos comerciais. Ao mesmo tempo, estamos considerando se e como podemos acomodar melhor esses tipos de casos de uso.
Desativação do comprador	A recusa padrão do comprador provavelmente vai gerar resultados menores para leilões de componentes.	Ao definir um único vendedor ou um leilão de PA de vários vendedores, o vendedor precisa listar explicitamente os compradores no campo interestGroupBuyers do AuctionConfig. Isso é baseado no feedback do ecossistema de que os vendedores têm acordos contratuais com alguns compradores e não com outros. Por isso, é necessário ter controle explícito sobre quais compradores incluir no leilão. É permitido discutir mais sobre o GitHub.
Anúncios	Não é possível pré-filtrar com base no tamanho do anúncio e no adSlotSize.	Estamos trabalhando para adicionar esse recurso. Mais detalhes estão disponíveis aqui.
Compatibilidade com segmentação negativa por IG	Uma API compatível com a segmentação negativa de IG: mostrar anúncios somente se o usuário não pertencer a esse grupo.	Este problema do GitHub propôs uma maneira alternativa de implementar a segmentação negativa, na qual o navegador informa diretamente ao servidor de anúncios quais regras de segmentação negativas precisam estar em vigor para uma determinada solicitação de anúncio. Embora essa pareça uma abordagem atraente, todas as versões dessa ideia que investigamos permitem que o servidor identifique o usuário de maneira exclusiva.
Lei dos Serviços Digitais	Como um editor pode usar Fenced Frames, mas também impedir que respostas contendo informações sujeitas à Lei dos Serviços Digitais sejam renderizadas?	Como acontece com qualquer tecnologia nova, cada empresa é responsável por garantir que o uso do Sandbox de privacidade obedeça à legislação. O Google não pode oferecer orientação jurídica a outras pessoas. Para cada API, publicamos uma extensa documentação técnica, que fornece a base para as avaliações legais necessárias. O uso de Fenced Frames não é obrigatório na API PA antes de 2026. Assim, as partes interessadas vão ter mais tempo para garantir que o uso dessa tecnologia esteja em conformidade com toda a legislação relevante.
Documentação	O updateAd InterestGroups() é temporário?	Não anunciamos nenhum plano para suspender o uso de updateAd InterestGroup. No futuro, poderemos aplicar proteções de privacidade semelhantes às mencionadas publicamente para outros mecanismos de atualização do IG, por exemplo, usar um endereço IP também como proxy e adicionar um atraso antes que a atualização ocorra.
Suporte a metadados de compra e propriedade de lógica para não DSPs	Solicitação de uma maneira de atuar como um proxy para DSPs.	Estamos cientes desse feedback de segmentos não DSP e estamos considerando essa solicitação. Gostaríamos de receber mais feedback do ecossistema.
Relatórios	Solicitação para adicionar o recurso de gerenciador personalizado para o bucket / valor de indicadores nos relatórios de agregação particular.	Estamos cientes e a solicitação de recurso está na nossa fila para ser descoberta mais detalhadamente. Clique aqui para receber mais feedback do ecossistema.
Documentação	Existe um link em que é possível visualizar todos os cabeçalhos de resposta que precisam ser definidos pelo anunciante e pelo domínio do proprietário (delegado)?	Estamos planejando atualizações na documentação para esclarecer isso e receber feedback adicional do ecossistema.
Lances em várias torres	Solicitação de uma explicação do fluxo de trabalho (treinamento e inferência) por meio de uma arquitetura ou diagrama de blocos sobre como uma abordagem de várias torres é imaginada no contexto da API PA.	Agradecemos o feedback. Temos algumas apresentações sobre o assunto para as quais planejamos criar documentação adicional.
Segmentação negativa	Capacidade do Sandbox de privacidade de proteger públicos-alvo sensíveis e menores de anúncios inadequados, como jogos de azar.	A API PA não considera o conteúdo dos anúncios mostrados. Isso controla os desenvolvedores de adtech que usam a PA. Em geral, o editor e os provedores de adtech podem bloquear criativos de anúncios nos leilões da Protected Audience usando informações contextuais da página e dos conjuntos de regras do editor. Isso reflete nossa compreensão da abordagem do ecossistema para esses desafios hoje. Para os compradores, a funcionalidade negativa de segmentação por IG também pode ser útil em alguns casos de conformidade.
Design de API	O Google está recusando e quer que as adtechs usem uma função de lances universais para aumentar a latência, em vez de diferentes URLs BiddingLogic em diferentes IGs, o que é permitido.	Durante nossas discussões sobre a latência do leilão, destacamos que reutilizar o mesmo script em todos os IGs de um comprador aceleraria os lances dele. Isso é detalhado aqui com nossas outras recomendações para melhorar a latência do leilão da API PA.
Marketing baseado em contas	A API PA não é limpa para casos de uso de marketing baseado em contas.	Agradecemos o feedback do ecossistema sobre casos de uso específicos que considerem impossível e incentivamos os participantes do ecossistema a continuar a discussão no nosso repositório público do GitHub (link em inglês) ou em chamadas semanais.
Teste A/B	No momento, quando a API PA é configurada no GAM para um editor, ela precisa ser ativada para todo o inventário ou para nenhum. Isso limita a capacidade dos editores de realizar um teste A/B viável.	Resposta fornecida pelo Google Ad Manager: os controles da API PA no Google Ad Manager (GAM) afetam a capacidade do GAM de usar a API, desde que ela esteja disponível. Assim, os editores podem executar testes A/B com a funcionalidade da política de permissões do Chrome para desativar o uso da API em um subconjunto de tráfego e usar como grupo de controle em um teste A/B.
Machine learning	Os editores precisam de mais controle sobre o uso proposto do aprendizado de máquina pelo GAM.	Resposta fornecida pelo Google Ad Manager: Em janeiro de 2024, lançamos um controle que oferece aos editores a possibilidade de desativar nosso limitador de aprendizado de máquina e ativar leilões de APIs de PA com vendedores que não são do Google em todo o tráfego. Confira mais detalhes sobre esse controle na Central de Ajuda.
(Também informado nos trimestres anteriores) Leilões de nível superior	Capacidade de usar o servidor de anúncios do editor do Google sem também dar ao GAM o controle do leilão de nível superior da API PA.	Resposta fornecida pelo Google Ad Manager: pelos motivos explicados no relatório do 3o trimestre de 2023, os planos do GAM para a integração da API PA não incluem o suporte a editores que usam o GAM como servidor de anúncios do editor sem controle do leilão de nível superior.
Acesso às informações	O GAM tem acesso a informações valiosas dos concorrentes, incluindo preços de leilão contextuais, indicadores fornecidos por compradores às SSPs para o leilão da API PA e parâmetros de configuração das SSPs.	Resposta fornecida pelo Google Ad Manager: Mantemos o foco na imparcialidade do leilão por anos, incluindo nossa promessa de que nenhum preço de qualquer fonte de publicidade não garantida de um editor, incluindo preços de itens de linha não garantidos, será compartilhado com outro comprador antes de dar lances no leilão, o que reafirmamos mais tarde em nossos compromissos com a Autoridade de Concorrência da França. Nos leilões da API PA, pretendemos manter nossa promessa e não compartilhar o lance de nenhum participante com outro antes da conclusão do leilão em leilões com vários vendedores. Para esclarecer, não compartilharemos 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 as configurações de leilão de componentes, incluindo indicadores fornecidos por compradores às SSPs, como parte do nosso próprio leilão. Na verdade, gostaríamos de fazer mudanças na API PA que permitam aos vendedores dos componentes especificar as configurações de leilão dos componentes de maneira ofuscada pelo vendedor de nível superior.
Leilões de componentes	Como o leilão de nível superior, o GAM controla quais SSPs realizam leilões de componentes para cada oportunidade de anúncio.	Resposta fornecida pelo Google Ad Manager: Como servidor de anúncios do editor, o GAM oferece uma API leve para as SSPs com que um editor pode trabalhar para especificar as configurações de leilão dos componentes usando a API da Tag do editor do Google (GPT). Confira mais detalhes neste link. Se uma SSP fornecer uma configuração de leilão de componentes usando essa API, ela será incluída na lista de leilões de componentes para essa oportunidade de anúncio. O GAM não impõe restrições aos leilões de componentes incluídos. As SSPs que quiserem realizar um leilão de componentes poderão fazer isso, desde que o editor tenha permitido a execução do código necessário na página do editor.
Leilões de componentes	O GAM pode aplicar um valor mínimo específico e não divulgado a cada lance vencedor do leilão de componentes.	Resposta fornecida pelo Google Ad Manager: O GAM manteve o foco na imparcialidade do leilão há anos. Para manter um leilão justo e transparente, não aceitamos preços mínimos que se apliquem apenas a segmentos específicos de demanda. Esse é um princípio consistente no nosso produto e continuará sendo assim para os leilões da API PA.
Servidores de anúncios de terceiros	Os servidores de anúncios de terceiros não teriam acesso à participação do Google no leilão de nível superior, limitando a capacidade de se beneficiar da demanda de SSP do Google no contexto da API PA.	Resposta fornecida pelo Google Ad Manager: Atualmente, o GAM é compatível com o teste da API PA com vários vendedores usando a API descrita aqui. A participação do GAM como um leilão de componentes em outros leilões de nível superior não está disponível no momento.
(Também informado nos trimestres anteriores) Desempenho de leilões da API PA	Informe dos testadores que os leilões da API PA têm alta latência.	Ouvimos preocupações sobre latência, e isso é parte do motivo pelo qual desenvolvemos uma série de recursos como parte da API PA, que possibilitarão que as SSPs definam limites de latência de DSP e façam melhorias que possam diminuir a latência. Recentemente, atualizamos nosso guia de práticas recomendadas para latência, que inclui mais informações sobre como aproveitar esses recursos. Também continuamos a desenvolver novas melhorias de latência. Algumas delas podem ser conferidas neste link.
(Também informado nos trimestres anteriores) Renderização de vídeo	Suporte à renderização de vídeos usando a API PA e Fenced Frames.	Em janeiro, publicamos uma demonstração de como os vídeos in-stream podem funcionar em um leilão de anúncios privados (em inglês) com mais detalhes sobre abordagens alternativas. Também observamos que os players do ecossistema começam propondo como a renderização de vídeos funciona para os parceiros que se integram a eles, como as propostas do GAM para a construção de renderURL compatível com vídeos ou o processo completo de E2E. Além disso, estamos ouvindo o feedback do ecossistema sobre as mudanças que podemos fazer para aumentar a adoção, e uma dessas mudanças está detalhada no GitHub. Permanecemos ativamente engajados com o ecossistema para identificar outros obstáculos à adoção que podemos encontrar e resolver em tempo hábil.
(Também informado nos trimestres anteriores) Política de tratamento de dados	Qual é a política de tratamento de dados para a API IGs / PA?	No design da API PA, todos os dados armazenados em IGs ou sobre o que as pessoas estão neles (i) permanecem no dispositivo ou (ii) são processados nos serviços de lances e leilões (B&A) executados em um ambiente de execução confiável (TEE). Em ambos os casos, os dados não podem ser lidos por terceiros nem usados de outra forma que não seja para produzir lances no leilão. Algumas melhorias de privacidade que o Chrome está explorando envolvem a interação com um servidor de k-anonimato gerenciado pelo Google. Essa interação está sendo cuidadosamente desenvolvida para evitar o compartilhamento de informações sobre os usuários e para ser executada em um TEE para garantir a paridade de informações em todo o ecossistema de anúncios. O Google se comprometeu com a CMA para elaborar e implementar as propostas do Sandbox de privacidade de uma forma que não distorça a concorrência ao dar preferência aos negócios do Google e considerar o impacto na concorrência na publicidade digital e para editores e anunciantes. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho cumpra essas obrigações.
(Também informado nos trimestres anteriores) Ciclo de vida do IG	Peça para aumentar a vida útil do IG de 30 para 90 dias.	Essa mudança requer uma avaliação cuidadosa, comparando os benefícios para o setor com o impacto sobre os usuários do Chrome e outras partes interessadas. Estamos considerando essa solicitação e receber feedback neste link.
(Também informado nos trimestres anteriores) ModelingSignals	Solicite um novo campo além dos modelSignals que só podem codificar informações de exibição e clique.	Respondemos a esse feedback com uma contraproposta neste link. Estamos sempre envolvidos com o setor para entender a opinião deles sobre nossa proposta. No momento, estamos avaliando os benefícios para o setor em relação ao impacto sobre os usuários do Chrome e outras partes interessadas.
Bits adicionais em reportWin()	Forneça bits adicionais em reportWin() do limite atual de 12 antes do 3PCD.	No momento, estamos avaliando abordagens para oferecer suporte a esse caso de uso. Está demorando um pouco, porque também estamos procurando abordagens que ajudem a garantir a criação de um plano de privacidade de longo prazo.
Design de leilão	Solicitações para um único leilão que retorna URLs de renderização com a pontuação correspondente.	O compartilhamento de vários URLs de renderização e a respectiva pontuação de um único leilão de PA é algo que consideramos, mas não implementamos por questões de privacidade. Entendemos o desejo de evitar mostrar o mesmo anúncio várias vezes a um usuário em uma única página e aceitamos mais discussões no GitHub.
reportWin	registrar campos arbitrários na função reportWin().	Isso já está acontecendo hoje durante o período de teste. Depois que o suporte ao Chrome for descontinuado, a versão forDebuggingOnly da API será migrada para ativar a depuração com amostragem reduzida, que é especificada aqui.
Vendedores de componentes	Ter um mecanismo independente para contar as próprias impressões e outros eventos, sem depender apenas dos relatórios de adtechs.	Essa solicitação de recurso está na nossa fila para descoberta posterior. Não esperamos resolver o problema durante o período de teste facilitado pelo Chrome.
Faturamento de custo por clique	Implementar o faturamento de custo por clique na API PA.	Estamos considerando essa solicitação aqui. No momento, ela é uma solicitação de sugestões sobre como implementá-la na plataforma atual da API.
browserSignals	Adição de inputBidInSellerCurrency ao relatório de especificação browserSignals do vendedor.	Estamos considerando essa solicitação e receber feedback neste link.
Suporte a metadados de compra e propriedade de lógica para não DSPs	O design atual da API pode levar a uma mudança significativa nas campanhas de nova segmentação no nível do produto, em que as campanhas podem precisar migrar para plataformas que servem como provedores de DSPs e de DCO.	Estamos discutindo o problema e agradecemos seu feedback aqui .
Suporte a metadados de compra e propriedade de lógica para não DSPs	Compartilhe exemplos em que a DSP não é proprietária do IG.	Sabemos que quem não é um bidder quer usar algumas funcionalidades do IG, mas não outras. Estamos avaliando ativamente as opções para abordar esses casos de uso e agradecemos seu feedback aqui.
Controles de tempo limite	Os editores devem poder determinar o número de IGs que podem participar e o tempo limite de nível superior / global.	Entendemos que há uma necessidade de controles de tempo limite e visibilidade entre o vendedor de alto nível e o de componentes e estamos considerando essa solicitação.
Vários anúncios	Compatibilidade com a API PA para casos de uso de vários tamanhos de anúncio.	Estamos considerando essa solicitação e receber feedback do ecossistema.
Documentação	Existe uma lista de atributos IG sujeitos a k-anonimato?	Nós respondemos a essa pergunta aqui.
Depuração	Recursos de depuração aprimorados para a API PA.	Reconhecemos a importância de ferramentas robustas de depuração para desenvolvedores que trabalham com a API PA. Temos o compromisso de melhorar a experiência do desenvolvedor, explorando maneiras de integrar melhor as buscas de arquivos .well-known com as ferramentas para desenvolvedores. Nosso objetivo é fornecer mais recursos de visibilidade e solução de problemas dentro do ambiente de desenvolvimento. Estamos discutindo mais esse problema aqui e agradecemos seu feedback.
Rótulos	Todos os usuários nos marcadores de tratamento do modo B têm as APIs do Sandbox de privacidade ativadas?	As atribuições de grupos experimentais do Chrome são determinadas aleatoriamente e independentes das configurações do Chrome configuradas pelo usuário. Embora essas APIs possam estar disponíveis para usuários em grupos de tratamento específicos (por exemplo, treatment_1.*), a funcionalidade delas pode ser modificada ou desativada nas configurações do Chrome. Grupo control_2 do modo B: a inclusão neste grupo desativa inerentemente as APIs de relevância e medição do Sandbox de privacidade, e essa configuração não pode ser substituída pelo usuário nas configurações do Chrome.
Uso do API	A chamada para reportWin() e a renderização do anúncio estão acontecendo em paralelo ou em sequência?	reportWin() é chamado logo após a conclusão de runAdAuction(). Ao mesmo tempo, o processo de renderização do anúncio pode começar quando o resultado do leilão é colocado em um iframe ou frame isolado. Depois que reportWin() terminar a execução e o anúncio começar a ser renderizado, os URLs fornecidos para sendReportTo() serão buscados.
(Também informado nos trimestres anteriores) Suporte do Teste A/B	Solicite suporte para o teste A/B da API PA.	Estamos discutindo a solicitação aqui e agradecemos seu feedback.
Modelagem de tráfego	A proposta do Google para gerenciar a tomada de decisão necessária usando o servidor KV não é útil, porque os vendedores não conseguem interagir com o back-end, o que dificulta a modelagem de tráfego.	Conforme discutido no problema do GitHub, expor se DSPs individuais têm IGs presentes pode causar preocupações com as impressões digitais do usuário. Sugerimos outras alternativas nesse problema e estamos abertos a sugestões.
Modelagem de tráfego	Mecanismos de armazenamento em cache adicionam uma camada significativa de complexidade e evita que as DSPs saibam o verdadeiro formato de tráfego para o qual fazeriam lances.	O mecanismo de armazenamento em cache era simplesmente oferecido como sugestão. As adtechs podem escolher as sugestões mais adequadas para cada caso de uso. Acesse este link para mais detalhes.
Rótulos	O Chrome precisa compartilhar o rótulo como um parâmetro nas solicitações aos servidores confiáveis do comprador e do vendedor.	Essa parece ser uma solicitação razoável, já que parece estar amplamente alinhada com o objetivo de uso responsável dos dados do IG. No entanto, estamos analisando o pedido e estamos sujeitos a análise interna. Vamos atualizar essa informação publicamente à medida que as discussões progredirem.
Uso do API	Esclarecimento da definição explícita do grupo "control_1" no documento "Orientações adicionais da CMA para terceiros em testes". Especificamente, é preocupante que uma mudança no texto possa ser mal interpretada como a exigência da exclusão de todas as APIs do Sandbox de privacidade de control_1.	Já mostramos o que pensamos sobre isso nesta conversa do GitHub. Dito isso, não podemos falar em nome da CMA e sugerimos levantar dúvidas sobre a interpretação das orientações sobre testes diretamente com ela.
Uso do API	O Chrome permitirá a chamada de joinAd InterestGroup() em uma página em branco ao redirecionar para outro recurso?	Se um usuário estiver visitando algum site, o proprietário poderá delegar a capacidade de chamar joinAd InterestGroup a um terceiro. Essa delegação permite que terceiros criem IGs sem precisar adicionar nenhum tipo de redirecionamento por meio de uma página em branco. Agradecemos feedback sobre motivos específicos para criar IGs no meio de um redirecionamento, em vez de usar o mecanismo de delegação pretendido.
Uso do API	As trocas devem poder gravar IGs nas páginas dos editores com quem trabalham e, então, delegar a permissão de lance nesse IG a qualquer comprador ou DSP.	Recebemos o feedback e estamos avaliando se essa solicitação pode ser atendida. Gostaríamos de receber mais feedback do ecossistema.
Uso do API	Não haverá notificação de perda de depuração se ninguém vencer um leilão da API PA.	As funções reportWin e reportResult do Chrome foram criadas para gerar relatórios de vitórias no nível do evento no sistema de leilão de privacidade (PA, na sigla em inglês). Nas circunstâncias em que todos os lances são rejeitados durante um leilão de PA, não é esperado que essas funções sejam invocadas, já que não foi determinado um vencedor. Uma atualização recente do Chrome pode explicar discrepâncias em que os URLs transmitidos para forDebuggingOnly.reportAdAuctionLoss() não aparecem no painel "Network" do DevTools. Recomendamos que você verifique essa funcionalidade usando o build do Canal de Desenvolvedor ou Canary do Chrome.
Uso do API	O adCost retornado de generateBid pode ser negativo (ele já está estocasticamente arredondado para 2 bytes)?	AdCost é o custo de conversão ou clique do anunciante passado de generateBid() para reportWin(). Esse valor pode ser Nulo ou duplo. Valores negativos serão ignorados e não transmitidos. O valor será estocasticamente arredondado quando transmitido.
Melhoria da API	Os servidores de execução confiável e criptografada podem ser usados para lidar com segmentação / coortes / atribuição e leilões em vez do navegador Chrome?	Recomendamos analisar os componentes e as opções baseados no TEE na API PA (por exemplo, servidores KV e B&A Services), assim como os componentes do TEE do Relatório de atribuição e da agregação privada (por exemplo, o Serviço de agregação) que abordam essa questão.
Melhoria da API	A resposta do leilão do Sandbox de privacidade pode ser uma resposta do lance (como os lances de cabeçalho) em vez de uma resposta do anúncio (como tags de anúncio)?	Esse tipo de alteração altera fundamentalmente as propriedades de privacidade da API PA, por isso não estamos considerando a possibilidade.
Controles do editor	Os editores podem bloquear criativos da API PA nas páginas deles?	O Chrome tem uma proposta para a verificação de criativos em tempo real que ainda não está disponível para testes. Embora esse recurso ainda não esteja disponível, observamos que a maioria das SSPs criou soluções para possibilitar isso.
Uso do API	Qual é o limite de tamanho para perBuyerSignals?	Na forma clássica, o perBuyerSignals não tem limitações de tamanho inerentes no Chrome. As principais restrições são que os dados permaneçam serializáveis por JSON e não causem consumo excessivo de memória. No entanto, vale lembrar que indicadores de “perBuyerSignals” muito grandes e complexos podem afetar negativamente a performance. Há um método alternativo para transmitir indicadores "perBuyerSignals" por meio de "directFromSellerSignalsHeaderAdSlot". Essa abordagem transmite indicadores perBuyerSignals dentro de um cabeçalho, sujeito a um limite de tamanho máximo de 10 KB para toda a resposta do cabeçalho. Além disso, servidores individuais podem impor suas próprias restrições sobre o tamanho máximo do cabeçalho.
Documentação	A documentação sobre a chamada registerAdBeacon de generateBid precisa ser alterada.	Atualizamos esta documentação em 17 de fevereiro.
Uso do API	Como o reportEvent escolhe o URL de beacon correto entre as várias opções registradas?	Cada leilão resulta em uma configuração diferente, que, por sua vez, resulta em um mapa de relatórios separado. Os leilões individuais (e os frames resultantes) são completamente separados entre si e não compartilham dados. A explicação sobre "Relatórios de anúncios com limites" fornece mais detalhes sobre esse assunto.
interface do Chrome	Adicione um filtro na guia "Aplicativo -> "Grupos de interesse" do Chrome DevTools, permitindo filtrar por proprietário do IG (ou talvez também pelo nome).	Estamos avaliando essa solicitação e esperamos receber mais feedback do ecossistema.
versão headless do Chrome	Suporte à API PA no Headless Chrome.	Há alguns componentes da API PA vinculados ao Chrome, como as chamadas de k-anonimato aos servidores do Google, que podem não funcionar no "antigo" Headless Chrome. Acreditamos que isso pode ser resolvido pela "nova" versão do Headless Chrome, lançada no Chrome 112.
Uso do API	No caso de relatórios de perda com reportAdAuctionLoss, vemos o "topLevelWinningBid=0" em muitos casos. Qual é a interpretação disso?	O valor topLevelWinnerBid origina-se da função scoreAd() no componente de vendedor de nível superior. Esse valor desempenha um papel para determinar o resultado do leilão de nível superior. De acordo com a explicação, um valor de topLevelWinningBid de zero ou qualquer número negativo significa que o anúncio correspondente não está qualificado para vencer o leilão. Esse mecanismo pode ser empregado, por exemplo, para filtrar anúncios segmentados por grupo de interesse que não superam um candidato segmentado por contexto. Embora um topLevelWinningBid com valor zero possa indicar a prevalência de um leilão contextual, a especificação da API PA reconhece que outros fatores podem contribuir para esse resultado.
Teste A/B do modo	Esclarecimento sobre a seleção de tráfego nos modos B e A e solicitações de recusa.	Os critérios de inclusão para os modos A e B são os mesmos. O objetivo é ter grupos que representem o tráfego normal do Chrome, desde que sejam compatíveis com as APIs do Sandbox de privacidade e o método de rotulagem. Por isso, algumas configurações de clientes não são compatíveis. Para os fins do experimento, é importante comparar apenas o tráfego rotulado a outros tipos de tráfego rotulados. Os usuários no modo B têm o recurso de proteção contra rastreamento ativado e, assim, recebem uma notificação sobre ele.
Melhoria da API	"lifetimeMs" pode ser incluído como uma propriedade direta na chamada joinAd InterestGroup ou gerenciá-lo como um argumento separado?	Estamos analisando cuidadosamente o feedback da comunidade de desenvolvimento da Web sobre a funcionalidade "joinAd InterestGroup" na proposta da API PA. Um ponto importante da discussão é o método ideal para gerenciar o ciclo de vida do IG. Estamos avaliando os benefícios de um argumento separado para o parâmetro "lifetimeMs", já que ele promove flexibilidade e adaptabilidade para possíveis melhorias futuras na especificação. Estamos discutindo esse problema aqui. Seu feedback é importante para nós.
Uso do API	Potencial para aumento das taxas de falsos negativos no framework da API PA devido a colisões com IDs de navegador de baixa entropia.	A equipe do Chrome está ativamente envolvida no refinamento contínuo da estrutura da API PA. Agradecemos a discussão sobre possíveis taxas de falsos negativos decorrentes de conflitos de ID do navegador. Estamos avaliando cuidadosamente esse feedback e trabalharemos para garantir que as análises atualizadas reflitam de maneira abrangente todos os fatores relevantes. Nosso compromisso é com uma solução que alcance os resultados de privacidade desejados, mantendo a precisão e a confiabilidade. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	É necessário um identificador de navegador de baixa entropia para evitar que os clientes enviem repetidamente solicitações "Join" para o mesmo objeto em um sistema de k-anonimato?	Reconhecemos e valorizamos a discussão contínua sobre o uso de identificadores de navegadores na implementação de sistemas de k-anonimato. Entendemos as preocupações levantadas sobre as possíveis implicações de privacidade desses identificadores. Embora nossa implementação inicial tenha empregado um identificador de baixa entropia como mecanismo antiabuso, estamos explorando ativamente técnicas alternativas, como tokens de contagem anônimos, que priorizam a privacidade do usuário mantendo a integridade do sistema. Temos o compromisso de encontrar soluções que equilibrem o uso responsável de dados com proteções robustas de privacidade. Por isso, o diálogo contínuo com a comunidade de pesquisa é bem-vindo. Estamos discutindo isso aqui. Seu feedback é sempre bem-vindo.
Uso do API	A tecnologia AMP (Accelerated Mobile Pages) é compatível com a API PA?	No momento, as AMP não têm compatibilidade nativa com a API PA. Queremos receber mais feedback do ecossistema se o suporte a AMP for uma prioridade.
Melhoria da API	Considere remover o tipo das verificações de k-anonimato.	Estamos considerando cuidadosamente o feedback sobre potencialmente otimizar as estruturas de solicitação de k-anonimato. Entendemos a sugestão de consolidar os parâmetros e possivelmente unificar os tipos para otimizar o processo. Nosso objetivo é garantir a eficiência e a manutenção, e estamos avaliando todas as opções à medida que continuamos a desenvolver nossas soluções de privacidade. Estamos discutindo esse problema aqui. Seu feedback é importante para nós.
interface do Chrome	Pedido de mecanismo para usuários com menos conhecimento técnico acessarem e gerenciarem facilmente os IGs a que pertencem, incluindo possíveis controles no nível do site para desativação.	Reconhecemos a importância de oferecer ferramentas fáceis de usar para entender e gerenciar os IGs. Analisamos cuidadosamente vários métodos e concluímos que identificar IGs pelo site em que eles foram unidos oferece o melhor equilíbrio entre clareza e proteção de privacidade. Atualmente, o gerenciamento global de IGs está localizado nas configurações do Chrome. Estamos continuamente explorando maneiras de melhorar ainda mais a experiência do usuário nessa área. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Segurança da API	A API PA é vulnerável a vazamentos de privacidade devido a interações criativas com anúncios, mesmo no contexto de Fenced Frames?	Reconhecemos o potencial de vazamento de informações por meio de interações sofisticadas com anúncios. Estamos investigando ativamente a interação entre Fenced Frames, API PA e possíveis vetores de ataque. A mitigação dos riscos de privacidade é uma prioridade, e temos o compromisso de desenvolver soluções robustas que equilibrem inovação com proteção do usuário. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Latência	O tempo limite padrão de 50 ms para a lógica de lances do comprador é um valor realista?	Reconhecemos as preocupações levantadas sobre possíveis inconsistências entre a especificação e o momento das solicitações de rede para a lógica de lances. Estamos revisando ativamente as especificações para garantir a precisão e investigando as configurações ideais de tempo limite padrão para equilibrar o desempenho e a viabilidade. Estamos discutindo esse problema aqui. Seu feedback é importante para nós.
Documentação	Possível vazamento de tempo na especificação em que um site poderia inferir se um anúncio falhou no limite de k-anonimato e possíveis implicações para o rastreamento entre sites.	Entendemos o problema relacionado a um possível vazamento de tempo. Confirmamos uma discrepância na especificação e estamos tomando medidas para garantir que o status de k-anonimato dos anúncios seja determinado antes do leilão para evitar esse tipo de vazamento. Levamos essas preocupações a sério e vamos atualizar a especificação para refletir essas mudanças. Estamos discutindo esse problema aqui. Seu feedback é importante para nós.
Uso do API	Formas de implementar uma lista de bloqueio de SSP na API PA.	Reconhecemos a necessidade de mecanismos para gerenciar restrições de anúncios pelas SSPs. Incentivamos a busca de soluções que priorizem a avaliação no dispositivo e aproveitem os metadados de anúncios atuais para proteger a privacidade do usuário e, ao mesmo tempo, possibilitar a flexibilidade. Temos o compromisso de trabalhar com os desenvolvedores para identificar as abordagens ideais na API PA. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Alguém pode pedir ao navegador para fingir usar a API PA de uma maneira que os sites não possam detectar?	Reconhecemos que, na forma atual, a desativação da API PA pode ser detectada por sites. Estamos trabalhando em recursos como lances adicionais e segmentação negativa, além da renderização de frames cercados, para aumentar a privacidade e oferecer opções de desativação indetectáveis. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Teste A/B do modo	Tráfego do data center que parece ser tratamento 1.1.	A equipe do Chrome confirmou com a equipe do GAM que esse tráfego está sendo filtrado do experimento. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Eficiência e imparcialidade na implementação de interestGroupBuyers na API PA.	Reconhecemos a discussão contínua sobre a eficiência e a imparcialidade do campo "interestGroupBuyers" nos leilões da API PA. Reconhecemos as vantagens e desvantagens entre eficiência, privacidade e imparcialidade no mercado. Embora os vendedores precisem gerenciar as relações comerciais com os compradores, estamos explorando maneiras de otimizar o processo de correspondência. Isso pode incluir ajustes dinâmicos com base em dados em tempo real e modelos híbridos. Continuamos comprometidos em encontrar soluções que priorizem a privacidade do usuário e ofereçam suporte a um ecossistema de publicidade competitivo. Estamos discutindo esse problema aqui e agradecemos seu feedback.
interface do Chrome	Possíveis problemas de memória e clareza da interface relacionados ao IG no Chrome.	Entendemos as preocupações levantadas sobre a exibição de IGs no DevTools. A visualização atual reflete todos os eventos do IG para rastreamento do histórico, mas reconhecemos a importância de fornecer uma visibilidade mais clara do estado atual dos IGs armazenados. Vamos explorar as otimizações e possíveis melhorias na interface para aprimorar os insights dos desenvolvedores. Em relação ao gerenciamento de memória, a implementação do IG foi criada para evitar vazamentos de memória. No entanto, monitoramos e otimizamos continuamente o uso de recursos. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Documentação	O autor da postagem original encontrou um erro ao tentar usar tamanhos de anúncios nomeados diretamente no campo "sizeGroup" da função "joinAd InterestGroup". Eles querem saber se esse é o comportamento esperado.	Reconhecemos a importância de simplificar a configuração de anúncios na função "joinAd InterestGroup". Estamos trabalhando ativamente para resolver essa limitação e planejamos ativar essa funcionalidade em atualizações futuras. Essa melhoria está de acordo com nosso compromisso de fornecer aos desenvolvedores ferramentas flexíveis e eficientes para o gerenciamento de anúncios. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Rótulo de teste facilitado pelo Chrome	Solicite dados diretos sobre o Modo A vs. B e rótulos exatos em sendReportTo para que possamos acompanhar o experimento de forma consistente.	Estamos discutindo a solicitação aqui e agradecemos seu feedback
Documentação	O nome de domínio do vendedor está incluído nas solicitações feitas ao servidor confiável do vendedor para fins de validação?	Confirmamos a omissão inicial do parâmetro do nome do host na documentação da API Protected Audience KV Server. Queremos garantir aos desenvolvedores que o nome de domínio do vendedor é incluído automaticamente nas solicitações feitas ao servidor confiável do vendedor. Essa funcionalidade é essencial para processos robustos de validação de anúncios. Atualizamos a documentação para resolver esse problema e continuaremos a priorizar a clareza e a transparência para a comunidade de desenvolvedores. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Possíveis métodos para incluir o nome "IG" nas chamadas de rastreamento de impressões de anúncios para fins de geração de relatórios.	Temos o compromisso de equilibrar a necessidade de mecanismos robustos de denúncia com o princípio fundamental da privacidade do usuário. A inclusão de nomes de IG no rastreamento de impressões de anúncios está sujeita às salvaguardas de k-anonimato criadas para impedir a identificação de indivíduos. Vamos continuar explorando soluções inovadoras de geração de relatórios com essas restrições de privacidade. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Recurso da API	Solicitação para que o servidor confiável do comprador receba cabeçalhos HTTP de dicas do cliente.	Estamos acompanhando essa solicitação de recurso aqui.
Uso do API	Se o arquivo de delegação precisa exigir que o cabeçalho "Access-Control-Allow-Origin" seja carregado, já que ele determina o comportamento de associação do IG para o navegador?	Temos o compromisso de seguir as práticas recomendadas de segurança na Web. O requisito do cabeçalho "Access-Control-Allow-Origin" para arquivos de delegação garante a consistência com os princípios do CORS e evita a exposição não intencional de informações sensíveis. Estamos estudando maneiras de otimizar esse processo e, ao mesmo tempo, manter uma forte postura de segurança. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Permite que os servidores de anúncios personalizem criativos na estrutura da API PA.	Sabemos o papel que os servidores de anúncios podem desempenhar na personalização de criativos. Estamos buscando soluções para capacitar os servidores de anúncios na API PA, como o modelo "junto de IG" em que a lógica de lances e seleção de criativos de anúncios pode ser combinada. Nosso objetivo é encontrar um equilíbrio entre ativar recursos eficientes de criativos de anúncios e proteger a privacidade do usuário. Agradecemos mais colaboração e feedback sobre a evolução da API para atender às necessidades de todas as partes interessadas aqui.
Preocupações sobre privacidade	Disponibilidade de identificadores alternativos (por exemplo, RampID, ID5) em solicitações de lance contextual podem prejudicar as metas de privacidade da API PA facilitando a coleta de dados entre sites.	Reconhecemos a possível tensão entre identificadores entre sites e os objetivos de privacidade da API PA. Embora os editores possam optar por compartilhar esses identificadores, o design da API PA tem como objetivo fundamental separar a seleção de anúncios da necessidade de rastreamento entre sites. Temos o compromisso de promover um ecossistema de publicidade centrado na privacidade e incentivamos os desenvolvedores a priorizar a abordagem da API PA. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Armazenamento em cache	É possível impedir a reutilização de scripts de lances em vários leilões?	Reconhecemos o comportamento de armazenamento em cache observado dos scripts de lances no framework da API PA. Embora os mecanismos padrão de armazenamento em cache HTTP sejam compatíveis, existe a possibilidade de reutilização de scripts em leilões devido ao comportamento de suspensão do dispositivo e ao design dos executores de lances. A equipe está investigando soluções para oferecer aos compradores maior controle sobre o armazenamento em cache de scripts para gerenciar as estratégias de lances com eficiência. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Centralize os relatórios de atividade de lances em todos os IGs para uma DSP, respeitando a privacidade do usuário.	Priorizamos a privacidade do usuário ao criar a API PA. Embora os relatórios diretos de eventos de lances individuais não sejam viáveis devido a riscos de rastreamento entre sites, oferecemos mecanismos como armazenamento compartilhado e agregação particular. Isso permite que as DSPs recebam insights agregados sobre a atividade de lances de uma maneira que preserva a privacidade do usuário.
Uso do API	A busca de sendReportTo() em reportResult() só ocorre 94% do tempo em relação ao recebimento de uma busca registrada com forDebuggingOnly.reportAdAuctionWin().	Embora não tenham o mesmo tempo, é possível buscar os dois URLs ao mesmo tempo. Em alguns casos, o worklet do vendedor do componente foi descartado e precisa ser recarregado para executar a função reportResult(). No entanto, o tempo para buscar a lógica de pontuação nem para o recarregamento da worklet afetam o tempo limite de 50 ms do reportResult(). O Chrome usará cabeçalhos de armazenamento em cache para definir o comportamento de busca nos casos em que o worklet precisar ser recarregado. Saiba mais sobre as fases de um leilão de PA aqui.
K-anonimato	Solicitação de confirmação de que o nome do interestGroup não afeta o k-anonimato da veiculação de anúncios.	Para que um criativo seja considerado k-anônimo, a tupla do URL do proprietário de IG, do URL do script de lance, do URL do criativo e do tamanho do anúncio precisa atingir o limite especificado (k) em um período anterior (w). O status de k-anonimato é atualizado periodicamente (p).
interface do Chrome	Proposta de fornecimento do tipo de "visibilidade interna" que muitas estruturas MVC, ORM etc. oferecem. Por exemplo, comece com o registro simples dos eventos internos selecionados em um novo painel na seção Ferramentas de desenvolvedor --> Aplicativo --> Aplicativo	Estamos discutindo a proposta aqui e agradecemos seu feedback.
interface do Chrome	A mesclagem do IG no Ferramentas para Desenvolvedores não mostra elementos relacionados à prioridade.	Resolvemos esse problema aqui.
Melhoria da API	É preferível permitir que o servidor de anúncios do criativo rastreie seus próprios eventos. É possível configurar uma lista de domínios de acompanhamento permitidos?	Compartilhamos uma proposta aqui e convidamos qualquer feedback adicional do ecossistema.
Solicitação de recurso de API	A API PA pode ser estendida para oferecer suporte a transações de mídia não RTB e manter casos de uso críticos, como veiculação de anúncios e DCO?	Estamos discutindo o problema aqui e agradecemos seu feedback.
Tempo limite do leilão do editor	Os editores precisam controlar a duração do leilão para evitar a perda de impressões, especialmente em configurações de lances de cabeçalho em que os anúncios são selecionados em sequência.	Reconhecemos a importância de dar aos editores controle granular sobre o tempo limite dos leilões de anúncios. Estamos estudando como implementar um mecanismo global de tempo limite do leilão, possivelmente dentro do objeto "auctionConfig", enquanto consideramos cuidadosamente os casos extremos. Esse recurso visa otimizar as taxas de preenchimento de impressões para os editores, e continuaremos colaborando com a comunidade para encontrar a melhor solução. Estamos discutindo o problema aqui e agradecemos seu feedback.
Melhoria da API	O design atual de IGs na API PA leva a grandes tamanhos de metadados devido a URLs de renderização longos. Os testadores querem uma forma de compactar esses URLs para melhorar a eficiência.	Reconhecemos a importância de otimizar o tamanho dos metadados de IG, especialmente para leilões de anúncios que dependem da eficiência. Acreditamos que uma solução baseada em modelos para compactar renderURLs oferece um potencial significativo. Avaliaremos cuidadosamente os designs de modelo propostos e asseguraremos que qualquer solução implementada inclua mecanismos robustos de prevenção de abuso para manter a estabilidade do navegador. Colaborar com a comunidade de padrões da Web para desenvolver a abordagem ideal continua sendo uma prioridade, considerando essas considerações. Estamos discutindo o problema aqui e agradecemos seu feedback.
Uso do API	Os testadores que lidam com formatos de anúncios nativos querem otimizar o processo de leilão do Sandbox de privacidade recuperando vários resultados de anúncios em uma única chamada para reduzir a carga da rede e melhorar a velocidade de renderização do anúncio.	Reconhecemos as questões de desempenho levantadas para a renderização de anúncios nativos no Sandbox de privacidade. Temos o compromisso de encontrar um equilíbrio entre eficiência e proteções sólidas da privacidade do usuário. Embora a exibição de vários anúncios com pontuações completas comprometa a privacidade, estamos explorando maneiras de otimizar o processo de leilão. Estamos dedicados a melhorar o suporte à API PA para formatos de anúncios nativos e investigar mecanismos alternativos para melhorar a eficiência dentro das fortes restrições de privacidade do Sandbox de privacidade. Estamos discutindo o problema aqui e agradecemos seu feedback.
Uso do API	Flexibilidade na forma como os lances de anúncios são pontuados e classificados no Sandbox de privacidade, principalmente para representar níveis de prioridade ou regras de mercado privado.	Entendemos a necessidade de um controle detalhado sobre a pontuação e classificação de anúncios no Sandbox de privacidade, especialmente em cenários de lances complexos. Reconhecemos as soluções propostas usando tuplas e funções matemáticas para alcançar pontuação multidimensional sem sacrificar a privacidade do usuário. Embora essas abordagens possam aumentar a complexidade para os desenvolvedores, elas oferecem a expressividade necessária. Estamos comprometidos em explorar maneiras de otimizar esses processos, possivelmente com funções ou diretrizes auxiliares, para garantir o uso otimizado dos recursos do Sandbox de privacidade para a lógica avançada de leilão. Estamos discutindo esse problema aqui e agradecemos seu feedback.
reportEvent()	Adicione um novo evento reservado (talvez um beacon automático) acionado pelo navegador assim que um frame com um criativo for inicializado.	Estamos discutindo a solicitação aqui e agradecemos seu feedback.
adCost	Permissão de detalhamento do adCost.	Cada valor de custo é uma oportunidade de enviar uma quantidade limitada de informações do leilão. Permitir uma lista inteira de N desses custos seria suficiente para enviar um identificador de usuário completo, o que permitiria o rastreamento entre sites. Estamos discutindo isso aqui e agradecemos seu feedback.
resolveToConfig	O resolveToConfig deve ser herdado do nível superior e exposto no browserSignals?	Estamos discutindo a solicitação aqui e agradecemos seu feedback.
Ferramentas melhores	Existe algo semelhante a chrome://topics-internals, mas para a API PA?	Não há nada exatamente igual. No entanto, existem ferramentas abrangentes para desenvolvedores para a API PA.
Rótulos	O Chrome pode usar rótulos para identificar a população de 20% k-anonimato?	Estamos considerando essa solicitação e receber feedback do ecossistema.
Documentação	Os Worklets de leilão do Sandbox de privacidade vão se tornar um tipo padrão?	Devido aos requisitos exclusivos de privacidade e segurança, esses worklets são significativamente diferentes dos tipos de worklet padrão do navegador. Portanto, não prevemos que eles se tornarão tipos de worklet padrão na especificação HTML em breve. Temos o compromisso de aprimorar nossos recursos para desenvolvedores com explicações claras sobre o ambiente de implementação e execução dos worklets de leilão, tornando essas informações mais acessíveis para os participantes do Sandbox de privacidade. Discutimos isso em mais detalhes aqui.
Servidor de chave-valor (KV) de servidor próprio (BYOS, na sigla em inglês)	As partes podem aprender vários IGs (do mesmo proprietário) reunidos por um usuário por meio de consultas de serviços KV em uma configuração do serviço BYOS KV.	Isso não será mais possível quando os servidores KV forem executados em TEEs e poderemos garantir que eles sigam o modelo de confiança publicado.
userBiddingSignals	atualiza parte de "userBiddingSignals" enquanto mantém outros.	Isso já é possível sem a necessidade de alterações na API.
Uso do API	Implemente o limite de frequência em vários IGs no Sandbox de privacidade, possivelmente usando o servidor KV ou dados "prevWinsMs" modificados.	Reconhecemos o desejo de ter recursos avançados de limite de frequência no Sandbox de privacidade. Sabemos que as restrições atuais quanto ao compartilhamento de dados nos IGs podem apresentar desafios na implementação dessas estratégias. Embora o servidor KV ofereça um possível mecanismo com as proteções de privacidade adequadas, recomendamos que os desenvolvedores explorem soluções em um único modelo IG. Estamos discutindo esse problema aqui e agradecemos seu feedback.
Uso do API	Os vendedores dos componentes (aqueles que participam de leilões aninhados no Sandbox de privacidade) precisam ter visibilidade dos tempos limite do leilão de nível superior para otimizar as próprias configurações e evitar atrasos desnecessários.	Reconhecemos a necessidade de melhorar a coordenação do tempo limite entre os principais vendedores e os vendedores de componentes no Sandbox de privacidade. Estamos investigando ativamente a adição de novos mecanismos de tempo limite, incluindo um possível tempo limite de leilão inteiro e explorando maneiras de aplicar tempos limite de nível superior a leilões de componentes. Nosso objetivo é melhorar a eficiência e a previsibilidade para todos os participantes no processo de leilão do Sandbox de privacidade. Estamos discutindo esse problema aqui e agradecemos seu feedback.

Serviços de público-alvo protegido

Tema do feedback	Resumo	Resposta do Chrome
Ambientes de execução confiáveis (TEEs)	É mais caro executar os TEEs em nuvens públicas do que em data centers de adtech no local?	Nossa resposta é semelhante aos trimestres anteriores: Nosso modelo de segurança TEE atual se beneficia das práticas de implementações de nuvem pública. Em particular, os TEEs atuais baseados em hardware não protegem contra todos os ataques físicos. Nossos provedores de nuvem pública com suporte, AWS e GCP, projetaram e implementaram mitigações de riscos de acesso físico, inclusive de funcionários. Confira mais detalhes abaixo sobre o suporte no local. As adtechs nos mencionaram que a execução de serviços na nuvem é mais cara do que os data centers locais. Não podemos avaliar essas afirmações, mas aceitamos outros feedbacks sobre os custos e continuamos avaliando opções para ampliar o suporte ao TEE.
TEE	Suporte para TEEs em ambientes de nuvem não públicos	Nossa resposta é parecida com os dos trimestres anteriores: Embora continuemos analisando o suporte para outras opções além das soluções baseadas na nuvem pública, não temos planos de oferecer suporte aos TEEs no local. Neste estágio, considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações no local, acreditamos que continuar a expandir e melhorar as implantações baseadas em nuvem (por exemplo, oferecer suporte ao Google Cloud e à AWS) é o mais benéfico para o ecossistema. No entanto, gostaríamos de receber mais feedback sobre por que esse requisito é necessário e viável, considerando as restrições de privacidade e segurança.
Outros provedores de nuvem	Suporte para outros provedores de nuvem	Estamos sempre abertos a sugestões para outros provedores de nuvem, mas planejamos incluir pelo menos a compatibilidade com o GCP e a AWS quando o 3PCD for aplicado. Consulte esta explicação para mais informações.
API B&A Services	Qual é a orientação do Google para a API B&A Services? Ela vai ter prioridade acima ou abaixo do público-alvo protegido do navegador Chrome em leilões de dispositivos?	Nossa resposta é semelhante aos trimestres anteriores: Continuamos comprometidos com o design atual dos lances no dispositivo da API Protected Audience. A proposta dos serviços de B&A é testar possíveis soluções em alguns casos de uso em que a capacidade computacional ou a velocidade da rede do dispositivo sejam limitadas.
Padronização	os serviços de B&A não passaram por um processo de padronização.	A proposta de serviços de B&A está no meio de uma fase do processo de padronização, e queremos um engajamento adicional para apoiar essa meta. Começando com uma proposta (baseada em propostas anteriores), ela está sendo incubada publicamente com uma ampla discussão aberta no W3C, e desenvolvedores interessados podem começar a testá-la e fornecer feedback. Esse é o padrão comum para o desenvolvimento de recursos da Web, conforme descrito na nossa postagem do blog aqui.
Servidor KV	Exponha o URL completo ao servidor KV do comprador para segmentação contextual / de conteúdo / site.	Estamos discutindo essa solicitação aqui. Queremos receber mais feedback do ecossistema.
Documentação	A documentação de "Componentes confiáveis/aplicados x opcionais" no GitHub causa confusão para algumas adtechs que têm o próprio conjunto de imagens e infraestrutura de implantação.	Queremos melhorar a documentação sobre "Componentes confiáveis/aplicados x opcionais" e queremos saber a opinião do ecossistema se esse trabalho precisa ser priorizado.
Melhoria da API	O código de status HTTP de uma chamada do servidor KV também deve estar disponível para a função scoreAd() como parâmetro.	Estamos avaliando essa solicitação e esperamos receber mais feedback do ecossistema.
Documentação	Forneça mais informações sobre como as cargas de trabalho JS e WASM seriam tratadas exatamente com a execução da UDF.	Queremos fornecer essas informações. Se quiser mais feedback, acesse este link.
Documentação	Solicitação para atualizar o nome do repositório.	Renomeamos o repositório como " Protected-auction-key-value-service". Isso está de acordo com o termo da coleção de serviços a que ele pertence, que também tem outros repositórios, como a discussão sobre serviços de público-alvo protegidos e os repositórios de documentação dos serviços de leilão protegido.
Documentação	Removemos a referência à API Cloud Debugger em Bidding_auction_services_gcp_guide.md.	Atualizamos a documentação e removemos a referência.
Uso do API	A latência introduzida pela pesquisa KV está levando mais de 50 ms. Está demorando quase 100 ms. Você tem alguma orientação sobre o que está funcionando bem para outros vendedores? Você tem alguma sugestão de como medir os tempos limite e os tempos?	A chamada do servidor KV acontece dentro do contexto dos executores de scripts, ou seja, no ambiente protegido especial dentro do navegador Chrome. O objetivo é manter as informações nesses executores de script protegidos contra acessos que não sejam de API. Confira uma explicação detalhada aqui.
Uso do API	Há um tempo limite para o servidor KV responder em um período específico?	Os vendedores podem especificar o campo "perBuyerCumulativeTimeouts" na configuração do leilão. Esse tempo limite inclui o tempo necessário para buscar indicadores de lances confiáveis.
Latência	Como a equipe do Sandbox de privacidade está trabalhando para resolver a latência?	Para conhecer as estratégias que estamos avaliando para manter a latência dentro dos limites aceitáveis, clique aqui.

Medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Otimização manual de campanhas	A ARA não oferece suporte à otimização manual de campanhas.	Conversamos sobre esse cenário com a adtech e mostramos maneiras de usar a ARA no suporte à otimização manual da campanha. A ARA foi criada para oferecer flexibilidade e personalização de adtech para vários casos de uso. Algumas sugestões foram o uso de diferentes configurações flexíveis no nível do evento e o uso de relatórios de evento com relatórios de resumo para reduzir o impacto do ruído e atender às necessidades de otimização manual e automática. Estamos abertos a mais feedback do ecossistema sobre a personalização e a flexibilidade das configurações da ARA.
Tipo de conversão	O Google permite apenas oito tipos de conversão, o que é uma limitação.	Implementamos a maioria dos relatórios flexíveis no nível do evento, o que oferece às adtechs mais flexibilidade em termos do número de janelas de relatórios, número de relatórios de atribuição e bits de dados do acionador que podem ser usados. As adtechs podem escolher uma configuração que permita medir até 32 tipos de conversão diferentes.
Limite de eventos de relatórios agregáveis	O mínimo numérico de 20 eventos de conversão por relatório agregável não é viável para anunciantes menores com orçamento limitado.	Não há um número mínimo de eventos de conversão necessários por relatório agregável. Além disso, há várias decisões de design que podem ser tomadas para otimizar relatórios agregáveis para anunciantes menores, como mudar a estrutura ou as dimensões principais rastreadas, testar diferentes níveis de épsilon, testar frequências de lote mais longas e testar diferentes alocações de orçamento de contribuição entre metas de medição. As adtechs menores também podem combinar os relatórios de resumo de ruído para reduzir o impacto de relatórios de eventos, além de testar o impacto de relatórios de eventos menores.
Dados em tempo real	Privar as DSPs de dados em tempo real (por exemplo, em cliques, sessões e conversões) que as DSPs usam para adaptar sua estratégia de lances e melhorar a eficácia da campanha vai contra o compromisso de manter as funcionalidades existentes.	Mesmo com a ARA, os cliques e as sessões permanecem em tempo real, e as conversões sempre ocorrem após o fato, mesmo com 3PCs.
Campos ausentes	Faltam requisitos no lançamento do evento flexível completo: i) campo "Moeda" e ii) "orderID" / "TransactionID".	No momento, não planejamos oferecer suporte a um campo "Moeda" ou "ID do pedido / ID da transação" como parte do evento totalmente flexível, porque já há maneiras de fazer isso com os relatórios a nível de evento atuais. Estamos abertos a mais feedback sobre esses campos e vamos reconsiderar se houver outros casos de uso que exijam isso. Como usar o design atual da ARA para medir informações de moeda e tipo de ID do pedido: 1. Com base no feedback, a moeda é determinada pela localização geográfica do usuário, que pode ser adicionada como parte do source_event_id para determinar qual moeda foi usada. 2. Com base no feedback, o campo "ID do pedido" é necessário para garantir que as conversões e os valores não sejam contabilizados duas vezes por engano. Isso pode ser feito usando chaves de eliminação de duplicação.
Orçamento de privacidade	O Orçamento de privacidade da ARA limita a medição em várias dimensões	A ARA foi projetada para permitir que as adtechs personalizem as próprias configurações da ARA para abranger vários cenários de atribuição. Com o design atual da ARA, as adtechs vão precisar pensar no equilíbrio entre quais dimensões são mais importantes para medir e o impacto do ruído nos dados. Adicionar ruído aos dados dependendo da granularidade das dimensões que estão sendo medidas é essencial para manter a privacidade. Estamos dispostos a receber mais feedback do ecossistema sobre a capacidade de medir em diferentes dimensões, mas precisaríamos entender os casos de uso específicos que exigem isso.
Atualizar especificação	Embora o Google tenha dito que mudou de janelas de relatórios de eventos fixos para flexíveis, isso não se reflete nas especificações técnicas do Google, que ainda têm uma janela mínima de uma hora.	No momento, os relatórios flexíveis no nível do evento permitem que as adtechs mudem o número de relatórios de atribuição por evento de fonte, os bits de dados do acionador e o número/tamanho das janelas de relatórios. A ARA ainda tem uma janela mínima de uma hora para relatórios a nível de evento, o que é essencial para manter a privacidade e minimizar certos tipos de ataques de reconstrução do histórico. Como os relatórios de resumo fornecem informações agregadas, as adtechs podem ativar o recebimento de relatórios agregáveis imediatamente, sem atraso, se necessário para os casos de uso.
Design de API	A preocupação com a redução de informações nos relatórios de conversão e a adição de ruído pode afetar mais o ecossistema do que o Google.	O Google se comprometeu com a CMA a criar e implementar as propostas do Sandbox de privacidade sem distorcer a concorrência ao dar preferência à própria empresa, além de considerar o impacto na concorrência na publicidade digital para editores e anunciantes de todos os tamanhos.
Correção de atribuição	A ARA não permite que o provedor de tecnologia controle e verifique a atribuição correta.	Há muitas soluções disponíveis na ARA que oferecem recursos de verificação: 1. As adtechs podem verificar se o comportamento da ARA corresponde às expectativas: – O código do lado do cliente da ARA tem código aberto. – O código do lado do servidor da ARA também tem código aberto, e os coordenadores garantem que somente as versões permitidas do serviço de agregação possam descriptografar e processar relatórios agregáveis. 2. O Chrome ofereceu às adtechs uma biblioteca de simulação para verificar o comportamento da atribuição, em que a adtech pode testar como a ARA realiza a atribuição em um ambiente simulado. 3. A ARA é compatível com vários sinais de depuração que ajudam a verificar se o processamento esperado e o motivo disso podem não ter ocorrido.
(Também informado nos trimestres anteriores) Ruído	Feedback de que o nível de ruído está muito alto e está afetando a utilidade do relatório.	Conversamos com adtechs com esse mesmo feedback e conseguimos identificar maneiras de personalizar a ARA para atender melhor aos casos de uso, mesmo com ruído. Temos a documentação para desenvolvedores que contém a maioria das decisões de design e personalizações discutidas com as adtechs. O ARA foi projetado para permitir que as adtechs personalizem as próprias configurações de ARA para abranger vários cenários de atribuição. No entanto, as adtechs precisam pensar sobre o equilíbrio entre quais dimensões são mais cruciais para medir e o impacto do ruído nos dados. Estamos abertos a mais feedback do ecossistema sobre o impacto do ruído e podemos fornecer mais orientações sobre alavancas da ARA que podem ser usadas para mudar esse impacto.
Atribuição de vários domínios	Como rastrear as atribuições que têm vários domínios?	As adtechs podem redirecionar para diferentes URLs de relatórios para resolver esse caso de uso. Estamos abertos a mais feedback do ecossistema sobre esse aspecto do design da ARA.
Melhoria da API	Mude regularmente o fator de escalonamento usado ao registrar a atribuição nos relatórios de resumo da ARA.	Com base na discussão no GitHub, parece que lidar com vários fatores de escalonamento no serviço de agregação provavelmente vai resultar em uma maior quantidade de ruído adicionado aos relatórios de resumo em comparação com a funcionalidade atual. Estamos dispostos a receber mais feedback sobre a necessidade de fatores de escalonamento como parte de relatórios agregáveis, mas queremos destacar a possível compensação com o aumento do ruído. Também estamos avaliando se outros recursos futuros da ARA também podem ajudar a resolver esse caso de uso.
Uso do API	Oportunidade de unificar como os eventos de atribuição são compartilhados com todos os participantes, o que é benéfico para SSP, DSP etc.	Planejamos sincronizar com a adtech para entender melhor o feedback e as limitações que eles enfrentam.
Testar o volume de tráfego	O tráfego de teste do modo B para todo o Chrome é estável?	A inclusão em um grupo experimental não é afetada pelas configurações do Chrome, independentemente das configurações.
Documentação	Suporte a ARA para pixels.	Temos informações publicadas sobre como dar suporte a esse caso de uso e aceitamos o feedback adicional do ecossistema.
Uso do API	A ARA pode não ser atribuída à origem correta para vendedores terceirizados em plataformas de e-commerce se a conversão não for feita pelo último toque.	As empresas podem usar filtros para evitar atribuições incorretas, já que nenhum relatório de conversão será gerado. Também estamos trabalhando em uma proposta de filtragem de pré-atribuição para ajudar nesse caso de uso.
Compatibilidade com navegadores	A ARA será compatível com outros navegadores?	Aceitamos que outros navegadores adotem as APIs do Sandbox de privacidade e continuemos a dedicar tempo para discutir nossa abordagem aberta no W3C. Determinamos a interoperabilidade explicitamente como uma meta para lançar a ARA e o design da ARA que seja independente do navegador, com valores flexíveis especificados pelo fornecedor para fornecedores com diferentes posições de privacidade. Outros navegadores estão fazendo suas próprias escolhas sobre oferecer alternativas viáveis para o ecossistema de conteúdo digital e os identificadores entre sites que possam oferecer suporte a identificadores digitais entre sites. Recomendamos que o Microsoft Edge tenha indicado que será compatível com ARA.
Uso do API	Qual é o tipo de origem esperado para os registros de origem da ARA para registerAdBeacon/reportEvent (e beacons automáticos Navigation_start/commit)?	Isso depende se esses beacons são automáticos ou manuais: - reservados.* (ou seja, automáticos) para que sejam do tipo origem de navegação. - Eventos acionados manualmente para serem do tipo origem de evento.
Uso do API	O limite máximo de 20 relatórios agregáveis por fonte significa para cada evento de origem? O limite é global ou diário? Há algum plano para aumentar o limite?	O limite de 20 relatórios agregáveis por fonte é global em que é possível criar 20 relatórios para cada fonte. O limite é definido pelo navegador e não é configurável. O objetivo desse limite é evitar o abuso da proteção dos relatórios de atribuição reais com relatórios nulos. Discutimos isso em mais detalhes aqui.
Uso do API	Suporte para e-mail marketing usando ARA.	No momento, não há suporte direto para esse caso de uso na ARA (se você não controlar o site de hospedagem de e-mail). Estamos discutindo isso aqui e agradecemos seu feedback.
Epsilon	Quando o valor de épsilon para a API Aggregate será determinado?	O valor atual do épsilon pode ser configurado por adtechs até um limite predeterminado definido pelo Sandbox de privacidade (que atualmente é 64). Recomendamos testar diferentes valores de épsilon, identificar pontos de inflexão para seus próprios casos de uso e fornecer feedback. Vamos entrar em contato com as adtechs com antecedência antes de qualquer mudança nos valores do épsilon.
Melhoria da API	Oferecer suporte a um caso de uso em que o anunciante pode inserir um identificador no campo trigger_data para fazer a correspondência com dados externos de CRM e permitir que os anunciantes verifiquem a qualidade das conversões.	Estamos discutindo a solicitação e receber feedback adicional neste link.
Uso do API	Como tratar URLs de redirecionamento como URLs de destino.	Elas podem: 1. Insira o URL de destino final no campo de destino. 2. O campo "Destino" permite até três URLs, o que possibilita inserir vários URLs no campo. Para usar as duas opções, é necessário conhecer o URL de destino final. Discutimos isso em mais detalhes aqui .

Serviço de agregação

Tema do feedback	Resumo	Resposta do Chrome
Principal mecanismo de descoberta	Solicitação de um mecanismo de descoberta de chaves	Temos uma proposta de descoberta de chave e aceitamos o feedback do ecossistema sobre ela.
Uso do API	Roteiro para observabilidade no serviço de agregação	Estamos analisando opções para oferecer mais observabilidade e receber feedback do ecossistema neste link.
Melhoria da API	Solicitar a capacidade de consultar novamente relatórios.	O serviço de agregação está trabalhando em uma proposta de nova consulta em que as adtechs podem dividir o épsilon para cada relatório. Isso pode gerar mais ruído por consulta, mas vai permitir que as adtechs façam consultas novamente e mantenham a privacidade.
Melhoria da API	gostariam de associar várias origens ao mesmo ID da AWS;	O serviço de agregação agora vai permitir que vários sites sejam integrados na mesma conta de nuvem (GCP ou AWS). Isso vai permitir que as adtechs usem o mesmo enclave do serviço de agregação para processar relatórios de vários sites e várias origens nos mesmos sites.
Uso do API	Quando os lotes agregáveis falham, não há certeza se o orçamento foi consumido ou não e se é possível reprocessar o lote. Quando um serviço de agregação encontra um erro de orçamento para relatórios duplicados, os demais relatórios são perdidos. Como minimizar essa perda?	Em um cenário típico, se todo o job falhar, o orçamento não será consumido. Nos casos de uma falha rara em que o orçamento é consumido, as adtechs podem solicitar a recuperação do orçamento. Se a adtech encontrar falhas frequentes de jobs com o erro de orçamento esgotado, ela precisará confirmar a estratégia de lote. Confira as instruções sobre como agrupar corretamente os lotes e evitar erros e relatórios duplicados neste link. Seu feedback sobre a recuperação do orçamento é muito importante neste link.
Uso do API	O uso da API Private Aggregate com o acionador descrito aqui geraria um relatório agregável para cada leilão. Quais são os recursos de escalonamento do serviço de agregação?	O serviço de agregação em si não estabelece um limite máximo para o número de chaves ou relatórios em um lote, mas uma escala de 10^14 relatórios e 10^12 chaves não é aceita no momento devido à memória necessária. Nossas orientações sobre dimensionamento indicam os intervalos que testamos e recomendamos para otimizar o desempenho, considerando a carga esperada e os tipos de instâncias de VM de nuvem com suporte.
Processamento de dados	Se dados criptografados tiverem informações pessoais, qual é a disposição legal de fornecer dados criptografados ao serviço de agregação? Você pode informar se há garantia de que o coordenador não acessará os dados criptografados?	O serviço de agregação não compartilha dados criptografados / do usuário com o coordenador. O serviço de agregação usa o coordenador para a contabilidade e o gerenciamento de chaves. Confira alguns detalhes sobre o coordenador aqui. Para fins de contabilidade, o serviço de agregação só compartilha o ID compartilhado e a origem do relatório com o PBS para o consumo do orçamento. Assim que lançarmos um multisite, substituiremos origem por site. O serviço de agregação é executado em um TEE, que é o único lugar em que os relatórios de clientes podem ser descriptografados. O TEE tem código aberto e auditado por partes externas, conforme descrito aqui.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Uso do API	Os vendedores dos componentes podem enviar relatórios para vários servidores de agregação em um TEE.	O status atual da API Private Aggregate não é compatível com esse recurso. Discutimos esse problema mais a fundo aqui.
Documentação	Qual é o valor de épsilon usado nos testes do Google?	Na API Private Aggregate, o valor de ε especificado em uma consulta de serviço de agregação corresponde ao orçamento de contribuição L1 de 2^16, que é aplicado a cada 10 minutos contínuos. Há também um orçamento de contribuição L1 "backstop" de 2^20 que é aplicado a cada 24 horas. Basicamente, o parâmetro de privacidade é ε em 10 minutos contínuos e é 16ε em uma base contínua de 24 horas (em vez de 144ε). No momento, o serviço de agregação oferece suporte a um intervalo de ε para testes (até 64) para permitir a experimentação com diferentes estratégias de agregação e oferecer feedback sobre a utilidade do sistema com diferentes parâmetros de privacidade para a agregação privada e outras APIs. Planejamos revisar o valor máximo permitido ao longo do tempo à medida que recebermos feedback dos testadores e adicionarmos recursos que permitam um uso mais eficiente do orçamento de privacidade.

Limitar o rastreamento oculto

Dicas de cliente do user agent/Redução de user agent

Nenhum feedback recebido neste trimestre.

Proteção de IP (antigo Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
ID da resolução	O Sandbox de privacidade precisa ser mais insistente de que os IDs de resolução geralmente criados com IP não são sustentáveis para anunciantes.	O Sandbox de privacidade deixou claro que nosso objetivo é reduzir o rastreamento entre sites. Nossas iniciativas públicas, que se estendem além dos cookies, são divulgadas no privacysandbox.com e no GitHub. Nós nos esforçamos para reduzir o rastreamento entre sites, inclusive com base em endereços IP. No entanto, cabe aos sites individuais decidir se devem ativar proativamente o rastreamento entre sites. Em uma era de crescente escrutínio sobre a conformidade regulatória, é prudente que as empresas individuais tenham uma compreensão das práticas empregadas por seus provedores de serviços.
Chromecast	A proteção de IP afetará o Chromecast ou outros dispositivos Chrome?	No momento, não há planos para aplicar a proteção de IP a dispositivos Chromecast.
Lista de proteção de IP	A lista de terceiros identificados como potencialmente usando endereços IP para rastreamento entre sites em toda a Web será publicada?	A lista vai ser publicada após a finalização, conforme discutido neste link.

Mitigação de rastreio por redirecionamento

Tema do feedback	Resumo	Resposta do Chrome
Isenção de Logon único (SSO)	Como a Mitigação de rastreamento por rejeição (BTM, na sigla em inglês) verifica os casos de uso de SSO para isenção?	A BTM será desativada pela heurística do Chrome. Clique aqui para ver mais detalhes.
Teste de descontinuação	O BTM está ativado nos sites no teste de descontinuação dos 3PCs?	Não, o BTM respeita as exceções de cookies criadas pelo teste de descontinuação, conforme discutido aqui.

Orçamento de privacidade

Conforme observado na explicação do 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.

Fortaleça os limites de privacidade entre sites

Conjuntos de sites relacionados (antigos conjuntos primários)

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso	Os CHIPs e / ou o particionamento de armazenamento podem ser acessados automaticamente no RWS, sem a necessidade da API Storage Access nem da interação do usuário.	Estamos considerando os benefícios e a viabilidade de um recurso que pode realizar essa função. Uma consideração é uma possível lacuna na interoperabilidade entre navegadores, que o RWS resolve aproveitando a API Storage Access. Atualmente, não existe um equivalente para essa funcionalidade solicitada compatível com outros navegadores. Incentivamos os desenvolvedores a enviar os casos de uso sobre esse problema para facilitar a discussão aqui.
Remoção de conjuntos que não estão em conformidade	Qual é o processo para remover do repositório os conjuntos que se tornaram incompatíveis?	Estamos trabalhando para definir um processo para isso e vamos compartilhar atualizações assim que elas estiverem disponíveis.
Processo de restrição	Não há clareza em relação ao papel subjetivo do Google no processo de aplicação dos RWS.	Como o RWS é um projeto em andamento e continuamos recebendo novos envios, aspectos do processo e nossos critérios ainda estão sendo consolidados. Concordamos que é importante que nossas diretrizes de envio descrevam totalmente nossos requisitos de envio e vamos adicionar mais detalhes a essas diretrizes no futuro para evitar mais ambiguidades e confusão. Nossa intenção é que o processo de envio seja o mais técnico possível para que possamos eliminar o envolvimento humano e confiar totalmente em verificações automáticas. RPs como este precisam de uma interação mais humana porque incluem comportamentos que não prevíamos, mas nos permitem identificar mais áreas de automação e maneiras de corrigir nossas diretrizes para evitar esses problemas no futuro.
Compartilhamento de dados	Solicitar um recurso que permita aos proprietários do domínio indicar que gostariam que terceiros também compartilhem dados de RWS com o consentimento do usuário.	A funcionalidade solicitada já está disponível em APIs como a FedCM e as APIs de acesso ao armazenamento, que permitem o acesso à identidade autenticada depois que o usuário aceita um prompt de permissão. O feedback do ecossistema é bem-vindo sobre casos de uso específicos que eles acreditem não ser possíveis.
Outros métodos de armazenamento	As informações salvas no armazenamento local ou no armazenamento por sessão também serão interpretadas como 3PCs?	O armazenamento local, o armazenamento por sessão e outras formas de armazenamento que não sejam cookies, quando usadas em contextos de terceiros, estão particionados no Chrome desde a versão 115. Confira mais detalhes nesta postagem do blog.
Limite de conjuntos associados	O que acontece com as organizações que enviam mais de cinco domínios, embora isso esteja "limitado a cinco sites associados"?	Esses conjuntos vão ser aceitos pelo processo do GitHub, mas o navegador (Chrome) vai aplicar as regras de concessão automática da API Storage Access apenas aos cinco primeiros domínios e ignorar os domínios restantes, conforme discutido neste link.
find_robots_txt	A verificação find_robots_txt não funciona com redirecionamentos.	Uma correção foi enviada para resolver esse problema.
Gesto do usuário	Remoção do requisito de gesto do usuário para accessStorage().	Essa exigência foi feita com base em um design semelhante que existe em todos os principais navegadores da API requestStorageAccess. Convidamos mais feedback e casos de uso neste problema do GitHub para nos ajudar a priorizar essa solicitação e permitir discussões entre navegadores.
Gesto do usuário	É necessário um gesto do usuário para conceder permissão de acesso ao armazenamento de terceiros após a reinicialização do Chrome ou do SO?	Sim, mas queremos receber mais feedback do ecossistema sobre a mudança desse comportamento neste link.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
adComponent	Falta de documentação e flexibilidade para usar AdComponents com Fenced Frames	Vamos compartilhar mais documentos sobre esse caso de uso. Além disso, os componentes de anúncio são compatíveis com Fenced Frames usando getNestedConfigs(), que está documentado na especificação aqui.
(Também informado nos trimestres anteriores) Renderizar adComponent	Solicitação de códigos de amostra sobre como renderizar adComponents no Fenced Frame.	Estamos trabalhando para compartilhar alguns exemplos de código aqui.
Verificação de anúncios de terceiros	O papel da verificação de anúncios terceirizada no contexto de Fenced Frames precisa de mais detalhes, especialmente em relação ao contexto/brand safety.	Atualmente, os Relatórios de anúncios com Fenced Frames permitem que as DSPs enviem dados no nível do evento de impressão e leilão a verificadores de anúncios de terceiros para faturamento e verificações de brand safety pós-renderização.
Anúncios expansíveis	Solicitação para compatibilidade com anúncios expansíveis.	Se o anúncio precisar alternar entre dois tamanhos com a mesma proporção e não houver diferença funcional entre os dois (apenas o tamanho), o incorporador poderá redimensionar o frame cercado com o segundo tamanho de anúncio e o navegador dimensionará o elemento de frame fenced.
(Também informado nos trimestres anteriores) Suporte para inventário de vídeo e nativo	O Fenced Frames é compatível com inventário nativo e de vídeo?	Nossa resposta é semelhante aos trimestres anteriores: A API PA oferece suporte à renderização de vídeos usando um mecanismo que depende de iframes. No entanto, ainda não criamos uma solução para a renderização de anúncios nativos e de vídeo que seja compatível com o Fenced Frames. Por isso, decidimos adiar essa aplicação para 2026. Isso significa que, se um parceiro decidir aplicar Fenced Frames agora, ele não terá suporte para vídeo e nativo.
Conselho consultivo	Solicita a criação de um comitê consultivo de fornecedores de anúncios nativos para garantir que as implementações do Fenced Frames sigam os padrões do setor.	Os Fenced Frames não precisam ser usados na API PA antes de 2026. O tempo adicional nos permite continuar trabalhando com o setor para projetar e implementar o suporte a uma gama mais ampla de casos de uso críticos. Como informamos que vamos melhorar o Fenced Frames antes da exigência para manter a compatibilidade com anúncios nativos e em vídeo com a API PA. De acordo com nossos compromissos, vamos entrar em contato e informar a CMA sobre essas mudanças e continuar interagindo com o feedback do ecossistema antes de exigirmos o Fenced Frames. Nosso modelo de engajamento com o ecossistema da W3C e organizações com padrões de anúncios, como o IAB Tech Lab, permitem que especialistas do setor de todos os tipos guiem os designs antes que eles sejam obrigatórios.
(Também informado nos trimestres anteriores) Diferença de tamanho entre plataformas	Informa que o tamanho do conteúdo exibido no Fenced Frame parece diferente em computadores e smartphones.	Esse é um problema conhecido do Chromium que estamos investigando. Clique aqui para enviar seu feedback.
Melhoria da API	O requisito de Fenced Frames foi adiado para 2025 para que os anúncios nativos agora tenham suporte no Sandbox de privacidade?	Conforme mencionamos no aviso público sobre a aplicação do Fenced Frames em 2026, soubemos de um amplo "esforço significativo para acomodar" Fenced Frames. Certamente, um deles era nativo, mas não foi o único fator. A intenção era fornecer mais tempo para garantir a prontidão do ecossistema para oferecer suporte aos principais casos de uso, incluindo, mas não se limitando a, nativos.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Desempenho	Os tempos de retorno do armazenamento compartilhado fora da worklet parecem depender da atividade nela.	Clique aqui para discutir o resultado do teste.
Adoção mais ampla	O armazenamento compartilhado deve ser um padrão do setor disponível em todos os navegadores.	Seu feedback é muito importante para nós. O Chrome continua participando ativamente dos fóruns do W3C, incluindo a WICG, para defender a proposta, buscar feedback e incentivar a adoção.
Objetos de lances	É possível ler o armazenamento compartilhado no generateBid (que já está em execução em um worklet) para aplicar a decisão de publicidade / lógica de negócios (como limite de frequência) com base em informações entre sites e selecionar um subconjunto de anúncios?	Não, é impossível ler o armazenamento compartilhado nos worklets de lance.

CHIPS

Tema do feedback	Resumo	Resposta do Chrome
Capacidade da partição	Esclareça o comportamento ao ultrapassar a capacidade da partição.	Quando a capacidade é atingida, os cookies mais antigos são expulsos dos cookies menos acessados para liberar a memória até que o limite não seja mais excedido. Os desenvolvedores veem o cabeçalho "Cookie atualizado" nas solicitações subsequentes.
Acesso a iFrame de terceiros	O conteúdo com iFrame de terceiros incorporado que abre uma nova guia/janela para o mesmo site de terceiros precisa ter acesso aos mesmos cookies particionados que o abridor.	Estamos discutindo este caso de uso e agradecemos seu feedback do ecossistema.
Cookies duplicados	Se houver um cookie particionado e um cookie não particionado com o mesmo nome, qual valor de chave o navegador decide enviar?	Se você tiver dois cookies com o mesmo nome (um particionado e outro não), você vai receber os dois cookies. Infelizmente, não é possível diferenciar qual é qual. A especificação RFC está disponível aqui, o que explica que não se deve confiar na ordem em que os cookies são enviados.
Solicitação de recurso	Ativar cookies particionados por origem.	Estamos considerando essa solicitação e queremos receber mais feedback do ecossistema neste link.

FedCM

Nenhum feedback recebido neste trimestre.

Combater spam e fraudes

API Private State Token (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Visualização da Web	Os tokens de estado particular (PST, na sigla em inglês) persistem em vários WebViews no mesmo dispositivo móvel (perfil)?	Cada app que usa o WebView tem um armazenamento local diferente, o que significa que os emissores de PST não podem emitir tokens no WebView de um app e, posteriormente, permitir resgates de token em outro app. Isso também é válido para outras formas de dados armazenados localmente em WebViews também, como cookies. Os PSTs ainda não estão totalmente disponíveis na WebView. Esperamos fornecer uma atualização sobre isso até o final do segundo trimestre.
Novo tipo de token	Proposta para um novo tipo de token.	Agradecemos essa proposta e continuamos analisando as aplicações e adaptações das PSTs. Esperamos saber mais sobre essa proposta nas próximas reuniões do grupo da comunidade antifraude no segundo trimestre de 2024.
Identificação do usuário	Como evitar que os usuários sejam identificados com base nos PSTs específicos que eles têm?	No momento, isso é mitigado pela limitação das tentativas de resgate em um site a dois emissores, independentemente de haver tokens disponíveis desse emissor. Você precisa contar um emissor em relação ao limite mesmo que não haja tokens disponíveis. Caso contrário, o site pode iterar por todos os emissores até encontrar uma correspondência positiva.
Inscrição	Por quanto tempo será necessário o registro para PSTs?	O registro continuará sendo necessário para um futuro próximo, conforme explicado em mais detalhes neste link.
Suporte para outros navegadores Chromium	O registro do emissor da PST para outros navegadores baseados no Chromium será compatível com o repositório de Registro do emissor do Chrome?	O Chrome busca os compromissos de chave e os distribui aos clientes Chrome com um mecanismo chamado atualizador de componentes. À medida que outros navegadores adicionam suporte mais completo à API, eles precisarão estabelecer um processo para conseguir as confirmações de chave para o cliente, seja por meio de um método no estilo atualizador de componentes ou de algum outro método. Isso é abordado em mais detalhes aqui.