Relatório de feedback – 4o trimestre de 2023

Relatório trimestral do quarto trimestre de 2023 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

ÍNDICE

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

PI

Endereço Protocolo de Internet

openRTB

Lances em tempo real

Prorrogação

Teste de origem

PatCG

Grupo da comunidade de tecnologia de publicidade privada

RP

Parte confiável

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
Linha do tempo de 3PCD	Compartilhe mais informações sobre a linha do tempo dos modelos 3PCD.	Para facilitar os testes, o Chrome restringiu os 3PCs por padrão para 1% dos usuários, a partir de 4 de janeiro de 2024. Sujeito a todas as outras preocupações da CMA, o Chrome planeja descontinuar gradualmente o suporte a 3PCs a partir do 3o trimestre de 2024 e vai continuar pelo restante de 2024.
Linha do tempo de 3PCD	Impacto do período de 3PCD no 4o trimestre de 2024, já que coincide com o período de festas de fim de ano e pode ter um impacto negativo para os editores.	Não há momento ideal para suspender o uso dos 3PCs. Há mais de um ano, sabemos que nossa intenção era descontinuar o uso de 3PCs no segundo semestre de 2024. Nossos compromissos com a CMA, que incluem o possível período de inatividade, não mudaram. Entendemos a preocupação com o prazo para o quarto trimestre, mas fazer mudanças no cronograma resultou em menos preparação do setor, não mais.
Teste do Chrome (modo a/b)	A configuração do teste para o modo A e o modo B é por instância ou por perfil do Chrome?	Publicamos um esclarecimento na documentação aqui de que o navegador Chrome, neste contexto, se refere a um cliente Chrome: uma instalação do Chrome em um dispositivo. Cada diretório de dados do usuário constitui um cliente distinto.
Teste de descontinuação	Compartilhe mais informações sobre o teste de 3PCD.	Compartilhamos mais informações sobre o teste de 3PCD neste link.
Teste de descontinuação	Não houve tempo suficiente para fornecer tokens de teste de descontinuação em todos os sites antes de janeiro de 2024.	Reconhecemos que há um curto período entre o momento em que os registros de testes de descontinuação são abertos e o período de teste facilitado pelo Chrome começa a bloquear 1% dos cookies. Para lidar com essas restrições de tempo, o Chrome está oferecendo um período de carência para as origens participantes enquanto elas trabalham para implantar tokens de teste de descontinuação. Durante o período de carência, que vai acontecer até 1o de abril de 2024, as origens registradas para o teste de descontinuação terão acesso aos 3PCs no Chrome, mesmo que ainda não tenham implantado os tokens. O objetivo desse período de carência é evitar problemas de compatibilidade com a Web durante a fase de transição. As origens participantes precisam implantar tokens de teste de descontinuação antes do final do período de carência para continuar tendo acesso aos 3PCs após o término desse período.
Teste do Chrome (modo a/b)	O modo B é uma amostra muito pequena para medir corretamente quedas no desempenho.	É preciso ter um equilíbrio cuidadoso entre a porcentagem de tráfego e o risco de impacto sobre os usuários e a funcionalidade da Web.
Controles de teste	Somente os maiores editores com recursos de desenvolvimento significativos poderão entender o desempenho durante o teste e repassá-lo à CMA.	Os provedores de serviços para editores já estão compartilhando insights publicamente com o ecossistema, e esperamos que isso continue à medida que os testes do Sandbox de privacidade aumentam. Também esperamos que as empresas de tecnologia de publicidade que usam as APIs do Sandbox de privacidade continuem desenvolvendo recursos que os clientes exigem, como relatórios com base em rótulos.
Dados de terceiros	Preocupação com empresas de dados de terceiros.	Há diferentes tipos de empresas de dados de terceiros. Algumas podem dobrar, adotando métodos cada vez mais opacos de rastreamento entre sites. Outras podem usar tecnologias que aumentam a privacidade e desenvolver novas propostas de valor para os clientes. Esperamos que mais usuários escolham a segunda opção e sigam as orientações cada vez mais exigentes para os usuários e reguladores. A mudança gerará oportunidades de evolução e inovação.
Google Ad Manager	Precisa de mais orientações do Google Ad Manager sobre como os editores podem testar o Sandbox de privacidade. Os relatórios não são suficientes para os editores entenderem o impacto.	Resposta fornecida pelo Google Ad Manager: O Google Ad Manager explicou como realizará os testes usando rótulos facilitados pelo Chrome na Central de Ajuda. Atualmente, o Ad Manager oferece aos editores relatórios sobre Topics e Protected Audience. No momento deste relatório de feedback, o Ad Manager podia gerar relatórios sobre as impressões veiculadas pela API Protected Audience e indicar se havia dados da API Topics em uma determinada impressão. Os editores interessados em relatórios mais sofisticados, como a segmentação de relatórios com base nos rótulos facilitados do Chrome, podem fazer isso lendo os rótulos diretamente do Chrome (usando a documentação do Chrome) e transmitindo-os como chaves-valor em solicitações de anúncios ao Ad Manager e em relatórios de chave-valor para gerar relatórios sobre os rótulos.
Incentivo de testes	Preocupação do anunciante sobre o tempo suficiente para testar o Sandbox de privacidade e a possibilidade de possíveis mudanças significativas na API.	Entendemos que algumas pessoas querem mais tempo, mas o setor nos disse que mudar o cronograma provavelmente resultará em menos preparação do ecossistema, não mais. O cronograma para descontinuar o uso de 3PCs está sujeito a abordar quaisquer preocupações com concorrência da CMA, mas incentivamos todos a se prepararem para essa iniciativa em 2024. Como qualquer tecnologia, as APIs do Sandbox de privacidade vão continuar evoluindo. Essa evolução é decorrente dos avanços nas tecnologias e dos impactos no ecossistema. Seremos responsáveis enquanto fazemos mudanças e não achamos que as mudanças na tecnologia devam inibir o uso indefinidamente.
Smart TV	Não há caminho para oferecer suporte a vídeo linear ou de smart TV.	Queremos explorar outros casos de uso de smart TV, mas não achamos que as APIs para dispositivos de smart TV atrapalhem o 3PCD no Chrome.
Servidores de anúncios do anunciante	O Google está mudando a segmentação de anúncios para o DV360. Que suporte será fornecido para os servidores de anúncios do anunciante?	Resposta fornecida pelo Chrome: A API PA foi criada para que os servidores de anúncios do anunciante veiculem e meçam os anúncios mostrados a um usuário com o uso de iframes / frames isolados e relatórios de beacon. Além disso, eles trabalharão com partes upstream e downstream para integração no fluxo de disponibilização, como já fazem.
Gerenciador de dados do Google Ads	O "Gerenciador de dados do Google Ads" recém-anunciado se baseia na Segmentação por lista de clientes e nas conversões otimizadas, que permitem aos anunciantes compartilhar dados próprios de clientes com o Google para manter todas as funções de marketing desempenhadas pelos 3PCs. Como esse novo recurso está alinhado aos compromissos do Google com a CMA?	Resposta fornecida pelo Google Ads: O Gerenciador de dados do Google Ads simplesmente facilita o upload de dados próprios dos sistemas de armazenamento de dados do anunciante (sistemas em nuvem) para uso dos anunciantes para a Segmentação por lista de clientes (CM) e as conversões otimizadas (EC), facilitando as empresas de pequeno e médio porte com menos recursos técnicos. O gerenciador de dados do Google Ads não habilita recursos novos para CM ou EC em termos de capacidade de endereços ou mensurabilidade de anúncios no Google O&O OU em editores terceirizados. As plataformas de publicidade do Google têm o mesmo acesso aos recursos disponíveis nas tecnologias do Sandbox de privacidade que as outras empresas de adtech.
Configurações do Chrome	A página de configurações internas do Chrome deve fornecer mais informações sobre o tamanho dos cookies.	A funcionalidade solicitada já está disponível nas Ferramentas para desenvolvedores do Chrome. Na página de configurações, você encontra mais feedback sobre por que esse recurso deve ser priorizado.
Heurística	Quais heurísticas o Chrome está implantando para preservar experiências críticas do usuário durante os 3PCDs?	Veja nossa resposta a esta pergunta no GitHub (em inglês).
Versões do navegador	Diferenciar navegadores Chrome estáveis de navegadores Chrome não estáveis?	Uma correspondência aproximada da versão principal do Chrome com o ciclo de lançamento Stable funcionará.
Compliance	O Chrome pode fornecer relatórios relacionados à SOX?	O Chrome não fornecerá relatórios relacionados à SOX. As APIs do Sandbox de privacidade são uma das muitas APIs da Web que o Chrome disponibiliza para os sites que um usuário visita. Como acontece com todas as APIs da Web, o autor da chamada de API não entra em um contrato com o Chrome para usar a API do Sandbox de privacidade. O acesso depende apenas de o autor da chamada da API atender a algum requisito técnico e do usuário ter as configurações apropriadas ativadas. Nesse caso, somente o autor da chamada da API determina como usar a API, incluindo quais dados armazenar, quais lances fazer, quais relatórios solicitar etc.
Compliance	Ampliamos as perguntas frequentes de compliance com o Sandbox de privacidade para responder a mais dúvidas.	Agradecemos o feedback e planejamos continuar ampliando as perguntas frequentes.
Pergunta sobre o Chrome	A descontinuação dos 3PCs no Chrome está afetando a disponibilidade de 3PCs no Android WebView (navegador incorporado)?	No momento, não incluímos o WebView nesta fase do lançamento e teste da API do Sandbox de privacidade ou do 3PCD, além da ativação da medição de atribuição entre apps e na Web.
Pergunta sobre a API	Como é possível rastrear cliques e impressões de produtos patrocinados?	Esse caso de uso é coberto pela API Attribution Reporting.
Cronograma	Por que o cronograma mudou para 3PCD?	Discutimos os motivos neste link.
SSO da extensão do Chrome	Permitir o caso de uso de Logon único entre um site e uma extensão do Chrome após o 3PCD.	Estamos discutindo esse problema. Seu feedback sobre outros casos de uso é bem-vindo.
Uso da API	O Google pode confirmar uma lista de parceiros para testar APIs?	Detalhes sobre os testadores que se identificaram publicamente estão disponíveis no GitHub para as seguintes APIs: - API Topics - API Protected Audience - API Attribution Reporting - Armazenamento compartilhado - CHIPs
Iniciativa Utiq	Qual é a opinião do Chrome em relação à iniciativa Utiq?	Saiba mais sobre isso aqui.
Pergunta sobre o Chrome	Como detectar os usuários que navegam sem 3PCs?	Não há configuração explícita para detectar o bloqueio por 3PC. Para uma abordagem geral de "detecção de recursos", recomendamos criar a solicitação iframe / entre sites e tentar definir um cookie semelhante ao caso de uso necessário é a solução mais próxima.
Pergunta sobre o Chrome	Navegar no modo de navegação anônima é o mesmo que executar o teste de sinalização (iniciar o Chrome usando a sinalização de linha de comando --test-third-party-cookie-phaseout)?	O modo de navegação anônima é diferente da sinalização. O flag não só bloqueia 3PCs, mas também permite o FedCM e o particionamento de armazenamento de terceiros.
Pergunta sobre o Chrome	Mais detalhes sobre qual é o impacto esperado do 3PCD para cada região/país quando 1% acontece.	Os clientes são incluídos de maneira aleatória e global, embora possa haver variações regionais. Por exemplo, pode haver diferenças na distribuição de dispositivos e nas versões do Chrome.
Tecnologias alternativas que melhoram a privacidade	As tecnologias alternativas de melhoria da privacidade precisam ter permissão para fazer o rastreamento de vários domínios que preserva a privacidade para evitar o monopólio dos dados no Chrome e no Android.	Há várias oportunidades para os desenvolvedores criarem ofertas de tecnologia que melhoram a privacidade além dos elementos básicos que oferecemos, além dos elementos básicos que não são do Sandbox de privacidade.
Estudo do CookieGraph	Qual é a perspectiva do Chrome sobre o método CookieGraph, conforme descrito neste documento na estrutura do Sandbox de privacidade?	Estamos analisando este documento e receberemos mais feedback.

