Esta página foi traduzida pela API Cloud Translation.

Relatório de feedback – 4º trimestre de 2024

Relatório trimestral do 4º trimestre de 2024 que resume o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.

Como parte dos compromissos com o CMA, o Google concordou em apresentar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas nas propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo de feedback do Sandbox de privacidade são gerados pela agregação de feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral do feedback, incluindo, entre outros: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe com prazer o feedback recebido do ecossistema e está procurando ativamente maneiras de integrar as lições às decisões de design.

Os temas de feedback são classificados pela prevalência em cada API. Isso é feito com uma agregação da quantidade de feedback que a equipe do Chrome recebeu sobre um determinado tema e a organização em ordem decrescente de quantidade. Os temas comuns de feedback foram identificados analisando os tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que aparecem nas equipes internas e nos formulários públicos do Google.

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

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

O feedback recebido recentemente pode ainda não ter uma resposta considerada pelo Chrome.

Glossário de acrônimos

ARA: API Attribution Reporting
CHIPS: Cookies com estado particionado independente
DSP: Plataforma de demanda
FedCM: Gerenciamento de credenciais federadas
IAB: Interactive Advertising Bureau
IDP: Provedor de identidade
IETF: Internet Engineering Task Force
IP: Endereço de Protocolo de Internet
openRTB: Lances em tempo real
Prorrogação: Teste do Origin
API PA: API Protected Audience (antes conhecida como FLEDGE)
PatCG: Grupo da comunidade de tecnologias de publicidade privada
RP: Entidade confiável
RWS: Conjuntos de sites relacionados (antigamente "Conjuntos primários")
SSP: Plataforma de fornecimento
UA: String do user agent
UA-CH: Dicas de cliente HTTP do user agent
W3C: World Wide Web Consortium
WIPB: IP Blindness proposital

Feedback geral, sem API/tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
Compromissos	A seção G dos Compromissos é essencial para a viabilidade do Sandbox de privacidade. Sem a garantia de que o próprio negócio de anúncios do Google vai operar exclusivamente com tecnologias do Sandbox, o risco de utilidade cada vez menor aumenta, assim como a possibilidade de desinvestimento do Google na tecnologia. Essa alienação ou redução na utilidade seria uma ameaça existencial à capacidade de segmentação com foco na privacidade na Web aberta.	Os Compromissos não garantem que o próprio negócio de anúncios do Google vai operar exclusivamente com tecnologias do Sandbox de privacidade. O Google pretende usar uma abordagem de portfólio para a capacidade de endereço, que incluirá as tecnologias do Sandbox de privacidade, da mesma forma que terceiros podem e usam. Entendemos que a abordagem de portfólio é comum em todo o ecossistema de anúncios. Acreditamos que é importante que os desenvolvedores tenham ferramentas e tecnologias que preservem a privacidade. Vamos continuar disponibilizando as APIs do Sandbox de privacidade e investindo nelas para melhorar ainda mais a privacidade e a utilidade.
Governança	O modelo de governança proposto não inclui mecanismos específicos de responsabilização em processos formais de consulta ou contestação.	Incorreto. Tanto (i) o sistema de tomada de decisão e as publicações associadas quanto (ii) o processo de contestação oferecem mecanismos específicos de responsabilização. Além disso, o Trustee de monitoramento vai supervisionar o funcionamento em detalhes.
Governança	Feedback de que o modelo não contém disposições para a criação e manutenção de um padrão em várias plataformas.	Nenhum modelo de governança pode obrigar outros atores, neste caso os navegadores, a adotar um padrão. Portanto, não propusemos um modelo que exija a adoção de padrões em várias plataformas. O Google vai continuar participando de fóruns de padrões em que fazer propostas e compartilhar experiências de implementação de propostas é uma atividade comum no processo.
Governança	Recomendamos estender o período de consulta para pelo menos dois meses. O modelo de governança proposto não oferece ao ecossistema tempo suficiente para analisar os impactos das mudanças propostas.	O período de três semanas não é o período de feedback completo para uma determinada mudança, já que os ciclos de feedback atuais (que são muito mais longos) vão continuar. Em vez disso, o processo de consulta oferece uma nova janela de feedback formal no processo atual para decisões estratégicas. Assim, terceiros vão continuar podendo dar feedback em vários fóruns (incluindo GitHub, W3C e órgãos de padrões de anúncios, como o IAB Tech Lab) durante o desenvolvimento do recurso. Ao estruturar os ciclos de feedback dessa forma, o ecossistema tem a oportunidade de analisar e compartilhar as opiniões sobre uma mudança proposta sem atrasos significativos no processo de desenvolvimento.
Governança	Solicitação de detalhes sobre planos de governança futuros.	Um resumo do modelo de governança proposto está definido no relatório do CMA do 2º e 3º trimestre de 2024 (páginas 3 a 5 aqui).
Pedido de exceção	Solicitar uma exceção para acessar cookies de terceiros (3PCs, na sigla em inglês) para os usuários que deram consentimento.	O consentimento para acesso e armazenamento de dispositivos para fins específicos de processamento de dados não indica que o usuário quer substituir a configuração de 3PC no Chrome. Permitir a substituição de configurações de 3PC de um usuário no nível do site criaria um potencial considerável de uso indevido, e seria inviável para o Chrome auditar o comportamento de todos os sites que podem levar a uma solicitação de exceção.
Sandbox de privacidade	Solicitação de taxas de ativação da API do Sandbox de privacidade.	Não temos planos de compartilhar essas informações com o ecossistema. Os desenvolvedores podem chamar as APIs em que têm o código implantado hoje para estimar a disponibilidade das APIs do Sandbox de privacidade.
Teste de origem	Há um plano para estender o teste de origem?	O teste de origem foi estendido até 14 de abril de 2025.
Sandbox de privacidade	Peça uma explicação concisa e não técnica do Sandbox de privacidade que destaque o valor comercial e garanta a adesão dos executivos.	Adicionamos recentemente uma seção de recursos para empresas ao privacysandbox.com neste link.
Modo B	Quando um navegador estiver no "Modo B", o cookie jar atual (1PC, 3PC, armazenamento local) vai permanecer ou será apagado?	O cookie jar atual não será apagado. Os cookies de terceiros permanecerão acessíveis no contexto próprio.
Abordagem atualizada para 3PCs no Chrome	Os 3PCs serão totalmente removidos do Chrome no futuro?	Estamos propondo uma abordagem atualizada que aprimora a escolha do usuário. Como definido aqui, em vez de descontinuar os cookies de terceiros, vamos lançar uma nova experiência no Chrome que permite que as pessoas façam uma escolha informada que se aplica a toda a navegação na Web e que pode ser ajustada a qualquer momento. Estamos discutindo essa nova abordagem com as autoridades reguladoras e vamos interagir com o setor antes de lançar a mudança.
Testes do Chrome	Solicitação de disponibilidade contínua dos rótulos de testes facilitados do Chrome.	A equipe do Sandbox de privacidade entende que as empresas querem continuar usando os rótulos de descontinuação de cookies. O processo para estender a disponibilidade dos rótulos é semelhante ao de estender um teste de origem. Como parte desse processo, o experimento só pode ser estendido para três marcos do Chrome por vez. Por exemplo, o experimento Intent to Extend (I2EE) mais recente do Chrome para rótulos de descontinuação de cookies foi estendido para o Chrome M130-M132. Isso permite o suporte aos rótulos até a versão estável da M133 no início de fevereiro. Outras extensões vão passar pelo mesmo processo. Por isso, recomendamos acompanhar o grupo de e-mails blink-dev para receber atualizações.

Inscrição e certificação

Nenhum feedback recebido neste trimestre.

Mostrar conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Especificações	O modelo de classificador é compartilhado entre o Android (pelo nome do app) e o Chrome (pelo nome do host)?	Não, são modelos separados, porque têm taxonomias diferentes.
Granularidade da taxonomia de temas	Os tópicos são muito genéricos para serem úteis quando usados com informações próprias.	A taxonomia de tópicos busca equilibrar utilidade e privacidade. Embora tenhamos avaliado possíveis mecanismos para tornar os Tópicos mais específicos, decidimos não fazer isso devido a questões de segurança e privacidade, entre outras preocupações. As tecnologias de publicidade podem alcançar os melhores resultados combinando todas as ferramentas disponíveis, como aprendizado de máquina e indicadores seguros para a privacidade de APIs que protegem a privacidade, com dados contextuais, de criativos e próprios. Confira mais instruções neste link.
Uso do API	A API Topics tem baixa cobertura.	As razões típicas para a baixa cobertura incluem: - Controles do usuário/desistência - Controles do editor/desistência - Elegibilidade do site (os sites a seguir não foram aprovados para correspondência com os Tópicos: sites não seguros; WebView; Chrome no iOS e modo de navegação anônima) - Limitações do usuário (usuários do Chrome com menos de 18 anos ou que estão usando o modo de navegação anônima não podem ser observados e receber Tópicos) - Requisito de observação do vendedor (o autor da chamada precisa ter visto o usuário antes no site associado a um Tópico qualificado) - Recência da implementação (permitindo cerca de 4 semanas para que a observação do autor da chamada seja dimensionada)
Uso do API	Solicitação de informações sobre o uso da API Topics, já que a guia "Networking" parece mostrar que há uma chamada enviada e detectada, mas chrome://topics-internals/ não mostra o observador registrado.	Ao usar o mecanismo de cabeçalho HTTP para interagir com a API Topics, os temas são enviados no cabeçalho de solicitação Sec-Browsing-Topics, mas só são observados se o servidor responder com o cabeçalho de resposta Observe-Browsing-Topics: ?1. Confira mais detalhes aqui.
Envolvimento do Chromium	No caso de computadores, o Chrome compartilha com outros navegadores baseados no Chromium o mesmo contexto de observação e classificação? No caso de dispositivos móveis, o Chrome para Android compartilha com outros navegadores Android baseados no Chromium / Chromium no app o mesmo contexto de observação e classificação?	O Chrome não compartilha dados do Topics com outros navegadores no dispositivo.
Especificações	Como a API Topics decide se uma visualização de página por um usuário é considerada como "entrada do histórico de temas"?	Para se qualificar para o cálculo semanal de temas, uma visita à página precisa ter uma chamada "observe" (pode ser de qualquer autor da chamada). Sem uma chamada de observação, a visita não será considerada para o histórico de temas.
Segurança	Como a API Topics impede que um autor de chamada receba os temas observados por outros autores?	Confira uma explicação aqui.
Taxonomia	Como a taxonomia da estrutura em árvore na API Topics é usada na observação em cada época?	Ao calcular os cinco temas principais, o algoritmo considera apenas os temas originais fornecidos pelo classificador, e as classificações são determinadas por (i) a frequência de visitas à página e (ii) uma pontuação de priorização (consulte a especificação). Ao calcular os usuários que observaram cada um dos cinco principais temas, o cálculo inclui os usuários que observaram o tema principal ou qualquer um dos temas derivados.
Especificações	Solicitação de mais informações sobre o ruído aleatório de 5% na resposta.	Sempre há cinco principais temas para cada época. Se o histórico de navegação não fornecer cinco tópicos, eles serão escolhidos aleatoriamente até que o número seja atingido. Chamamos esses tópicos de "agrupados". Os autores de chamadas não vão receber um desses temas preenchidos aleatoriamente, a menos que tenham observado (chamado a API) o usuário em um site com o tema nas últimas semanas. Quando a API é chamada, um hash por usuário, por site e por período é calculado. Se esse hash for menor do que a probabilidade de retornar um tema com ruído, o tema aleatório por usuário, por site e por época será selecionado para retornar. No entanto, o tema com ruído só é retornado (ou seja, não é filtrado) se o autor da chamada tiver observado o tema correspondente sem ruído para esse usuário/site/época (consulte o explicador). Essa filtragem garante que os tópicos com ruído sejam retornados 5% do tempo para o autor da chamada, independentemente da capacidade de observação.
Especificações	Como funcionam os temas duplicados entre semanas? A API está escolhendo de forma independente entre as semanas e depois mesclando?	Os temas de cada semana (época) são calculados de forma independente. O tema específico escolhido para ser retornado de cada época depende do site em que o autor da chamada está. Não consideramos que o tema possa ser repetido em épocas para um determinado autor da chamada. Portanto, é recomendável selecionar um tema diferente. No entanto, agradecemos o feedback sobre esse problema aqui.