Registro e atestado

Tema do feedback	Resumo	Resposta do Chrome
A inscrição é restritiva	O Google introduziu termos de uso específicos para as APIs do Sandbox de privacidade. Os termos impedem efetivamente que empresas especializadas em ajudar editores a reconhecer os visitantes com consentimento para testar e/ou integrar recursos do Sandbox de privacidade na solução de identidade. Os Termos e Condições limitam injustamente a capacidade de operar no Sandbox de privacidade.	O processo de registro e atestado não envolve a aceitação dos Termos de Uso da API. O registro e a confirmação são mecanismos para melhorar a transparência sobre quais desenvolvedores chamam as APIs do Sandbox de privacidade e como usam os dados acessados. Especificamente, o atestado é uma declaração pública de que o desenvolvedor que atesta não usa as APIs para identificar usuários em sites ou apps e não burla as proteções de privacidade das APIs. O atestado não exige que os desenvolvedores informem o uso de outros dados ou tecnologias pelos desenvolvedores.
Inscrição no Sandbox de privacidade	Como atualizar o ponto de contato / endereço de e-mail para atestado?	As informações da inscrição podem ser atualizadas usando o formulário de inscrição. Mais detalhes estão disponíveis aqui.
Inscrição no Sandbox de privacidade	Você poderia esclarecer os cenários de limite de acesso caso o atestado não esteja disponível?	O Sandbox de privacidade tem três semanas para que um contato técnico restabeleça o arquivo de atestado do site inscrito antes de negar o acesso de uma empresa inscrita às (APIs de medição e relevância).
Inscrição no Sandbox de privacidade	Como podemos testar as APIs em um ambiente local usando endpoints que não sejam de produção?	Nós respondemos a essa pergunta aqui.

Mostre conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Utilidade para diferentes tipos de partes interessadas	Os editores estão preocupados com o impacto dos tópicos nas vendas baseadas em dados. Sites maiores recebem um Tópico de notícias geral, nenhum dado o vincula ao editor específico. Em troca, editores especialistas oferecem seus dados por informações limitadas.	Sabemos que os sites com domínios de interesse mais geral tendem a contribuir com temas menos granulares do que os sites com domínios de interesse mais nicho. No entanto, nem todos os sites de nicho contribuem com tópicos valiosos. Além disso, essa dinâmica reflete o status quo: alguns sites agregam mais valor que outros em sistemas de relevância de anúncios baseados em 3PC. A API Topics (e o Sandbox de privacidade em geral) oferece aos editores mais controle sobre como as informações deles são usadas pelas empresas de adtech parceiras. Além disso, as informações disponíveis pela API Topics são muito mais precisas do que os indicadores atuais.
Servidores de anúncios do editor	Os servidores de anúncios do editor que usam servidores dedicados podem não observar diretamente a API Topics.	Estamos discutindo esse problema aqui e agradecemos seu feedback.
Declaração	Expandir o requisito de atestado para lidar com consequências indesejáveis conhecidas da transferência de informações entre contextos.	No momento, o atestado não cobre essa ampla categoria de risco, mas sim o abuso da API.
Volume de tráfego da API Topics	O volume atual de impressões recebidas não é suficiente para testes.	O Chrome está ciente do feedback sobre o volume de temas disponíveis no ecossistema programático. Estamos investigando os possíveis motivos, tanto no navegador quanto entre testadores relevantes. Se considerar necessário, o Chrome vai avaliar quais possíveis mudanças no design da API estão disponíveis para aumentar a taxa de cobertura e permitir testes em escala suficiente, preservando a privacidade do usuário.
Uso da API	Existe uma limitação de taxa da API Topics?	Existem alguns limites de taxa da API Topics para evitar abusos e proteger a experiência dos usuários na Web. Confira mais detalhes neste link.
Taxonomia V2	Diretrizes do IAB para os detalhes do tópico a serem incluídos no protocolo de RTB aberto?	Sim, as diretrizes do IAB sobre a inclusão de temas no protocolo Open RTB podem ser encontradas aqui.
Impacto nos indicadores próprios	A taxonomia granular da API Topics v2, em conjunto com um processo para retornar o valor mais alto dessa segmentação granular (tópicos principais), vai distorcer o mercado de dados para publicidade.	Nossa resposta permanece inalterada desde o terceiro trimestre: "Embora uma taxonomia da Topics mais detalhada possa diminuir indiretamente a atratividade de outras soluções, como aquelas que se baseiam em dados próprios do editor ou aquelas que dependem de transações diretas, à medida que desenvolvemos a API Topics, nosso principal objetivo é garantir que ela ofereça suporte aos casos de uso de publicidade com base em interesses após o 3PCD da maneira mais eficaz possível, para todas as partes interessadas. Acreditamos que uma maior utilidade da API Topics vai melhorar a concorrência em geral e beneficiar o ecossistema como um todo."
Lista de testadores	Qual é a adoção de tópicos e da API PA entre seus editores?	Não é possível compartilhar essas informações. Consulte a lista de testadores, onde os editores podem ativar o compartilhamento do status dos testes.
Seleção de temas	Permitir que os usuários selecionem temas de interesse proativamente?	Certamente pensamos em permitir que os usuários adicionem tópicos de forma proativa. Não pretendemos resolver o problema em curto prazo, mas estamos abertos a explorá-lo em longo prazo.
Seleção de temas	Se uma adtech tem código em um site para observar temas, ela consegue saber quais tópicos podem ser observados?	Uma empresa de adtech pode determinar os temas associados a um site. A API não compartilha essas informações em tempo real porque pode gerar custos de latência.
Taxonomia V2	Como a API Topics pode retornar até três temas, qual é o comportamento esperado com o lançamento da taxonomia v2?	A API ainda vai retornar até três temas e vai incluir a versão da taxonomia relevante para cada tema na resposta.
(Também informado nos trimestres anteriores) Observação de tópicos	Permita que os editores concedam permissões ao Chrome para categorizar temas com base no conteúdo da página (por exemplo, cabeçalho ou corpo).	Nossa resposta não mudou desde o terceiro trimestre: "Anteriormente, consideramos oferecer uma funcionalidade para classificar sites em temas com base no conteúdo da página e decidimos não prosseguir com a privacidade e a segurança. Esta proposta pode atenuar algumas dessas preocupações, mas não está claro o quanto. Devido ao próximo período de testes da CMA, não esperamos que essa mudança ocorra antes do 3PCD. Envie seu feedback neste link.
Seleção de temas	Como os domínios estão sendo classificados na API Topics considerando que eles são gerais?	Usamos o nome do host apenas para classificar sites em tópicos. Um site classificado de maneira ampla não é prejudicado por isso. Isso ocorre porque as informações contextuais de um site sempre estarão disponíveis para leilões no site, o que daria informações mais específicas para o Tópico amplo.
Taxonomia V2	Desejem um melhor alinhamento dos tópicos com outros padrões (por exemplo, IAB).	Gostaríamos de saber por que eles esperavam um alinhamento mais próximo entre as taxonomias do IAB e da API Topics. Que etapas eles precisam seguir para adotar a API Topics e como uma taxonomia mais distinta afeta essas etapas? Estamos pensando em lançar um mapeamento entre a taxonomia da API Topics e a taxonomia de conteúdo do IAB. Seria útil entender se isso solucionaria os desafios que os editores enfrentam.
Armazenamento e uso de dados	Você tem mais informações sobre como os dados são armazenados e para onde são transferidos?	As informações dos tópicos são geradas e armazenadas localmente no dispositivo do usuário. Mediante solicitação, a API retorna até três temas para os autores da chamada. Na visão do Google, os autores das chamadas são responsáveis por obedecer aos regulamentos locais ao processar e armazenar informações da API Topics. Além disso, os autores das chamadas precisam confirmar que não estão usando a API Topics para reidentificar usuários nos sites. Consulte as Perguntas frequentes sobre compliance relacionadas à privacidade para mais detalhes.
Taxonomia V2	Efeito do upgrade da taxonomia da API Topics e do estado do navegador durante a transição da v1 para a v2.	Os temas inferidos com a taxonomia anterior ainda estão disponíveis e podem ser buscados pela adtech até que expirem (quatro semanas).
Descrição da API	A experiência do usuário da API Topics é enganosa.	Compartilhamos este feedback com a equipe de UX.
Pergunta sobre a API	Como os domínios do Yahoo estão sendo classificados na API Topics, considerando que eles são gerais?	Usamos o nome do host apenas para classificar sites em tópicos. É importante entender que um site classificado de maneira ampla não será prejudicado por isso.
A taxa de disponibilidade dos temas está baixa	Os testadores estão recebendo um volume baixo de temas do Google Ad Manager.	O Google Ad Manager lançou várias otimizações para melhorar a cobertura. Os compradores devem ter notado um aumento na cobertura. Alguns fatores esperados podem limitar a cobertura, como preferências do usuário, requisitos de observação do autor da chamada e, possivelmente, latência/tempos limite.