API Protected Audience

Tema do feedback	Resumo	Resposta do Chrome
Teste A/B	A solução de armazenamento compartilhado descrita aqui aumenta a latência e tem uma alta taxa de falhas, ou seja, uma proporção significativa do tráfego acaba sem um ID de população. Um ID de baixa entropia (por exemplo, 3 bits) pode ser suficiente para testes A/B eficazes sem impacto significativo na privacidade.	Acreditamos que a solução de armazenamento compartilhado ainda é uma abordagem viável, mas estamos considerando essa solicitação e agradecemos mais feedback do ecossistema se esse recurso for uma prioridade alta.
Relatórios	Solicitação de bits adicionais em `reportWin()`, principalmente porque o entendimento é de que os novos relatórios de cliques e exibição na API PA vão usar de 6 a 8 bits, reduzindo efetivamente os bits restantes disponíveis para outros relatórios da API PA.	Não vamos mais aumentar os bits de modelingSignals além dos 12 bits atuais devido a questões de privacidade. Convidamos o ecossistema a enviar feedback sobre nossa proposta de treinamento de modelos particulares, que tem como objetivo atender às necessidades de treinamento de ML em um ambiente seguro sem um limite de bits imposto pelo Sandbox de privacidade.
Grupos de interesse	Solicitar ciclos de vida de 90 dias para grupos de interesse (GIs), porque 30 dias não é tempo suficiente.	Como mencionamos na postagem do blog, planejamos estender a vida útil do IG para 90 dias. Criamos um explicativo aqui. No momento, estamos trabalhando na implementação e vamos compartilhar o cronograma de lançamento quando ele estiver disponível.
Grupos de interesse	Solicitando atualizações dinâmicas para a delegação do Instagram.	Sabemos que várias partes interessadas fizeram esse pedido e estamos pesquisando uma solução. Vamos compartilhar atualizações no GitHub à medida que o projeto for desenvolvido e receberemos mais feedback do ecossistema.
No dispositivo	Demonstrar mais valor para o ecossistema para continuar investindo em soluções de API de PA no dispositivo.	A equipe do Sandbox de privacidade continua desenvolvendo APIs baseadas em tecnologia que preserva a privacidade (PET, na sigla em inglês), incluindo a API PA, para oferecer aos desenvolvedores mais opções que preservam a privacidade no navegador. Essas tecnologias estão disponíveis em grande escala em todos os navegadores Chrome (não apenas 1%, como alguns desenvolvedores entenderam). Os usuários podem ativar ou não os 3PCs, e os desenvolvedores podem incorporar soluções baseadas em PET nos produtos, assim como muitas empresas estão adotando outras soluções baseadas em PET fora do navegador. Muitos desenvolvedores já se beneficiam ao investir em soluções de API PA no dispositivo, ampliando o indicador de público-alvo próprio determinístico para melhorar o alcance em vários sites. Entendemos que alguns desenvolvedores só vão escolher usar as APIs do Sandbox de privacidade ou outras soluções baseadas em PET se mais 3PCs forem desativados. Esses desenvolvedores estão esperando informações que permitam especular quantos navegadores vão manter os 3PCs. Sabemos que esses desenvolvedores vão esperar até encontrar as informações que procuram para tomar decisões sobre o produto.
Grupos de interesse	Permitir que as SSPs participem da criação de IGs e das funções associadas a elas. As SSPs consideram isso uma parte importante do valor agregado e gostariam de ajudar os editores a vender IGs por meio das SSPs.	Recebemos o pedido de suporte a delegações mais avançadas de IG de várias partes interessadas e percebemos o valor agregado das SSPs que contribuem para esse processo. Estamos pesquisando para encontrar a melhor solução que permita que diferentes partes participem do processo de extensão do público-alvo. Vamos compartilhar atualizações no GitHub conforme o desenvolvimento avança e agradecemos o feedback do ecossistema.
Relatórios	Discrepâncias no número de relatórios de "lances diferentes de zero" entre a API forDebuggingOnly e a API Private Aggregation.	Esperamos uma discrepância por dois motivos: Primeiro, o modo de depuração da API Private Aggregation só está disponível quando há 3PCs permitidos no dispositivo, enquanto a API forDebuggingOnly está sempre disponível sem amostragem. Esse último comportamento vai mudar conforme detalhado aqui. Em segundo lugar, a API Private Aggregation tem limites de contribuição, enquanto a forDebuggingOnly não tem. No entanto, esse feedback indica que pode haver algo mais causando uma discrepância inesperada, e estamos trabalhando com uma parte interessada externa para resolver esse problema.
Cliques	Como mencionado na proposta atualizada para o indicador de clickabilidade, as visualizações e os cliques seriam registrados retornando um novo cabeçalho de resposta HTTP para solicitações iniciadas pelo atributo "attributionsrc" que são qualificados. Esse cabeçalho de resposta incluiria uma lista de origens que podem ser usadas para indicar quais outras partes podem incluir essas visualizações e cliques nas contagens agregadas. Isso significa que a adtech pode definir as origens de forma arbitrária?	O explicativo sobre a taxa de cliques especifica que uma adtech que contribui com um evento de visualização ou clique para as contagens de visualização e clique agregadas (uma "origem de fornecimento") pode incluir um parâmetro opcional com o cabeçalho de resposta que permite especificar "uma ou mais origens de proprietário do IG para as quais esse evento pode ser incluído nas contagens de visualização e clique computadas que serão fornecidas às invocações de `generateBid()` nos leilões da API Protected Audience ("origens qualificadas"). No entanto, essas visualizações e cliques não são incluídas automaticamente nas contagens de visualizações e cliques. Em vez disso, cada adtech precisa especificar, nas IGs, o conjunto de "origens de fornecimento" de que os eventos de visualização e clique precisam ser incluídos, e apenas os dados dessas origens de fornecimento contribuem para as contagens de visualização e clique apresentadas às chamadas `generateBid()` da adtech. Esse mecanismo exige um acordo de ambas as partes e impede que players maliciosos influenciem as contagens de visualizações e cliques de outras adtechs. Isso também significa que uma adtech "fornecedora" que define "origens qualificadas" de forma arbitrária não vai ter impacto nas visualizações e contagens de cliques dessas origens qualificadas, a menos que elas incluam essa origem de fornecimento de forma explícita e intencional no IG.
Treinamento de modelo particular	Há casos em que o DP-SGD (privacidade diferencial - gradiente estocástico diferencial) torna o processo de treinamento consideravelmente mais lento, porque ele destrói a sparsidade dos gradientes calculados durante a retropropagação. Há alguma técnica que está sendo considerada para lidar com isso ou alguma ideia sobre essa preocupação?	Sabemos de algumas técnicas para preservar a sparsidade no DP-SGD (por exemplo, esta) e estamos analisando a compatibilidade com esses tipos de técnicas na infraestrutura de treinamento de modelos particulares. Vamos compartilhar atualizações à medida que o processo avança e agradecemos seu feedback aqui.
Segmentação negativa	Pedido de atualizações sobre o lançamento da funcionalidade de filtragem de comentários negativos do Instagram descrita aqui.	Conforme definido em nossa resposta aqui, planejamos oferecer suporte a IGs negativas em lances da API PA. Vamos compartilhar um cronograma de lançamento quando ele estiver disponível. Confira aqui outros feedbacks.
Lances	É possível combinar vários IGs ao dar lances?	Isso não é possível no momento com a API PA. A API PA é baseada no design que o IG relaciona às informações que um site conhece sobre o usuário, o que tem sido fundamental nas discussões com o ecossistema em geral. Essa abordagem permite que as adtechs criem várias soluções que ajudam os anunciantes a expandir os públicos-alvo próprios na Web. Sabemos que a proposta da API Ads Selection da Microsoft propõe um design diferente, em que os públicos-alvo são baseados em informações de vários sites. Vamos continuar monitorando a abordagem deles, mas gostaríamos de ver mais discussões do ecossistema, incluindo a comunidade de privacidade, antes de considerar mudanças semelhantes no Chrome.
Anúncios nativos	Preocupações sobre se a API PA pode ou não oferecer suporte adequado aos diversos formatos e requisitos de renderização de anúncios nativos e se a API PA permite a flexibilidade e otimização criativa necessária para uma publicidade nativa eficaz.	Estamos pesquisando ativamente para oferecer mais suporte aos anúncios nativos e agradecemos o feedback do ecossistema.
Relatórios	Pedido para melhorar a robustez dos scripts de relatórios que competem por recursos com scripts de lances e podem ser perdidos quando o frame do leilão em execução é navegado.	Esperamos postar uma resposta no GitHub em breve, mas não acreditamos que essas questões afetem significativamente os relatórios válidos na prática.
Substituição de macro	As substituições de macro transmitidas pela configuração do leilão não funcionam com algumas configurações de terceiros.	A causa raiz foi que nem todo o tráfego rotulado do Modo A/B tinha esse recurso ativado. Recentemente, decidimos ativar esse recurso (e outros na mesma situação) em todo o tráfego rotulado do modo A/B. A previsão é que essa mudança seja feita no primeiro trimestre de 2025. Envie seu feedback aqui.
Documentação	Solicitamos esclarecimentos, porque parece haver uma discrepância na documentação sobre a unidade de medida do valor de recência no objeto browserSignals em `generateBid()`.	Respondemos a isso com mais detalhes aqui e atualizamos nossa documentação. A resposta correta é que a unidade de medida é milissegundos.
Relatórios	Solicitação de relatórios de terceiros: embora as DSPs e SSPs recebam notificações de impressão do Chrome, os provedores técnicos de camada intermediária não recebem por padrão.	Estamos discutindo esse pedido de recurso aqui e agradecemos seu feedback.
Grupos de interesse	Pedido de orientação sobre como excluir interestGroupBuyers dinamicamente ao usar fluxos de leilão de IG paralelos.	Confira as orientações neste link.
Anúncios nativos	Os leilões independentes da API PA para um determinado carregamento de página impedem a filtragem de anúncios na mesma página.	Outros recursos de anúncios nativos, incluindo widgets de recomendação conhecidos como "nativos" e que têm vários anúncios em uma unidade, são uma área ativa de pesquisa. Sabemos que o design atual pode não oferecer suporte à filtragem de anúncios na mesma página, e outras proteções, como os frames de proteção, também podem impedir isso.
Anúncios nativos	Talvez seja necessário adaptar os recursos atuais da API PA, como a verificação de criativos, relatórios etc., que dependem de indicadores baseados em URL para processar objetos JSON usados em criativos de anúncios nativos.	O suporte a outros anúncios nativos é uma área ativa de pesquisa, e estamos avaliando a viabilidade de adaptar a API PA para ajudar na renderização de anúncios nativos.
Verificação de anúncios	A brand safety de terceiros na API PA é afetada devido à latência e às limitações de armazenamento em cache de perBuyerSignals, o que é problemático para conteúdo dinâmico.	Sabemos que as SSPs e as DSPs precisam determinar um TTL ideal para o armazenamento em cache que equilibre as metas de modelagem de tráfego e os TTLs máximos de brand safety para garantir que os dados armazenados em cache permaneçam relevantes para a brand safety. Estamos investigando o problema e vamos compartilhar atualizações conforme ele se desenvolve.
Verificação de anúncios	A substituição da macro FullpageURL por SSPs é necessária para realizar a medição de brand safety pós-lance.	deprecatedReplaceInURN é a sugestão atual para que os SSPs forneçam esse indicador.
Verificação de anúncios	A falta de padronização nos formatos de macro usados pelas SSPs para a verificação pós-lance pode causar inconsistências e erros no processamento e na análise de dados.	As SSPs e os verificadores de anúncios precisam colaborar diretamente para definir diretrizes e especificações claras sobre o uso de macros e impulsionar a padronização dos formatos de macros nas SSPs, garantindo a consistência e evitando erros no processamento e na análise de dados. Essa é uma atividade para a qual organizações de padrões de anúncios, como o IAB Tech Lab, são adequadas.
Verificação de anúncios	Os anunciantes e verificadores de anúncios precisam de um mecanismo para vincular verificações pré-lance e pós-lance para o mesmo contexto do editor para depuração e solução de problemas.	Uma opção para a verificação pós-lance é usar indicadores com base em leilões e campanhas incorporados aos relatórios de eventos. Isso pode ativar mesclagens com registros de decisão pré-lance. Estamos analisando possíveis padrões para fazer isso e vamos compartilhar atualizações conforme o desenvolvimento.
Verificação de anúncios	Solicitação para conhecer as soluções de servidor de chave-valor confiável (TKV, na sigla em inglês) (de propriedade do DSP e do Ad Verifier) para pré-lances e para lidar com limitações de frames restritos para pós-lances.	Estamos avaliando esse pedido e agradecemos o feedback adicional do ecossistema aqui para encontrar uma solução que ofereça suporte à brand safety pré-lance e facilite os requisitos de coordenação entre as partes.
Anúncios nativos	Solicitação de auditoria de renderização pós-lance de venda para anúncios nativos.	O suporte a anúncios nativos é uma área de pesquisa ativa, e estamos considerando adaptar recursos como esse para ajudar na renderização de anúncios nativos.

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

Tema do feedback	Resumo	Resposta do Chrome
Latência	Não houve mitigações adequadas para a latência. Embora os serviços de B&A possam atenuar esse problema a longo prazo, o Google não se comprometeu com a disponibilidade generalizada antes das mudanças nos 3PCs no Chrome.	Fizemos várias melhorias na latência no dispositivo nos últimos trimestres. Também estamos criando e escalonando os serviços de B&A conforme necessário. Recentemente, atualizamos nosso guia de práticas recomendadas sobre latência, que inclui mais informações sobre como aproveitar esses recursos. Também estamos desenvolvendo novas melhorias de latência, algumas delas podem ser conferidas aqui.
(Também informado nos trimestres anteriores) Segurança do leilão	Pedido de esclarecimentos sobre abordagens para evitar/mitigar tentativas de adulteração do leilão no dispositivo (por exemplo, incluindo se o Google considera isso um risco significativo).	Nossa resposta não mudou em relação aos trimestres anteriores: "Os mecanismos de relatórios dos anúncios da API PA retêm as informações usadas para distinguir o tráfego humano 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.
Soluções no local	Preocupações sobre como os maiores fornecedores podem não adotar o Sandbox de privacidade ou o B&A devido à falta de suporte para a nuvem privada e ao longo e opaco roteiro para oferecer suporte a ele.	Estamos comprometidos em expandir as infraestruturas em que os serviços do Sandbox de privacidade são executados. Recentemente, anunciamos o suporte ao Azure Cloud e continuamos a investigar possíveis soluções para oferecer proteções de privacidade e segurança semelhantes para nuvens privadas. Desde nossa comunicação em outubro, fizemos progressos ao continuar pesquisando possíveis abordagens para proteger a privacidade dos usuários do Chrome em um ambiente de execução confiável (TEE) local. Agora, estamos em um ponto da pesquisa em que queremos validar diferentes abordagens com as partes interessadas do ecossistema e planejamos começar a coletar informações no primeiro trimestre. O feedback e a colaboração do ecossistema ajudam a refinar as possíveis soluções.
Teste	É possível criar TEEs para testar soluções de relatórios da API PA (Relatórios em tempo real e Agregação particular)?	Para testes de serviço de agregação, as adtechs podem usar dados de teste e ferramentas de teste local para gerar relatórios de resumo para testes funcionais. Consulte o Codelab de testes locais aqui. Para testar a agregação no TEE, as adtechs precisam concluir o processo de inscrição, conforme mencionado nos pré-requisitos do codelab acima. Envie seu feedback sobre essa solicitação aqui.
Integração de K/V da transação	Solicitar a capacidade de extrair informações de transações do KV para casos de uso comercial.	Estamos avaliando essa solicitação de recurso e vamos enviar uma atualização no GitHub.
de vitória impossível Medida de transação	Solicitar um indicador ou a capacidade de entender quando uma SSP não venceu e por quê.	Estamos avaliando essa solicitação e vamos enviar uma atualização no GitHub.
Solicitação de recurso	Solicitação para que o Sandbox de privacidade forneça uma estrutura de dicionário para ajudar a corresponder um grupo de anúncios ao respectivo conjunto de IDs de transação.	Estamos avaliando esse pedido, além de outras maneiras de reduzir o tamanho do IG em relação ao armazenamento de IDs de transação. Vamos publicar uma atualização no GitHub.
Desempenho	Soluções para medir possíveis oportunidades perdidas no leilão de anúncios, possivelmente devido ao tamanho do script de lances.	Estamos avaliando esse pedido e gostaríamos de receber mais feedback aqui.
Especificações	Atualmente, a B&A só lê o campo prevWins, e não o campo mais recente prevWinMs que substituiu prevWins na especificação.	É correto que a B&A não transmita a duração em milissegundos em prevWins para `generatebid()`. O Chrome envia a duração em segundos para garantir menos sobrecarga no payload. A correção aqui é para que a B&A faça a conversão de segundos para milissegundos. A B&A forneceria prevWins e prevWinsMs em browserSignals para tornar isso compatível com os leilões no dispositivo. Observação: mesmo para leilões no dispositivo para a Web, prevWins e prevWinsMs correspondem ao mesmo valor e prevWinsMs = prevWins * 1000. Estamos priorizando uma correção.
Documentação	A documentação não é clara sobre como testar o front-end do vendedor (SFE). Seria útil ter mais orientações de teste logo após a conclusão da implantação, bem como como usar o Bazel para builds.	Este codelab foi publicado como um guia para facilitar o teste de SFEs para o ecossistema mais amplo.
Implantação	Há planos de fornecer binários pré-criados para B&A?	Estamos considerando fornecer binários pré-criados para B&A, mas não temos cronogramas concretos para isso. Até lá, as adtechs podem criar os binários por conta própria e validar usando os hashes fornecidos.
Implantação	Todos os tipos de orquestração (servidor, cliente, misto) precisam de suporte ou há um que deve ser priorizado em relação aos outros?	Não temos recomendações específicas sobre quais modos a adtech implementa. A escolha depende de vários fatores, mas, no fim, se resume ao que é melhor para seus clientes.
Teste	Buscando esclarecimentos sobre testes com falha durante o build de B&A.	Isso pode ser resultado de um teste instável. Recomendamos que a adtech use a flag `--no-tests` para todos os comandos de build `build_and_test_all_in_docker` para pular a execução dos testes.
Registros	Procurando esclarecimentos sobre por que os registros no Log Explorer no GCP são marcados para a instância de VM que executa o SFE quando estão no modo de teste, mas no modo de produção os registros não são marcados para a instância de VM.	É difícil generalizar, porque depende do que exatamente foi observado, mas, em geral: - os registros de non_prod provavelmente são os registros stderr redirecionados pelo provedor de nuvem (neste caso, o GCP) e o GCP adicionou a tag. - Os registros produzidos pela VM geralmente são marcados com a instância da VM, enquanto os registros produzidos pelo binário não são marcados pelo GCP. - os registros do produto são exportados pelo Open Telemetry no TEE, que têm tags diferentes. Confira alguns detalhes do que está disponível em non_prod e prod.
B&A	Erro 403 em segredos ausentes quando o registro do OTEL está desativado.	O problema foi corrigido na atualização 4.1, e a documentação foi editada de acordo.
B&A	O arquivo outputs.tf ausente para a configuração do Terraform do GCP leva a um erro.	Isso já foi corrigido
Teste	Erro ao buscar a chave privada no modo de teste.	Nesses casos, verifique se os servidores estão em execução com TEST_MODE=true. Confira a explicação aqui.
Roteiro	Há planos para que a função getInterestGroupAdAuctionData aceite mais de uma origem do vendedor e retorne um mapa da origem do vendedor para o texto criptografado do payload B&A?	Sim, a adição de suporte para permitir que navigator.getInterestGroupAdAuctionData() aceite vários vendedores está planejada.
Especificações do KV	O URL KV (trustedScoringSignalsURL) pode ser entregue como uma promessa?	Confira a explicação neste link.
B&A	Solicitação de criação de um novo cabeçalho de plataforma para indicar ao lado do vendedor de B&A quais recursos o cliente (navegador) exige para que um leilão privado ocorra.	Estamos discutindo esse pedido de recurso aqui e agradecemos seu feedback.
Ajuste da programação	Proposta para reduzir os custos incrementais da hospedagem de servidores de B&A, principalmente para DSPs.	Estamos discutindo esta proposta aqui e agradecemos seu feedback.
Bring-Your- Own-Binary	Considere atualizar a explicação para abordar explicitamente que todos os binários têm suporte.	A página foi atualizada. Saiba mais.
Chamadas KV	O `generateBid()` aguarda o término de todas as chamadas de armazenamento de chave-valor (KV) ou é executado de forma independente? Como o agrupamento de KVs afeta o tempo?	Confira a explicação neste link.
Desempenho	Solicitação de documentação adicional sobre o reuso de scripts de lances e a recomendação de definir cabeçalhos de controle de cache nos scripts.	A documentação foi adicionada aqui.
Desempenho	Solicitação para considerar e analisar a capacidade de carregar recursos (por exemplo, scripts de lances) de forma assíncrona para reduzir a latência do leilão no dispositivo.	Estamos discutindo esse pedido de recurso aqui e agradecemos seu feedback.
Geração de registros de consentimento	Foi necessário esclarecer o erro encontrado ao tentar usar o registro de consentimento definindo o CONSENTED_DEBUG_TOKEN.	Nesses casos, verifique se CONSENTED_DEBUG_TOKEN está presente no gerenciador de segredos, ENABLE_OTEL_BASED_LOGGING definido como true e TELEMETRY_CONFIG definido como mode: PROD. Consulte o explicativo aqui, que se refere à fonte aqui.
Registros	Os eventos forDebuggingOnly estão disponíveis na B&A?	A flag "forDebuggingOnly" para perguntas e respostas está disponível para leilões de um único vendedor desde abril de 2024. Nosso plano é ativar esse recurso para leilões de vários vendedores em breve.
Registros de worklet	Solicitação para tornar o registro de worklets compatível com o ChromeDriver.	Estamos avaliando esse pedido e gostaríamos de receber mais feedback aqui.