API Protected Audience (antigo FLEDGE)

Tema do feedback	Resumo	Resposta do Chrome
Diferencial	Falta de clareza sobre como as SSPs trazem diferenciação para o novo leilão.	Já ouvimos falar de vários planos estratégicos que têm a Protected Audience e/ou outras APIs do Sandbox de privacidade em evidência. De modo geral, a redução dos identificadores onipresentes entre sites é frequentemente vista pelos vendedores do ecossistema como uma medida positiva, não apenas em termos de privacidade, mas comercialmente. Empresas, pequenas e grandes, que abraçam essa mudança provavelmente encontrarão oportunidades.
Renderização do anúncio	como o único caminho para a renderização dos anúncios, impede a inovação. A renderização da API Protected Audience reduz a viabilidade dos padrões atuais em relação à publicidade nativa.	Os anúncios renderizados em navegadores sempre usaram tecnologias de navegador para fazer a renderização. Isso não muda. Talvez essa preocupação seja específica para os planos de exigir o uso do Fenced Frames junto com a Protected Audience no futuro. Parte do motivo desses planos estarem "no futuro" é exatamente porque queremos a tecnologia Fenced Frames para oferecer suporte à inovação e diferenciação do ecossistema na renderização de anúncios. Há tempo para que desenvolvedores e empresas interessados opinem sobre a direção dos Fenced Frames, que inclui como as abordagens dos anúncios nativos podem ser compatíveis.
Entrada	A API Protected Audience (PA) da Concern Audience foi lançada mais ou menos completa quando muitas adtechs começaram a explorar as APIs do Sandbox de privacidade.	As APIs continuarão evoluindo com base no que aprendemos com o uso, bem como em novas ideias que vêm de dentro e de fora do Chrome. Atualmente, as APIs de relevância e medição com disponibilidade geral estão estáveis, mas isso não significa que o desenvolvimento foi interrompido. Queremos receber mais feedback.
Design de leilão	O design da API Protected Audience coloca toda a lógica de criação de público e seleção de anúncios nas mãos da plataforma de compra, removendo a capacidade de uma SSP oferecer criação de público-alvo e lógica de seleção de anúncios para campanhas executadas na plataforma.	A API Protected Audience não depende de quem cria públicos-alvo e quem faz lances neles. Uma SSP pode criar um grupo de interesse (IG) que disponibiliza para lances. Também é possível que uma SSP forneça uma lógica de lances, que parece estar alinhada com a direção que muitas SSPs estão indo diretamente para as agências. Embora sempre haja espaço para outros casos de uso, as bases da Protected Audience são flexíveis o suficiente para oferecer suporte a muitas abordagens diferentes de criação e ativação de públicos-alvo. As características de privacidade dessas fundações também significam que os dados brutos no nível do usuário não são compartilhados entre sites.
Design de leilão	O leilão da Protected Audience vai contra os esforços de otimização do caminho de fornecimento (SPO, na sigla em inglês) do ecossistema para reduzir a quantidade total de intermediários entre um anunciante e um editor e/ou a duplicação de uma determinada oportunidade de anúncio?	Não. Um anúncio vencedor na API Protected Audience vai passar por no máximo duas entidades de vendedor (por exemplo, uma SSP e um servidor de anúncios do editor) e pelo menos nenhuma, se o comprador criar uma integração direta com o editor. A duplicação da mesma solicitação por vários intermediários permanece a escolha do editor. A API Protected Audience não deve afetar de uma maneira ou de outra. Os leilões da Protected Audience ocorrem fora do sistema em tempo real de servidor para servidor atual para não vazar dados do usuário entre sites. Alguns podem dizer que isso duplica uma solicitação de anúncio. Chegar a uma privacidade tecnicamente demonstrável exige algumas compensações. No entanto, é possível que, a longo prazo, o ecossistema decida usar a Protected Audience sem os leilões tradicionais do lado do servidor. Essa escolha pode levar a caminhos de fornecimento ainda mais otimizados.
Design de leilão	A API Protected Audience muda para um modelo em que as SSPs raramente são o "último" leilão executado na página, mas são forçadas a esse modelo pelo design da API.	Nós discordamos. As implementações de usuários iniciais que vimos realmente fazem com que as SSPs que participam de leilões de componentes possam superar o resultado do leilão contextual, que ocorre antes da execução do leilão da Protected Audience. Os resultados do leilão de componentes da SSP na Protected Audience são considerados por último, depois que um leilão contextual completo é realizado.
Design de leilão	O leilão contextual pode ser relevante apenas para fornecer indicadores de dados sobre a oportunidade de leilão para informar o leilão da API Protected Audience.	Esperamos que os leilões contextuais permanecerão relevantes por diversos motivos, como transações, campanhas segmentadas por público-alvo que não são próprios e muitos cenários contextuais. Ele também é útil quando não há IGs ou os lances na Protected Audience não alcançam os preços mínimos ou não seguem as regras de qualidade dos anúncios.
Modelagem de tráfego	As DSPs operam com um QPS fixo. Ajustar os leilões da Protected Audience vai diminuir a utilidade da infraestrutura legada.	Pelo que sabemos, o que está mudando em relação às consultas por segundo é que muitas SSPs usam IDs entre sites como um recurso para determinar se devem ou não enviar uma solicitação DSP. Isso seria verdadeiro se o editor quiser realizar um leilão da Protected Audience ou não. Exploramos a modelagem de tráfego com muitas SSPs e encontramos soluções que incluem armazenamento em cache e filtragem baseada em contexto. Com o tempo, esperamos que os desenvolvedores aproveitem a agregação privada para ajudar na compreensão das preferências de lances da DSP e na filtragem adequada. Por fim, algumas infraestruturas legadas criadas com base em identificadores entre sites não serão mais úteis.
Indicadores disponíveis	A falta de clareza sobre a gama completa de indicadores disponíveis quando os leilões ocorrem e como a sequência com o leilão contextual prejudica isso.	De modo geral, para os bidders, as informações podem ser fornecidas na criação de um IG a partir do leilão contextual e de uma pesquisa de chave-valor em tempo real. Para os pontuadores, as informações podem ser fornecidas quando o leilão é configurado, incluindo informações contextuais sobre a página e o leilão contextual, bem como de uma pesquisa de chave-valor em tempo real em renderUrls de anúncios.
(Informado nos trimestres anteriores) Renderização de vídeo	Suporte à renderização de vídeo usando Protected Audience e Fenced Frames.	Nossa resposta não mudou em relação aos trimestres anteriores: "A API Protected Audience oferece suporte à renderização de vídeo usando um mecanismo que depende de iframes. No entanto, ainda não criamos uma solução compatível com o Fenced Frames, e esse é um dos motivos por que decidimos adiar a aplicação desse recurso para 2026. Isso significa que, se um parceiro decidir aplicar Fenced Frames agora, ele não terá suporte para vídeos."
Renderização de vídeo	O suporte da API PA para vídeo em iframes é limitado ao vídeo HTML5 e não é compatível com o padrão VAST amplamente utilizado.	É possível implementar anúncios baseados em VAST usando o mecanismo de renderização de iframe disponível na API Protected Audience. O Google reconhece que isso requer nova engenharia por parte de compradores, vendedores e plataformas de anúncios dos editores. Além disso, continuaremos trabalhando para facilitar essa transição.
(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 Google Ad Manager o controle do leilão de nível superior da API PA.	Nossa resposta não mudou em relação aos trimestres anteriores: "Resposta fornecida pelo Google Ad Manager: Os planos do Google Ad Manager para a API Protected Audience não incluem suporte ao servidor de anúncios para editores do Google sem o controle do leilão de nível superior da Protected Audience, pelos seguintes motivos. Para atender corretamente nossos clientes no mercado de veiculação de anúncios do editor, o servidor de anúncios do editor do Google precisa manter o controle do leilão de nível superior da Protected Audience. Como um servidor de anúncios do editor, nosso papel é fornecer aos editores previsões para que eles possam negociar campanhas de venda direta sem reservas em excesso, além de definir o ritmo e a entrega de reservas diretas de maneira otimizada. Para isso, é necessário realizar o leilão final para comparar toda a demanda direta e indireta qualificada. A estimativa e o ritmo são funcionalidades essenciais que os editores esperam de um servidor de anúncios. Sem uma previsão precisa, os editores podem acabar vendendo demais do inventário, o que coloca a reputação da empresa em risco. O ritmo também é fundamental, já que não conseguir cumprir os contratos de reserva com os anunciantes também pode causar danos à relação direta entre editor e anunciante, o que pode causar um impacto significativo nos negócios dos editores. Em resumo, portanto, não consideramos a atividade do servidor de anúncios do editor na realização do leilão de público-alvo protegido de nível superior como diferente das outras atividades desse servidor."
(Informado nos trimestres anteriores) directFrom SellerSignals	directFromSellerSignals permite que o Google Ad Manager evite que o editor veja o preço do leilão contextual.	Nossa resposta não mudou em relação aos trimestres anteriores: "Resposta do Chrome: As informações transmitidas para runAdAuction() não são reconhecidas pelo vendedor, a menos que ele chame runAdAuction() pelo próprio iframe. Em um leilão com vários vendedores, não é possível fazer com que todos os vendedores criem o frame chamando runAdAuction(). O directFromSellerSignals resolve esse problema carregando conteúdo de um pacote de recursos secundários carregado a partir da origem de um vendedor. Isso garante que a autenticidade e a integridade das informações transmitidas nas configurações dos leilões entre vendedores e vendedores não possam ser manipuladas. Se os editores quiserem usar a API Protected Audience para entender as informações transmitidas pelos provedores de tecnologia aos leilões da Protected Audience, poderão pedir essa funcionalidade a eles. Resposta fornecida pelo Google Ad Manager: Mantemos um foco na imparcialidade do leilão por anos, o que inclui nossa promessa de que nenhum preço de qualquer fonte de publicidade não garantida do editor, incluindo preços de itens de linha não garantidos, será compartilhado com outro comprador antes de dar um lance no leilão, o que mais tarde reafirmamos em nossos compromissos com a Autoridade de Concorrência da França. Nos leilões da Protected Audience, pretendemos cumprir nossa promessa usando directFromSellerSignals e não compartilhar o lance de nenhum participante com outros participantes antes da conclusão em leilões de vários vendedores. Para esclarecer, não compartilharemos o preço do leilão contextual com nosso próprio leilão de componentes, conforme explicado nesta atualização."
(Informado nos trimestres anteriores) Valor de K-anonimato	Como o valor de "K" a "k-anon" será decidido e quando ele será publicado?	Publicamos o valor de K-anonimato em dezembro de 2023. Após o início do processo de 3PCD, aumentaremos o limite de k-anonimato para o valor final de 50 (k=50) e definiremos o período de atualização para 1 hora (p=1). O valor de K-anonimato de 50 foi avaliado como o ideal de equilíbrio entre utilidade e privacidade. Esse valor é suficiente para frustrar ataques de bot básicos e manter a privacidade diferencial, além de ser baixo o suficiente para que a API continue sendo útil para os casos de uso pretendidos.
(Informado nos trimestres anteriores) forDebuggingOnly	Possível uso indevido de forDebuggingOnly.reportAdAuctionWin se continuar após o 3PCD.	Compartilhamos nossa proposta sobre como continuar a oferecer suporte aos casos de uso de depuração a longo prazo neste link. Gostaríamos de receber mais feedback sobre a proposta.
(Informado nos trimestres anteriores) Política de mesma origem	Solicitação de relaxamento da política de mesma origem para permitir subdomínios.	Essa solicitação está sendo analisada, e discutimos isso aqui.
(Informado nos trimestres anteriores) Tamanho do componente do anúncio	Aumente o número de componentes do anúncio de 20 para 40.	Discutimos essa solicitação durante a ligação WICG de 4 de outubro e neste problema do GitHub e planejamos resolvê-lo até o final do primeiro trimestre de 2024.
(Informado nos trimestres anteriores) Validade da chave do servidor de chave-valor	Discussão sobre a remoção das chaves do servidor depois que os IGs correspondentes expirarem.	É melhor gerenciar o TTL fora do TEE para reduzir a complexidade, mas qualquer feedback adicional é bem-vindo.
Acionadores do InterestGroup	Um único IG pode acionar vários generateBids em um único leilão (componente)?	Toda vez que o navegador chamar a função generateBid() de um IG, esse IG poderá retornar um valor de lance. Por exemplo, em um leilão com vários vendedores, um IG é chamado várias vezes, cada vez em um dos leilões de componentes. Nada precisa ser feito explicitamente pelo proprietário do IG para ativar/apoiar esse comportamento.
Perguntas sobre compliance	Qual é o escopo do consentimento sendo coletado pelo navegador Chrome de um usuário?	Consulte "Como o Sandbox de privacidade está abordando a conformidade relacionada à privacidade no Chrome?" nas Perguntas frequentes de conformidade relacionadas à privacidade para mais detalhes.
Leilões com várias tags	Como participar de leilões com várias tags?	Estamos avaliando a solicitação e receber feedback adicional neste link.
Disponibilidade de proteção de IP	Qual é o impacto nos cronogramas de recursos da API Protected Audience, como a aplicação do Fence Frame e a remoção ou remoção dos relatórios no nível do evento se a proteção de IP não estiver pronta para as datas anunciadas?	Como mencionado neste link, acreditamos que os cronogramas da API Protected Audience precisam estar vinculados aos cronogramas de lançamento de outros recursos de proteção de privacidade.
modelingSignals	Solicitação de um novo campo, além dos modelSignals, que só podem codificar informações de exibição e clique.	Entendemos os benefícios proporcionados por isso e, por isso, vamos avaliar a solicitação e receber mais feedback neste link.
IGs negativos	É possível permitir que IGs normais especifiquem um nome de IG negativo?	Atualmente, não é possível fazer isso de acordo com a explicação, mas queremos receber mais feedback do ecossistema sobre por que isso é necessário.
Uso da API	Gerar um relatório agregado no nível generateBid() passando	A agregação particular pode ser invocada dentro de generateBid.
Macros	Encaminhe indicadores de perBuyerSignals por meio de macros em IFrames para terceiros.	Estamos discutindo esse caso de uso aqui e agradecemos seu feedback.
Uso da API	Se a busca de indicadores de pontuação confiáveis retornar um erro, scoreAd() ainda será chamado?	ScoreAd() ainda deverá ser executado se a chamada de busca não tiver êxito.
Uso da API	Gravação de metadata.shard_num em arquivos riegeli para arquivos delta/snapshot.	Estamos adicionando suporte a shard_num para desbloqueio. Riegeli não é tão adotado quanto, por exemplo, o Avro, mas não é abandonado. Como o TEE tem muito mais restrições e sobrecarga, priorizamos a performance em vez da experiência do usuário. Estamos pensando em fornecer um serviço gRPC para criar arquivos com base em solicitações. Também podemos avaliar outros formatos, como Avro, para analisar o impacto no desempenho.
Teste de API	Como as APIs PA e Measurement vão oferecer suporte aos testes de incrementabilidade?	O Sandbox de privacidade não tem como medir a incrementabilidade com um pré-leilão contrafatual. É possível usar o armazenamento compartilhado e a agregação privada, mas o contrafatual só ocorreria após o leilão.
Uso da API	Usar BiddingWasmHelperURL para atualizações diárias está afetando o limite de k-anonimato?	Como o k-anonimato não é mais considerado nas atualizações do IG, é possível atualizar o BiddingWasmHelperURL sem afetar o limite.
Uso da API	Podemos receber notificações de erro referentes à API PA?	O feedback do ecossistema sobre o tipo de notificação de erro é necessário para resolver problemas da API PA.
Tamanhos de anúncio	Os tamanhos de anúncio não são visíveis no leilão nem nos relatórios.	Estamos resolvendo o problema com esta solicitação de envio.
Uso da API	O endpoint de atualização do IG é chamado para o IG se ele não participa desse leilão?	Sim. O updateURL é chamado para todos os IGs de um determinado proprietário, mesmo que ele não tenha definido um lance nesse leilão específico. Os únicos requisitos são: - o proprietário precisa ser incluído em um determinado leilão (ou seja, ser incluído como comprador em leilãoConfig). - O interestGroup do proprietário não pode ter sido atualizado nas últimas 24 horas.
Prebid na API PA	Qual versão do Prebid.js será necessária para a fase de teste?	De acordo com nossa documentação técnica, a versão precisa ser >= 8.9.0.
Ativação de dados próprios na API PA	Como ativar dados próprios para a definição e uso dos IGs?	É possível usar "Delegação de permissões" e "grupos de interesse negativos" para esta tarefa.
API PA e inclusão de tags no servidor	Como a API PA funciona com a inclusão de tags no servidor?	A tag base no navegador do usuário precisará redirecionar a chamada da API para o restante das tags no lado do servidor, o que permitiria o registro da chamada.
Teste do Chrome (modo a/b)	Espera-se que as SSPs também passem esses rótulos em solicitações de lance RTB? Se sim, como?	Sim, a expectativa é que os rótulos sejam transmitidos da SSP para a DSP. As entidades são incentivadas a acessar o marcador e compartilhar o valor sem modificações com os parceiros usando esta extensão de dispositivo.
Armazenamento e uso de dados	Você tem mais informações sobre como os dados são armazenados e para onde são transferidos?	Não fornecemos orientação jurídica, mas sim nossa abordagem/pensamento geral sobre armazenamento de dados, retenção e outras questões de privacidade. Consulte este link (em inglês) com perguntas frequentes sobre compliance relacionadas à privacidade.
Segurança da API	Preocupações sobre código malicioso do lado do cliente que manipula o valor de retorno da função generateBid().	Discutimos o problema aqui , e parte do feedback foi incorporado à proposta da agregação privada.
Destino personalizado	Ao usar chamadas reportEvent de destino personalizado, você sabe se uma origem de relatórios personalizados (não para o comprador nem para o vendedor) pré-registrada como parte de um IG em allowedReportingOrigins precisa ser declarada pelo DSP em reportWin usando registerAdBeacon?	Não, ele não precisa ser registrado novamente no reportWin e pode ser usado diretamente no reportEvent, conforme documentado aqui.
Restrições da API	Tamanho do IG durante a criação e a atualização.	O tamanho da atualização foi atualizado para 1 MB, correspondendo ao novo limite de 1 MB (de 50 KB) para criação do IG.
Restrições de k-anonimato	K-anonimato para anúncios com tamanhos diferentes.	Publicamos o valor de K-anonimato em dezembro de 2023, que afirma que o tamanho do anúncio vai começar a ser verificado "algum pouco depois de 2025". Não há como excluir o tamanho porque ele pode ser um vetor de rastreamento entre sites, conforme descrito na reunião da WICG de 11 de outubro.
Segurança da API	Um player malicioso pode falsificar o "nome do host" de uma página?	A API é compatível com um conjunto de subchaves para o nome do host do editor. Como o navegador está configurando a chave, parece difícil contornar esse mecanismo.
Uso da API	As funções ForDebuggingOnly não devem ser recomendadas para uso em produção.	Estamos prestes a reafirmar ao ecossistema que as funções forDebuggingOnly não são adequadas para problemas além da solução de problemas pós-3PCD.
Mais ferramentas de depuração necessárias	O ForDebuggingOnly não é suficiente para entender os problemas que podem acontecer antes de scoreAd().	Gostaríamos de receber mais feedback sobre essa diferença neste link.
Desativação permanente de grupos de interesse	Pedido para permitir que os usuários desativem permanentemente a criação de IGs especiais.	Nossa estratégia tem sido não permitir que os usuários recusem em nível de IG, já que a semântica não é compreensível para os usuários no momento em que as coisas estão acontecendo.
Melhorar a documentação	Use a mesma capitalização para o parâmetro renderUrls nas especificações e na explicação.	Agradecemos o feedback e continuaremos atualizando a documentação.
Suporte à transação da API Protected Audience	Solicitação de mais opções para o suporte a transações da API Protected Audience.	No momento, a equipe do Chrome está avaliando o que podemos fazer para oferecer suporte a isso pelo 3PCD.
Macros	Compatibilidade com macros necessária para manter o tamanho de IGs abaixo do tamanho máximo.	Uma atualização recente na explicação resolveu parcialmente essa solicitação.
API ReportLoss no nível do evento	Solicitação da API ReportLoss no nível do evento.	Embora os relatórios de perda no nível do evento representem um grave risco de privacidade, acreditamos que as metas subjacentes dessa solicitação podem ser atendidas com modificações adequadas na API Private Aggregate. Clique aqui para enviar seu feedback.
Uso da API	Como os métodos forDebuggingOnly se comportam se nenhum lance de pontuação for maior que 0?	Se a pontuação for menor ou igual a 0, será uma perda automática. Portanto, reportAdAuctionloss será invocado.
Padronização	Não há alinhamento entre os usuários do valor de entrada/saída da função generateBid() da API PA.	Recomendamos a todos os parceiros que encaminhem esse problema (ou semelhantes) ao IAB Tech Lab. Esse grupo está trabalhando especificamente em padrões do setor para APIs como a Protected Audience.
Segurança da API	Quais dados de nossos IGs o Google pode ver?	O K-anonimato depende de fortes proteções de privacidade para evitar o vazamento de dados sensíveis do usuário para qualquer parte, incluindo o Google. O Google também está desenvolvendo uma implementação de terceiros (Fastly) dessa camada para minimizar esse risco.
Teste do Chrome (modo a/b)	Os usuários com acesso restrito "k-anon" podem ser excluídos dos testes?	Mostramos o status de k-anonimato nos relatórios, conforme explicado aqui.
Brand safety	Ofereça suporte a casos de uso de brand safety em que os anúncios não são veiculados, dependendo da lista de sites ou palavras-chave bloqueados.	Esses casos de uso de brand safety já são possíveis com a API PA. Para que uma campanha publicitária segmente negativamente um conjunto de domínios, é possível armazenar a lista de bloqueio no próprio IG e usar um filtro Bloom se a listagem de cada um ocupar muito espaço. Eles também podem retornar a decisão de permitir ou negar do servidor de chave-valor usando uma UDF que procura a resposta com base na combinação da chave que identifica a campanha publicitária e o nome de domínio incluído na solicitação de chave-valor. A API Protected Audience também permite que a SSP e a DSP transmitam para o leilão informações sobre o contexto da página. Isso pode incluir, por exemplo, uma lista de temas ou palavras-chave sensíveis na página. A lógica de lances da DSP pode comparar essas informações com outras informações armazenadas sobre onde o anúncio não deve aparecer e optar por não definir lances quando apropriado. O feedback do ecossistema de apps é bem-vindo sobre casos de uso específicos que eles acreditem não ser possíveis.
Delegação de permissão	Como funciona a delegação de permissões?	Compartilhamos a documentação sobre a delegação de permissões neste link.
Solicitações por lote	Use a solicitação POST para alguns URLs da API PA para dar suporte à solicitação em lote.	Gostaríamos de receber seu feedback neste link.
Melhorias na API	Campos que provavelmente não devem ser usados (como X-fledge-bidding-signals-format-version).	Estamos discutindo o problema e esperamos receber mais feedback aqui.
Melhorias na API	Solicitação de transmissão do consentimento do GDPR para o fornecedor de medição e veiculação de anúncios de terceiros.	Essa funcionalidade é compatível com o uso da API de substituição de macros ReplaceInURN, conforme explicado aqui.
Otimização de criativos dinâmicos	Como a API Protected Audience oferece suporte à otimização de criativos dinâmicos?	Estamos discutindo esse caso de uso e compartilhamos possíveis soluções aqui.
Melhorias na API	Solicitação de URL para veiculação de anúncios de terceiros que consegue extrair o contexto do IG, principalmente o nome correspondente ao IG que venceu o leilão.	Essas solicitações podem aumentar o risco de rastreamento para os usuários. Estamos discutindo o problema e queremos receber mais feedback aqui.
Segurança da API	Preocupação com o tamanho de "IG blob" vazar informações sobre os IGs que foram selecionados.	Como mencionado na seção "Considerações sobre privacidade" da explicação da API Chrome B&A, o tamanho do blob não depende de nenhuma das entradas em navigator.get InterestGroupAdAuctionData(). Ele apenas empacota todos os IGs no dispositivo. Isso garante que o tamanho do blob seja relativamente consistente em uma página e limita a capacidade de vazamento de informações entre sites. Projetamos dessa maneira exatamente por esse motivo.
Teste do Chrome (modo a/b)	Qual é a postura das outras SSPs em relação à perda do primeiro carregamento em relação à configuração de cookies e aos testes facilitados pelo Chrome?	Não recebemos nenhum problema significativo (embora outras pessoas tenham reconhecido essa situação), mas o feedback do ecossistema é bem-vindo se esse for um problema significativo.
Suporte ao Teste A/B	Solicite suporte para o teste A/B da API PA.	Discutimos essa solicitação na reunião de novembro do WICG, e queremos receber mais feedback neste link.
Tamanhos de anúncio	Quem escolhe o tamanho de um leilão da Protected Audience?	Respondemos nestas Perguntas frequentes.
Melhorias na API	Solicitação para configurar o serviço de chave-valor para aceitar o caminho /bidding-signals/v1/getvalues.	Adicionamos prefixos de caminho de suporte a esta solicitação de envio.
Uso da API	Como um editor pode criar o IG com o código se ele deveria estar na base do anunciante para que ele possa dar lances nele?	As respostas precisam vir de algum parceiro de adtech, ou seja, uma DSP ou SSP que queira participar de leilões da Protected Audience e criar uma maneira de esses públicos-alvo virem de uma fonte externa. Discutimos isso mais detalhadamente neste problema do GitHub.
Melhorias na API	Solicitação de possibilidade de vincular IGs negativos a anúncios em "grupos de interesse positivos".	Estamos considerando essa solicitação e compartilhamos uma possível proposta de suporte aqui.
Número de fragmentos	Solicitação de suporte para transmitir o "suporte a shard_num" nos metadados.	Depois desse feedback, adicionamos o suporte a shard_num.
Uso da API	Solicitação de estimativa de sobrecarga de chaves no servidor K/V.	Compartilhamos nossas ideias e queremos receber seu feedback aqui.
K-anonimato	Pedido de esclarecimento e melhoria da granularidade do contador de K-anonimato.	Esclarecemos a granularidade do contador de K-anonimato.
Depuração	Solicitação para melhorar os recursos de depuração da API PA após as recentes mudanças propostas para forDebuggingOnly.	Estamos discutindo a solicitação aqui e esperamos receber mais feedback aqui.
Tamanho do anúncio	Solicitação de tamanho do espaço do anúncio como um indicador adicional do BTS.	Compartilhamos uma proposta de apoio a essa solicitação neste link.
Segurança da API	É possível restringir o uso de "runAdAuction()" com base em uma origem?	Compartilhamos uma resposta detalhada aqui.
Instagram total	Pedido para aumentar a vida útil dos IGs de 30 para 90 dias.	Estamos analisando a solicitação e agradecemos seu feedback neste link.
Uso da API	É possível fazer um leilão da Protected Audience em paralelo com os lances de cabeçalho e a chamada do servidor de anúncios do editor?	Estamos discutindo a solicitação e receber feedback adicional neste link.
Depuração	Pedido de melhor suporte às extensões de depuração da API Chrome PA que se comunicam com o DevTools.	Queremos oferecer mais ferramentas de depuração e aceitamos outras sugestões neste link.
Uso da API	Notificações de perda não são acionadas se nenhum lance dos vendedores dos componentes chega ao vendedor principal.	Explicamos a lógica por trás disso aqui.
Melhorias na API	Solicitação de suporte do TextEncoder no worklet de lances da API Protected Audience.	Estamos considerando essa solicitação e receber feedback neste link.
Uso da API	Chamadas de rede e execução de lógica no cliente podem bloquear a linha de execução principal e causar desafios de execução de JS que podem afetar a SEO.	Estamos discutindo o problema e queremos receber mais feedback aqui.
Uso da API	É possível que as DSPs usem o funil de lances atual do servidor para avaliar e enviar os candidatos a anúncios como parte do "perBuyerSignal" para serem usados em leilões no dispositivo?	Estamos discutindo esta pergunta e qualquer feedback adicional é bem-vindo neste link.
Estender dados de oportunidade de lance	Solicitação para estender os dados de oportunidade de lance transmitidos pelo navegador à SSP com uma lista de domínios de origem exclusivos dos IGs ativos no navegador.	Estamos discutindo a solicitação e receber feedback adicional neste link.
ORTB	Solicitação de dois novos hooks para leilãoConfig e geração de adaptação de resposta de Bid no ORTB.	Estamos analisando o problema e queremos receber mais feedback aqui.
Vitória anterior	Solicitação para IG definindo um prevWinsTransformer, que usa as vitórias anteriores do IG e gera uma coisa serializável.	Estamos analisando o problema e queremos receber mais feedback aqui.
Tipos de conteúdo	Estratégia para a evolução dos tipos de conteúdo, por exemplo, JSON para algo como CBOR.	Estamos analisando o problema e queremos receber mais feedback aqui.
Prebid na API Protected Audience	Solicitação de uma amostra de página do editor que usa o Prebid para executar um fluxo completo para o leilão da Protected Audience.	Estamos considerando essa solicitação e recebemos mais feedback do ecossistema sobre por que isso precisa ser priorizado. Também vimos participantes do ecossistema criando amostras de páginas do editor que estão disponíveis para outras pessoas no ecossistema para demonstração.

Serviços de leilão protegido

Tema do feedback	Resumo	Resposta do Chrome
Ambientes de execução confiáveis (TEEs)	É mais caro executar ambientes de execução confiáveis em nuvens públicas em vez de data centers de adtech no local?	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. Veja mais detalhes abaixo sobre o suporte no local. As adtechs já mencionaram que a execução de serviços na nuvem é mais cara do que os data centers no local. 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.
(Informado nos trimestres anteriores) TEE no local	Quais são os requisitos para alguém se tornar um provedor de TEE?	Nossa resposta é semelhante aos trimestres anteriores: "Embora continuamos a analisar o suporte para opções além das soluções baseadas em nuvem pública, inclusive considerando quais implantações seriam aceitáveis do ponto de vista da segurança, ainda não temos planos de oferecer suporte a 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 na nuvem é o mais benéfico para o ecossistema. No entanto, agradecemos mais feedback sobre por que esse requisito é necessário e viável, dado as restrições de privacidade e segurança."
Limites do servidor de chave-valor	Limites de chaves por leilão por servidor	Estamos discutindo o problema e queremos receber mais feedback aqui.
Restrições de k-anonimato	Confirmação de que o K-anonimato não será aplicado no futuro em chaves K/V.	No momento, não temos planos para aplicar k-anonimato a chaves de solicitações de servidores K/V, já que pretendemos mover esses servidores para o TEE no futuro.
Building K/V	O Google tem artefatos pré-criados disponíveis para o serviço K/V?	No momento, não temos artefatos pré-criados para o servidor de chave-valor da API Protected Audience, mas podemos considerar fornecê-los se houver uma forte demanda no ecossistema.
Suporte de EgId em B&A	Solicitação de suporte para o campo experimentGroupId no código de lances e leilões e na solicitação para o serviço KeyValue do BuyerFrontEnd	No momento, o B&A não oferece suporte ao experimentGroupId, mas pretende lançar a versão Beta 2 (atualmente programado para fevereiro de 2024). Compartilhamos mais informações aqui.
Uso da API	A fusão de solicitações em HTTP pode ajudar a proteger contra invasores no caminho, mas o operador do TEE aprende os tamanhos.	Estamos discutindo a solicitação e receber feedback adicional neste link.
Melhorar a documentação	A especificação não está clara como o servidor k-v será abordado.	Estamos discutindo o problema e queremos receber mais feedback aqui.
Uso da API	Qual é a finalidade de "Ad-Auction-Result" e adAuctionHeaders?	Estamos discutindo esse problema aqui e agradecemos seu feedback.
Melhorar a documentação	Não está claro se o design v2 foi propagado para FLEDGE.md.	O site FLEDGE.md (em inglês) explica como o Chrome envia solicitações para o BYOS-KV. O design do protocolo v2 é limitado apenas ao TEE-KV e não é compatível com o Chrome no momento.

Medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Medição em vários ambientes	Como o Chrome planeja oferecer suporte à medição em vários ambientes na fase provisória em que os 3PCs foram removidos do Chrome para dispositivos móveis, mas o Sandbox de privacidade para Android ainda não está disponível?	No Android, estamos trabalhando para expandir a cobertura de PSB/ARA. A API Attribution Reporting (ARA) está disponível no Android 13 e 14, e planejamos começar a expansão para o Android 11 e 12 ainda este ano, embora isso esteja sujeito a mudanças. Não poderemos expandir para o Android 10 ou versões anteriores, mas esperamos que a porcentagem de dispositivos que ainda usam o Android 10 ou versões anteriores seja menor em 3PCD e diminua naturalmente à medida que os usuários fazem upgrade. Esperamos receber mais feedback do ecossistema sobre essa solicitação.
Filtragem	Filtrando "conversões" da verificação de criativos.	Entramos em contato com essa parte interessada para entender melhor a solicitação e agradecemos mais feedback do ecossistema sobre esse problema.
Servidores de anúncios de terceiros	Como a API PA e a ARA funcionam com tags do servidor de anúncios de terceiros?	Assim como os pixels funcionam com tags de impressão e de clique atualmente, um servidor de anúncios pode definir registros de origem e acionador para a ARA por conta própria (inclusive de leilões da Protected Audience) ou configurar redirecionamentos para transmitir e aceitar registros de origem e acionador para ARA.
DCM	Suporte à atribuiçãosrc pelo DCM e outros servidores de anúncios de terceiros.	Esse é um problema relacionado ao DCM e foi resolvido pela equipe do DCM neste problema do GitHub.
Chave de agregação hierárquica	É necessário dividir todo o orçamento de contribuição em todas essas chaves hierárquicas?	Discutimos e fornecemos uma resposta a essa parte interessada. Ao usar uma estrutura de chave hierárquica, a adtech precisa considerar que o orçamento de contribuição é compartilhado entre todas as principais saídas de uma impressão.
Use subdomínios diferentes	Agora, os relatórios de atribuição funcionam com fontes e acionadores registrados em subdomínios diferentes, mas no mesmo eTLD+1?	Discutimos essa questão com a parte interessada e propomos as seguintes soluções. Eles podem alterar a configuração do URL para que tenham a mesma origem de relatórios na fonte e no acionador ou redirecionar o URL atual para um URL comum antes de fazer os registros. Podemos receber mais feedback do ecossistema se as soluções propostas não funcionarem para o caso de uso deles.
(Também informado nos trimestres anteriores) Suporte à produção	Quais níveis de serviço estão disponíveis para os parceiros de suporte que usam a ARA?	Nossa resposta não mudou em relação aos trimestres anteriores: "O Google oferece vários canais para que as adtechs informem problemas técnicos e permitam os encaminhamentos necessários para resolver esses problemas. Além disso, o Chrome espera desenvolver e escalonar ainda mais um processo para resolver problemas técnicos e encaminhamentos que afetam a integridade do ecossistema. O Chrome tem o compromisso de garantir os recursos para essa iniciativa. Consulte nossa postagem para desenvolvedores se quiser mais informações sobre os fóruns públicos e privados para feedback e encaminhamento.
(Também informado nos trimestres anteriores) Cronograma	O Google terá a "Fase 2 no nível do evento flexível completo" pronta quando o teste quantitativo de CMA estiver pronto?	O nível de evento totalmente flexível da Fase 2 vai ser disponibilizado no Chrome no primeiro trimestre de 2024. Acompanhe o status aqui.
(Também informado nos trimestres anteriores) Funil de conversão	Informar vários domínios que foram usados na conversão.	Esse caso de uso é possível porque vários destinos foram adicionados. Seu feedback é muito importante.
Rótulos de teste dos relatórios	Os recursos de relatórios permitem que os testadores informem de qual grupo o usuário (navegador Chrome) faz parte (modo A/B)?	Estamos trabalhando na publicação de um guia de teste para capturar rótulos de teste do Chrome no ARA.
Documentação	A documentação de Attribution-Reporting-Register-Source declara que o vencimento será arredondado para o dia mais próximo. Como esse prazo será arredondado?	Arredondado para o dia mais próximo significa que 1,5 dia será arredondado para 2 dias.
Use subdomínios diferentes	Peça para receber relatórios da API Attribution Reporting em um subdomínio diferente do registro de origem e acionador.	Isso não é possível. Os redirecionamentos HTTP podem ser aplicados, mas não há configuração para isso. Queremos receber mais feedback do ecossistema sobre por que essa solicitação é útil.
Atraso na geração de relatórios no nível do evento	atribuição de sete dias e janela de geração de relatórios, mas devido ao atraso na geração de relatórios no nível do evento, pode levar mais de oito dias para que todos os relatórios sejam enviados.	Reconhecemos o feedback e aceitamos outras informações do ecossistema sobre se esse atraso nos relatórios a nível de evento é um problema ou não, especialmente com a mudança de janelas de relatórios de eventos fixas para flexíveis.
Acionadores de conversão	Os acionadores de conversões que ocorrem entre o fim da primeira event_report_window (1h) e o prazo de validade (1 Day) não geram relatórios.	Lançamos uma configuração flexível no nível do evento, que passa das janelas fixas para as flexíveis.
Ruído	Os relatórios de evento têm uma conversão falsa com ruído, como descrito na explicação do GitHub?	Sim, o ruído é aplicado a relatórios de evento e representa todos os estados de saída possíveis, incluindo trigger_data diferentes, não relatando nada quando um acionador realmente ocorreu ou possivelmente relatando vários relatórios falsos para o evento. A porcentagem de ruído tem código aberto e pode ser flexível com configurações flexíveis no nível do evento.
Filtragem	O uso do filtro com a API Attribution Reporting ainda vai consumir o orçamento de contribuição, mesmo que ele não registre a chave de agregação.	Isso está funcionando como esperado, já que aggregatable_trigger_data só oferece suporte à filtragem nas chaves do acionador, não nos valores / chaves. Os filtros de nível superior oferecem suporte à filtragem das chaves, mas isso é compartilhado por evento + agregado, por isso não é aplicável aqui. Se você precisar filtrar as chaves, receba mais feedback do ecossistema neste link.
Limite de armazenamento	Solicitação para introduzir um limite de armazenamento que também considere a origem dos relatórios.	Na versão M120, um aumento de 1.024 para 4.096 desse limite vai entrar em vigor. Envie feedback para feedback do ecossistema.
Atribuição direta	Como conseguir métricas para situações em que um usuário visita um anunciante diretamente sem passar por um editor, já que o processo padrão de geração de relatórios de atribuição não abrange esse cenário?	A ARA foi projetada apenas para recuperar informações entre sites (ou seja, a combinação de informações entre sites de editores/anunciantes). Se não for necessário fornecer informações entre sites, a ARA não ajudará você. Estamos discutindo o problema e queremos receber mais feedback aqui.
Horário da denúncia	Receba calendar_report_time a hora de um timeserver em vez de usar o horário da máquina local.	No momento, não temos planos de usar um servidor de tempo, e não recebemos muita demanda da adtech. Gostaríamos de receber mais feedback do ecossistema sobre se esse seria um recurso útil.

Serviço de agregação

Tema do feedback	Resumo	Resposta do Chrome
(Também informado nos trimestres anteriores) Solução local	O serviço de agregação pode ser implantado em data centers no local?	Estamos analisando possíveis opções de suporte além das soluções baseadas na nuvem, mas no momento não é viável oferecer suporte aos TEEs no local devido às limitações de segurança locais que exigiriam uma avaliação demorada do Sandbox de privacidade. 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 GCP além da AWS) é o mais benéfico para o ecossistema. No entanto, gostaríamos de receber mais feedback neste link sobre por que esse requisito é necessário.
Enclave	Se o enclave não estiver ativo ou receber um erro repentinamente, como ele é processado pela API Aggregate Service?	Vamos usar novas tentativas se o enclave falhar na inicialização e no escalonamento automático para exibir novas instâncias se uma delas for considerada não íntegra. As adtechs também podem investigar falhas usando registros. Para depurar falhas de enclave na AWS, as adtechs podem verificar o status da instância do EC2 fazendo login no Gerenciador do Console da AWS. As adtechs também podem fazer login na instância do host do Nitro Enclave e verificar o status do enclave com a ferramenta nitro-cli (link em inglês). Se houver erros/falhas, eles podem usar a interface de linha de comando da AWS para visualizar os registros e investigar mais. Para depurar falhas de enclave no GCP, as adtechs podem verificar o status da instância por meio do Console do Cloud. Eles também podem verificar se há erros usando o list-errors-command.
Use subdomínios diferentes	Solicite o registro de vários (sub)domínios para usar diversas instâncias de serviços de agregação, tanto em ambientes de desenvolvimento quanto de produção.	O registro do site foi lançado para que as adtechs possam registrar vários subdomínios do mesmo site em uma conta da AWS ou projeto do GCP. Eles também poderão registrar o mesmo domínio em várias contas da AWS ou projetos do GCP. Agradecemos o feedback do ecossistema.
Orçamento de privacidade	Como depurar melhor problemas relacionados ao esgotamento do orçamento de privacidade?	No momento, estamos buscando soluções para fornecer mais detalhes sobre o orçamento esgotado e melhorar nossa documentação para descrever as estratégias que as adtechs podem usar para minimizar as ocorrências desse erro. Vamos atualizar a página do serviço de agregação no GitHub assim que tivermos uma proposta.
Valor de épsilon	Solicitação para aumentar o valor de épsilon.	O valor épsilon do serviço de agregação será mantido como um intervalo de até 64, para facilitar a experimentação e o feedback sobre diferentes parâmetros durante o 3PCD. Avisaremos com antecedência ao ecossistema antes que os valores do intervalo épsilon sejam atualizados.
Binários	Publique um conjunto mais completo de binários para versões do serviço de agregação.	Estamos analisando essa solicitação e envie seu feedback.
Uso da API	Compartilhamento de dados com os coordenadores, conforme os Termos de Serviço do coordenador.	Precisamos de mais esclarecimentos sobre esse problema e queremos receber seu feedback.

API Private Aggregate

Tema do feedback	Resumo	Resposta do Chrome
Depuração	Ative opções adicionais para depuração durante o teste no modo B.	Conforme compartilhado neste problema do GitHub, vamos permitir o modo de depuração no modo B. Essa qualificação vai mudar na versão M121 Beta em 50% do tráfego no modo B a partir de 31/01. Vamos enviar um aviso antes do lançamento para a versão Stable.

Limitar o rastreamento oculto

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

Tema do feedback	Resumo	Resposta do Chrome
ChromeOS	Ofereça suporte às dicas de cliente do user agent para a quantidade de bits do Chrome OS.	Compartilhamos uma resposta a essa solicitação aqui.

Proteção de IP (antigo Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Abuso	O Google pode acessar os dados de navegação do usuário com a proteção de IP.	A proteção de IP tunela o tráfego por meio de dois proxies (um executado pelo Google e outro por outra empresa). Isso garante que o Google não tenha acesso aos dados de navegação. Todo o tráfego é criptografado entre o Chrome e os proxies, portanto, o proxy do Google não tem informações sobre quais sites estão sendo navegados. Além disso, o sistema usa tokens de autenticação mascarados para minimizar o acesso a identificadores de usuários nos proxies. Tudo que o proxy do Google vai perceber é que um cliente desconhecido em um IP específico está usando o sistema de proxy. Não há informações disponíveis sobre os sites visitados ou os anúncios carregados.
Suporte ao modo headless	Como os bots que usam plug-ins e o modo headless serão gerenciados?	Reduzir o abuso da Proteção de IP é uma prioridade fundamental para a equipe. Analisamos cuidadosamente esses cenários (entre muitas outras ameaças em potencial também) e estamos trabalhando em opções que ajudarão a reduzir a probabilidade de abuso ou fraude ser bem-sucedido. Embora não possamos fornecer mais detalhes no momento, esperamos fornecê-los em breve e esperamos continuar a discussão.
Proxies atuais	Como a proteção de IP funcionará com as configurações de proxy existentes no Chrome?	As configurações de proxy atuais vão continuar sendo compatíveis. Os usuários poderão configurar seus próprios proxies personalizados como antes.
Denúncia de abuso	Como a denúncia de abuso será tratada?	Teremos mais detalhes para compartilhar em breve, mas planejamos criar um mecanismo para organizações e usuários compartilharem denúncias e provas de abuso.
Regulamentações	Como a proteção de PI seguirá as leis e regulamentações locais?	O Google tem o compromisso de obedecer à legislação e aos regulamentos locais. Portanto, não é permitido contornar esses bloqueios no nível do país. Esse recurso não é para evasão.
Limitar recursos	A Proteção de IP bloqueará nossa resposta cibernética?	Nós nos esforçamos para encontrar um equilíbrio entre proteger os usuários de serem rastreados na Web com base em seus endereços IP e minimizar a interrupção das operações normais dos servidores, incluindo o uso de endereços IP para combate ao abuso. Embora não possamos fornecer mais detalhes no momento, esperamos fornecê-los em breve e esperamos continuar a discussão.
Cronograma	Se ela for aplicada antes do final de 2024, será quase impossível se preparar.	Inicialmente, o Chrome lançará a proteção de IP como uma configuração opcional para usuários em regiões específicas, entendendo que isso pode ser uma mudança significativa na forma como algumas empresas dependem de endereços IP e buscando minimizar as interrupções conforme o ecossistema se ajusta. A proteção de IP fará a transição para o padrão a partir de 2025.
Uso da API	O usuário terá a opção de ativar a proteção de IP na primeira vez que abrir o Chrome?	Planejamos oferecer aos usuários a opção de usar a proteção de IP ou não. O mecanismo de apresentação dessa opção aos usuários ainda está sendo desenvolvido.
Uso da API	Quantos dados são registrados e por quanto tempo eles são retidos?	Teremos mais detalhes para compartilhar no futuro, mas planejamos registrar quantidades mínimas de dados.
Feedback negativo	Os usuários podem usar VPNs se preferirem usá-las. Não são necessárias APIs PS.	O objetivo da proteção de IP é impedir o uso de endereços IP para fins de rastreamento entre sites. O objetivo dela não é ser um serviço de VPN.
Segurança da API	Como evitar que o primário acesse o endereço IP e encaminhe informações pelo parâmetro do cabeçalho?	Inicialmente, estamos nos concentrando em terceiros porque entendemos que eles têm o maior impacto. Vamos continuar monitorando o ecossistema para determinar se precisamos aprimorar nossa abordagem e evitar violações em grande escala.
Uso da API	Confirmação necessária se o entendimento do uso da API estiver correto.	A proteção de IP usa uma abordagem baseada em lista para identificar qual tráfego de terceiros passa pelos proxies. As origens que estão na lista, mas são acessadas em um contexto próprio, não são encaminhadas por proxy por esse serviço para essas conexões. Por exemplo, se uma empresa de análise estiver na lista de domínios e um usuário navegar diretamente para o site, esse site ainda poderá observar o endereço IP do usuário em vez do endereço IP por proxy. No entanto, se esse domínio na lista fizer uma solicitação de rede em um contexto de terceiros, a conexão será colocada em proxy e o endereço IP original do usuário não ficará visível para o site. Nosso principal objetivo é impedir o rastreamento de usuários na Web entre sites. Estamos analisando alguns detalhes antes de compartilhar mais informações sobre os domínios de terceiros em que pretendemos focar inicialmente.
VPN	Preocupação com o fato de a proposta do Google ser desvantajosa para outros provedores de VPN.	O objetivo da proteção de IP é impedir o uso de endereços IP para fins de rastreamento entre sites. O objetivo dela não é ser um serviço de VPN.
Cronograma	Qual é o cronograma da proteção de IP?	A proteção de IP será ativada inicialmente. Isso vai ajudar a garantir que o usuário tenha controle sobre as decisões de privacidade e que o Google possa monitorar o comportamento em volumes menores. A proteção de IP será lançada em fases, com a transição para o padrão a partir de 2025. Como todas as nossas propostas de privacidade, queremos garantir que vamos aprender à medida que avançamos e reconhecemos que pode haver considerações regionais a serem avaliadas. Usamos uma abordagem baseada em lista, e apenas os domínios listados em um contexto de terceiros serão afetados. Estamos cientes de que essas propostas podem causar interrupções indesejadas em casos de uso legítimos. Por isso, nos concentramos apenas nos scripts e domínios que são considerados como rastreamento de usuários.
Limitar recursos	Não é mais possível pesquisar os endereços IP do usuário no WHOIS.	Nossa posição é que o endereço IP é um identificador estável cujo uso pode ter implicações de privacidade para os usuários, incluindo o uso de metadados associados a ele, como o ASN. Com a proteção de IP, tentamos encontrar o equilíbrio certo entre privacidade e suporte a uma experiência do usuário útil na Web, por exemplo, com nossa abordagem de geolocalização por IP. Se esses metadados não forem suficientes para seu caso de uso, podemos conversar mais.
Referenciador de HTTP	O referenciador de HTTP original será preservado?	Não há planos para alterar o cabeçalho Referer como parte da proteção de IP, conforme discutido aqui.
Código aberto	Os códigos-fonte da proteção de IP serão de código aberto?	A maior parte do software aqui é de código aberto como parte dos projetos do Chromium e do Envoy Proxy, mas alguns componentes têm código fechado, como explicado aqui.

Mitigação de rastreio por redirecionamento

Tema do feedback	Resumo	Resposta do Chrome
Exclusão do armazenamento	A mitigação de rastreamento de rejeição (BTM, na sigla em inglês) exclui o armazenamento compartilhado e o armazenamento da API Attribution Reporting?	Não foi nossa intenção que a BTM excluísse o armazenamento da API do Sandbox de privacidade (ARA, API PA, armazenamento compartilhado, agregação privada e Topics). O BTM só deve excluir os tipos de armazenamento com riscos de privacidade se acessados em um contexto de terceiros. Uma correção de bug está em andamento.
Uso da API	Qual versão do Chrome o BTM será ativado? O rastreamento de redirecionamentos/rejeições após 10 segundos será considerado um Rastreamento de rejeições por BTM ou não?	Na versão M116, os BTMs foram lançados para 100% dos usuários com 3PCs bloqueados. Atualmente, um redirecionamento após 10 segundos não é considerado uma rejeição.
Caso de uso de login	Sincronizar/manter automaticamente o estado de login em vários domínios, sem nenhuma punição por comportamento semelhante ao acompanhamento?	Estamos discutindo essa solicitação aqui. Queremos receber mais feedback do ecossistema.
Jornada do usuário	Atualmente, o BTM resulta em jornadas do usuário complicadas.	Estamos discutindo o problema e compartilhamos nossos pensamentos sobre ele aqui.
API Storage Access	O BTM no Chromium vai honrar as concessões de 3PC da API de acesso ao armazenamento (SAA, na sigla em inglês).	Conversamos sobre esse problema com os participantes do ecossistema no TPAC 2023, e seu feedback está disponível neste link.
Impacto nos relatórios de anúncios	Com esse recurso, empresas menores no ecossistema podem usar outras APIs do Sandbox de privacidade, como a ARA, para realizar casos de uso relacionados a anúncios.	As mitigações de rastreio por redirecionamento visam evitar a violação dos 3PCDs. A ARA é uma das muitas soluções alternativas de métricas que as empresas terão disponíveis após o 3PCD, mas nenhuma empresa é obrigada a usá-la.

Orçamento de privacidade

Nenhum feedback foi fornecido neste trimestre.

Fortaleça os limites de privacidade entre sites

Conjuntos de sites relacionados (antigos conjuntos primários)

Tema do feedback	Resumo	Resposta do Chrome
(Também informado nos trimestres anteriores) Limite de domínios de conjuntos de sites relacionados (RWS)	Solicitação para expandir o número de domínios associados.	No momento, não esperamos aumentar o limite numérico. O limite foi estabelecido com base em considerações de privacidade do usuário, no feedback das partes interessadas do ecossistema no W3C e na consideração de implementações parecidas em outros navegadores. Saiba mais nas postagens do blog (1, 2). Recomendamos examinar os casos de uso que exigem acesso a cookies entre sites além do limite numérico e aproveitar nossa orientação para casos de uso de identidade, incorporações autenticadas e casos de uso de publicidade.
Escopo do acesso a cookies	Preocupação de que todos os domínios em um RWS tenham concedido acesso para ler e gravar todos os cookies de todos os domínios.	A associação a um RWS não permite que os membros acessem os cookies uns dos outros. Em vez disso, isso permitiria que os membros acessassem os próprios cookies quando incorporados a outros sites com o mesmo RWS (após uma invocação da API Storage Access).
(Também informado nos trimestres anteriores) Integração RWS + CHIPS	Solicitação de integração de RWS + CHIPS para dar suporte a casos de uso como testes A/B	Continuamos a solicitar casos de uso e solicitações para esse recurso neste link. Por enquanto, avaliamos a necessidade desse recurso em relação aos riscos de interoperabilidade entre navegadores.
Uso da API	E se um usuário remover localmente sites manualmente das configurações do Chrome?	No momento, não existe uma forma de um usuário excluir manualmente um site de um grupo. Em vez disso, o usuário pode desativar o recurso "sites relacionados" usando o botão abaixo de "Bloquear cookies de terceiros" ou "Bloquear todos os cookies de terceiros" no novo painel de configurações da Proteção antirrastreamento.
Comunicação entre domínios	O RWS permite a comunicação entre domínios?	Estamos fazendo um teste de origem para expandir o acesso a alguns tipos de armazenamento não particionado (incluindo localStorage e canal de transmissão) pela API Storage Access que vai permitir essa comunicação. Esse recurso está disponível em todas as configurações compatíveis da API Storage Access, no mesmo RWS e também em sites que não são do RWS. Esta postagem do blog tem mais informações.
requestStorageAccessFor	document.requestStorageAccessFor(origin) pode retornar uma promessa que é resolvida com os cookies entre sites da origem?	Isso não é possível. Como a invocação acontece pela origem de nível superior (que é diferente da origem transmitida como argumento), isso violaria a mesma política de origem.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
(Também informado nos trimestres anteriores) Publicidade nativa	Suporte a frames isolados para publicidade nativa.	Conforme avisamos (em inglês) que algumas tecnologias do Sandbox de privacidade vão ser necessárias no futuro para reforçar ainda mais as proteções. Por exemplo, para a API Protected Audience, vamos exigir o uso de Fenced Frames para renderizar anúncios e deixar de usar os relatórios de eventos a partir de 2026. Fornecemos datas "no mínimo" para cada um desses requisitos futuros. Assim, o setor tem clareza quanto à evolução pretendida das APIs. 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. Por exemplo, vamos melhorar o Fenced Frames antes do requisito a partir de 2026 para manter a compatibilidade com anúncios nativos e em vídeo com a API Protected Audience. De acordo com nossos compromissos, a CMA será consultada sobre essas mudanças, e vamos continuar interagindo com o feedback do ecossistema antes de implementar esses requisitos.
Diferença de tamanho entre plataformas	Informa que o tamanho do conteúdo exibido no Fenced Frame parece diferente em computadores e smartphones.	Estamos analisando o problema e agradecemos seu feedback neste link.
Renderizar adComponent	Fornece exemplos de códigos sobre como renderizar adComponents no Fenced Frame?	Procuraremos fornecer documentação sobre como usar navigator.adAuctionComponents(numComponents) dentro do Fenced Frame para exibir um anúncio composto de várias partes.
Melhorias na API	Forneça mais indicadores para a FencedFrames (melhorar, por exemplo, brand safety).	Gostaríamos de receber seu feedback neste link.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Caso de uso antiabuso / antifraude	Potencial do uso de armazenamento compartilhado para detecção de fraudes ou anomalias.	Discutimos essa possibilidade neste link e agradecemos seu feedback.
Limite de frequência	Ofereça uma maneira de usar o limite de frequência entre sites fora da API PA.	Agradecemos o feedback informando que o limite de frequência entre sites, fora da API PA, é um caso de uso valioso. No momento, o Sandbox de privacidade continua focado no conjunto atual de APIs para 3PCD. No entanto, gostaríamos de receber mais feedback do ecossistema sobre esse caso de uso neste link.

ÍCONES

Tema do feedback	Resumo	Resposta do Chrome
Pop-up/redirecionamentos	Como os CHIPs vão oferecer suporte aos casos de uso de autenticação incorporada que envolvem pop-ups e redirecionamentos?	Recentemente, compartilhamos algumas orientações sobre como verificar o impacto da desativação dos 3PCs no seu fluxo de trabalho de login e queremos receber mais feedback neste link.
Limite de partição	Reduza o limite geral por site e por partição para 1 KiB.	Estamos considerando essa solicitação e receber feedback neste link. Vamos continuar monitorando o feedback dos usuários à medida que lançamos o 3PCD e os desenvolvedores adotam os CHIPs e enviam feedback.
Migração de cookies	Processo recomendado para migrar um app da Web para emitir cookies como particionados que não interrompem os cookies/sessões em andamento?	Nossa sugestão de um esquema de migração foi posta aqui, mas o desenvolvedor conseguiu formular uma solução alternativa que funcionasse melhor na configuração.
Uso da API	O acesso ao armazenamento particionado é desativado quando um usuário não ativa a configuração das APIs de privacidade de anúncios?	O armazenamento particionado e os cookies particionados (CHIPs) são ativados mesmo que o usuário não ative a configuração das APIs de privacidade de anúncios, já que elas não permitem a transferência de informações entre sites. Como princípio geral, a transferência de informações entre sites está sujeita a limites, verificações ou permissão do usuário, mas isso não se aplica aos CHIPS no momento.
Uso da API	Qual é a lógica para bloquear cookies não particionados, em vez de o navegador apenas particionar "silenciosamente"?	Isso não é possível a curto e médio prazos, conforme explicado aqui.

FedCM

Tema do feedback	Resumo	Resposta do Chrome
Uso da API	Não é possível exibir um "arquivo conhecido" no eTLD+1 no ambiente de desenvolvimento.	Atualizamos o Chrome Canary para pular a busca de recursos conhecidos, conforme discutido aqui.
Uso da API	Há algum requisito específico de interação do usuário definido para solicitar permissões de login de terceiros ou usar o FedCM?	Não há requisitos específicos de interação do usuário, conforme discutido aqui.
Segurança da API	Há algum plano de ter um fluxo que permita ao cliente iniciar a FedCM, mas essencialmente os tokens são transferidos do IdP para um sistema de back-end da RP?	Estamos discutindo e agradecemos seu feedback neste link.
Permissão	Permitir que o IdP ative o recebimento do ID do cliente da RP para que os usuários possam decidir se confiam no IdP ou não.	Estamos discutindo a solicitação e receber feedback adicional neste link.
Uso da API	Pedido de mais documentação sobre a FedCM.	Reconhecemos esse feedback e continuaremos a melhorar a documentação à medida que desenvolvemos esta API.

Combater spam e fraudes

API Private State Token (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Documentação	Peça um guia detalhado para desenvolvedores sobre tokens de estado particular para ajudar nos testes.	Publicamos um guia para desenvolvedores sobre tokens de estado particular no quarto trimestre de 2023.
Verificação de idade/gênero	É difícil verificar a idade e o gênero dos públicos-alvo após a 3PCD.	No momento, os tokens de estado particular não foram criados para verificação de idade e gênero. Queremos entender melhor o caso de uso e como isso é feito hoje. Seu feedback é muito importante.