Como medir anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Relatórios de depuração	Como os relatórios de depuração do ARA vão estar disponíveis para as adtechs após a abordagem atualizada para 3PCs no Chrome? As adtechs ainda podem ter acesso aos relatórios de depuração do ARA para usuários que mantêm 3PCs e têm as APIs do Sandbox de privacidade ativadas?	As adtechs vão ter acesso a soluções de depuração com e sem cookies para usuários com 3PCs e ARA ativados. Quando os cookies estão desativados, eles só têm acesso à solução de depuração agregada. Confira mais detalhes das soluções de depuração aqui e aqui.
Detecção de recursos	Solicitação de orientação sobre como fazer a detecção de recursos para ARA no lado do servidor.	No momento, o suporte a recursos de ARA pode ser identificado com base na versão do Chrome exibida na string do user agent. Agradecemos o feedback do ecossistema sobre esse assunto.
Solicitação de recurso	A solicitação de que a source_registration_time usada no Aggregate shared_info do ARA seja mais detalhada, por exemplo, arredondada para uma hora ou um minuto (em vez de um dia) e também configurável para considerar o fuso horário (atualmente, apenas UTC).	O arredondamento do campo source_registration_time para o dia mais próximo é um mecanismo de privacidade usado para impedir que uma adtech vincule um usuário específico a um registro de origem específico. No momento, o source_registration_time é baseado no UTC, e uma adtech pode ajustar os relatórios de anúncios para considerar isso. Envie seu feedback sobre o ecossistema neste link.
Especificações	Pedido para esclarecer a especificação de "trigger_data" e "priority", especialmente quando eles são usados com o valor da matriz.	Esses campos não aceitam valores de matriz. Os colchetes no explicador não representam uma matriz, mas indicam que o texto não é um valor de exemplo, mas um marcador de posição com uma descrição. Como o texto nos colchetes sugere: - trigger_data é um int-64 - priority é um int-64 assinado Nenhum dos campos aceita valores de matriz. Também vale a pena usar a ferramenta de validação de cabeçalho para ARA testar valores diferentes e encontrar erros se a documentação for confusa.
Suporte a anúncios de Accelerated Mobile Pages (AMP)	O ARA é compatível com anúncios AMP?	Nossa proposta de como podemos oferecer suporte ao AMP está aqui. Agradecemos seu feedback.
Especificações	Qual URL será considerado "site de origem" para anúncios incorporados de várias camadas para ARA?	O URL do site de nível superior.
(Também informado em trimestres anteriores) Solicitação de recurso	Solicitação para que o valor mínimo de event_report_window seja reduzido de 3.600 segundos (1 hora) para 1.800 segundos (30 minutos).	A determinação da janela mínima de relatórios exige um equilíbrio entre utilidade e privacidade. O período mínimo de 1 hora para relatórios de eventos é essencial para manter a privacidade e evitar certos tipos de ataques de reconstrução de histórico. Envie seu feedback sobre essa solicitação aqui.
Ruído	Você quer entender melhor como o ruído é implementado nos relatórios de evento do ARA para garantir a interpretação e utilização precisa dos dados.	Confira mais detalhes aqui e aqui.
Relatórios	A shared_info dos Relatórios agregados não contém mais source_registration_time por padrão.	Isso se deve a mudanças na API e está descrito em mais detalhes neste link.
Relatórios	O `filtering_id` não está na guia "Relatórios agregáveis" da interface chrome://attribution-internals/.	No momento, o `filtering_id` aparece nos detalhes da guia "Registros de acionadores" quando você clica em uma linha, o que permite confirmar a validade. Sabemos que é útil mostrar isso na guia "Relatórios agregáveis" e abordamos isso aqui.
Origem da atribuição	Pedido de esclarecimento sobre como a origem da atribuição funciona.	Confira uma explicação aqui.
Atribuição de app para Web	Pedido de orientação para implementações em que não se sabe se as fontes serão do SO ou da Web.	Confira as orientações aqui.

Serviço de agregação

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso	Solicitação de um tempo limite configurável para o AgS e/ou mais visibilidade do status do job para execuções de longo prazo.	Estamos considerando recursos para monitorar jobs de longa duração. Agradecemos o feedback do ecossistema sobre esse assunto.
Terraform	O Terraform tenta modificar a política de IAM da conta mesmo que service_account_token_creator_list não esteja definido.	Os desenvolvedores podem adicionar as permissões no arquivo local modules/adtech_setup/main.tf.
Solicitação de documentação	Solicitar documentação ou um codelab explicando como monitorar a integridade do serviço de agregação.	Uma descrição dos alarmes existentes que podem ser usados para monitorar o serviço e a integridade do job pode ser encontrada nos arquivos terraform relevantes do operador (alarms.tf e monitoring.tf) no repositório coordinator-services-and-shared-libraries. Vamos publicar mais documentação e orientações sobre como monitorar jobs de serviço de agregação.
Escalonamento	Como monitorar os problemas de escalonamento?	Publicamos uma versão atualizada desta orientação que documenta a escala mais alta do serviço de agregação. No momento, não há um indicador direto que indique que ocorreu uma falha porque a máquina não pode oferecer suporte à escala do job. Os indicadores indiretos incluem: 90% de consumo de memória antes de uma falha, um job que falha de forma recorrente. Agradecemos o feedback do ecossistema sobre a necessidade de um indicador.
Especificações	Qual é o tempo de execução típico dos lotes de relatórios do AgS?	Consulte as orientações aqui.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Solicitação de recurso	Solicitação para permitir que contribuições de valores flutuantes (incluindo negativos) sejam enviadas para contributeToHistogramOnEvent com uma sensibilidade de 2^16	Estamos discutindo esta proposta aqui e agradecemos seu feedback.

Limitar o rastreamento oculto

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

Nenhum feedback recebido neste trimestre.

Proteção de IP (anteriormente Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Geolocalização	Solicitação de arquivo de geolocalização para proteção de IP.	O arquivo que mapeia os IPs para locais aproximados para a Proteção de IP está disponível aqui. Esse arquivo é atualizado periodicamente.

Mitigação de rastreio por redirecionamento

Tema do feedback	Resumo	Resposta do Chrome
Lista de permissões	A posição atualizada não aborda mais a lista de permissões ou mecanismos semelhantes que seriam independentes do processo de tomada de decisão do Google.	O Google não planeja ter listas de permissões associadas a mitigações de rastreamento de rejeições (BTM, na sigla em inglês). As proteções são aplicadas de forma uniforme a todos os domínios.
Conformidade	A ICO precisa ter autoridade em conformidade com a privacidade.	O status de compliance não tem relação com a aplicação do BTM, e o Google não toma decisões sobre compliance na implementação do BTM.
Concorrência	Parece que o Google pode impedir a entrada de concorrentes de PET usando BTM (ou outras medidas) e depois decidir se permite ou não que eles voltem ao mercado. O processo de contestação atual pode impedir temporariamente que os concorrentes do PET usem BTM ou medidas semelhantes.	A proposta atual de BTM tem como objetivo o rastreamento de rejeição como técnica. Embora o Google busque evitar a quebra de determinados casos de uso que possam envolver técnicas semelhantes, não há planos para fornecer isenções individuais da BTM. Portanto, a questão de o Google exercer discrição sobre a presença de concorrentes não surge.

Reforçar os limites de privacidade entre sites

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

Tema do feedback	Resumo	Resposta do Chrome
(Também informado nos trimestres anteriores) Limite de domínio dos conjuntos de sites relacionados (RWS, na sigla em inglês)	O limite atual de cinco domínios associados não é alto o suficiente para atender aos casos de uso de medição entre sites.	Nossa resposta é semelhante aos trimestres anteriores: No momento, não esperamos aumentar o limite numérico. O limite foi estabelecido com base nas considerações de privacidade do usuário, no feedback de partes interessadas do ecossistema no W3C e na consideração de implementações semelhantes em outros navegadores. Para mais informações, consulte nossas postagens do blog (1, 2). Recomendamos examinar os casos de uso que exigem acesso a cookies entre sites além do limite numérico e considerar nossas orientações para casos de uso de identidade, incorporações autenticadas e casos de uso de publicidade. Envie seu feedback sobre esse problema aqui.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
Anúncios nativos	A renderização de anúncios nativos em frames delimitados apresenta desafios, já que a herança do estilo do editor é limitada devido às limitações na comunicação entre o iframe e a página do editor.	Mais suporte para anúncios nativos, incluindo o suporte após a aplicação de frames restritos, é uma área de pesquisa ativa. Envie seu feedback sobre esse problema aqui.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Uso do API	A API Shared Storage fica indisponível em alguns dispositivos quando outras APIs do Sandbox de privacidade estão funcionando.	Esse comportamento é esperado para um pequeno subconjunto de usuários (aproximadamente 1%) que fazem parte do experimento controlado de armazenamento compartilhado. Essa configuração experimental é usada para avaliar a performance e a adoção de APIs em diversos cenários.
Uso do API	As gravações no Shared Storage ocorrem na origem do editor ou do script de lances? O teste inicial não mostrou gravações quando a origem do editor era diferente da origem do script.	Esse problema foi resolvido e só permanece aberto em caso de um possível bug do DevTools. Confira mais detalhes neste link. O Armazenamento compartilhado grava na origem do comprador no contexto de lance da chamada `generateBid`. A gravação não está vinculada à origem do editor, mesmo que a página do editor esteja em um domínio diferente.
Uso do API	Quais são as proteções contra usuários de má-fé que podem ler os relatórios do Armazenamento compartilhado?	O armazenamento compartilhado é particionado chamando a origem para que um agente mal-intencionado ou uma adtech não possam ler os dados de armazenamento compartilhado de outra adtech. Os relatórios de agregação privada são enviados diretamente para a mesma origem por TLS para que não possam ser interceptados.

CHIPS

Tema do feedback	Resumo	Resposta do Chrome
Cookies particionados	Há um processamento inconsistente de cookies em diferentes portas localhost no Chrome e no Firefox, principalmente ao usar o atributo Particionado.	O Firefox trata o localhost com portas diferentes como chaves de partição distintas. Embora esse comportamento esteja alinhado aos princípios de segurança, ele se desvia da especificação e da abordagem do Chrome. Vamos discutir isso com outros navegadores em uma discussão sobre a especificação HTML e notificaremos o ecossistema se isso resultar em uma mudança na chave de partição do CHIPS. Envie seu feedback sobre esse problema aqui.
Cookies particionados	O rascunho do Clear-Site-Data permite a limpeza incorretamente além da partição do site de emissão, o que contradiz as discussões anteriores mencionadas aqui.	Esse é um bug no documento de especificação de padrões, que vamos corrigir em breve. O comportamento correto é especificado nesta seção do explicativo e está alinhado com o comportamento de outros navegadores no repositório do explicativo sobre particionamento de armazenamento. A implementação do Chrome já funciona corretamente.