Esta página foi traduzida pela API Cloud Translation.

Relatório de feedback – 3o trimestre de 2022

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

Como parte do compromisso com a CMA, o Google concordou em fornecer relatórios trimestrais sobre o processo de engajamento das partes interessadas para as propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo do feedback do Sandbox de privacidade são gerados agregando o 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 com a revisão dos tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), o feedback direto, o GitHub e as perguntas mais frequentes que surgiram pelas equipes internas do Google e formulários públicos.

Mais especificamente, as atas de reuniões de ó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 as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas que surgiam em relação a cada API.

As explicações das respostas do Chrome ao feedback foram desenvolvidas a partir de perguntas frequentes publicadas, respostas reais feitas a problemas levantados pelas partes interessadas e determinação de uma posição específica para os fins deste exercício de geração de relatórios públicos. Refletindo o foco atual de desenvolvimento e testes, as perguntas e o feedback foram recebidos principalmente em relação às APIs Topics, Fledge e Attribution Reporting.

Talvez os feedbacks recebidos após o fim do período do relatório atual ainda não tenham uma resposta do Chrome considerada.

Glossário de siglas

ÍCONES: 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 Internet Engineering
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 HTTP do user agent
W3C: World Wide Web Consortium
WIPB: Deficiência de IP intencional

Feedback geral, sem API/tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
(Também informado no 2o trimestre) Utilidade para diferentes tipos de partes interessadas	Preocupações de que as tecnologias do Sandbox de privacidade favorecem desenvolvedores maiores e de que sites de nicho (menores) contribuem mais do que sites genéricos (maiores).	Atualização do 3o trimestre: O Google se comprometeu com a CMA a criar e implementar as propostas do Sandbox de privacidade que não distorçam a concorrência, priorizando a própria empresa do Google, além de considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes, seja qual for o tamanho deles. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos. À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é a performance das novas tecnologias para diferentes tipos de partes interessadas. Feedback é fundamental nesse sentido, especialmente feedback específico e útil que pode nos ajudar a melhorar ainda mais os designs técnicos. Trabalhamos com a CMA para desenvolver nossa abordagem de testes quantitativos e apoiamos a publicação de uma nota sobre o design do experimento para oferecer mais informações aos participantes do mercado e uma oportunidade de comentar sobre as abordagens propostas.
(Também informado no 2o trimestre) Solicitações de documentação	Pedidos de mais recursos detalhando como gerenciar testes, análises e implementações	Atualização do 3o trimestre: Agradecemos que os desenvolvedores tenham considerado nosso material atual útil e estamos comprometidos em fornecer mais materiais nas próximas semanas e meses para que eles possam continuar a entender como as novas tecnologias podem funcionar para eles. Também realizamos sessões públicas de atendimento aos desenvolvedores para compartilhar práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produtos e engenharia para permitir discussões e perguntas ao vivo.
Compatibilidade entre navegadores	Outros fornecedores de navegadores que adotam as APIs do Sandbox de privacidade.	Outros fornecedores de navegadores, como Apple, Mozilla e Microsoft, participam ativamente dos fóruns públicos em que os princípios de privacidade e as abordagens baseadas em navegador são discutidos. Somos incentivados pelas discussões colaborativas em fóruns, como a recente reunião anual do TPAC do W3C e os fóruns atuais sobre o PATCG do W3C, onde vemos sinais de convergência.
Diferenças de plataforma	Peça o máximo possível para alinhar os conjuntos de recursos na Web e no Android para ajudar a reduzir os recursos necessários para a transição.	Estamos trabalhando para alinhar nossas abordagens no Chrome e no Android e evitar confusão/fragmentação no setor. Qualquer diferença na nossa abordagem será em grande parte devido às diferenças técnicas necessárias entre as plataformas da Web e de apps para dispositivos móveis que os desenvolvedores já vão considerar.
Recursos para testar as APIs do Sandbox de privacidade	Dificuldades em alocar o suficiente recursos para testar as APIs do Sandbox de privacidade, considerando os obstáculos econômicos atuais.	O Google está aprimorando continuamente a documentação e o suporte disponíveis aos testadores para facilitar a complexidade e ajudar na adoção das APIs. Esses esforços incluem: listas de e-mails específicas para APIs, horário de atendimento e atualizações contínuas em developers.chrome.com.
Indicador de desativação da API do sandbox	Solicitação para fornecer um indicador "O usuário desativou as APIs de sandbox", que pode ser usado por adtechs e sites.	Já vimos muitos casos históricos em que os sites reagem às escolhas do usuário, como "desativar cookies de terceiros", pressionando o usuário para mudar as configurações, às vezes incluindo o bloqueio de acesso a sites, a menos que isso seja feito. Um sinal de desativação também pode ser usado como um sinal adicional para técnicas de impressão digital. No momento, o Google não pretende fornecer um indicador de desativação.
(Também informado no 2o trimestre) Cronogramas mais claros	Programações de lançamentos mais claras e detalhadas	Atualização do 3o trimestre: Como explicado na seção "Mudanças em resposta ao feedback" abaixo, o Google atualizou o cronograma do Sandbox de privacidade em julho para dar ao mercado mais tempo para testes preliminares e feedback, além de mais tempo para testar quando as APIs do Sandbox de privacidade forem totalmente lançadas, antes que os cookies de terceiros sejam descontinuados.
(Também informado no 2o trimestre) Cronogramas de descontinuação dos cookies de terceiros	Solicitações para evitar mais atrasos na descontinuação de cookies de terceiros	Atualização do 3o trimestre: Em julho, o Chrome anunciou um cronograma atualizado para a descontinuação dos cookies de terceiros, refletindo nosso compromisso de agir com responsabilidade, considerando a complexidade das tecnologias e a importância delas para o ecossistema. O feedback dos reguladores e do setor foi levado em consideração antes dessa mudança, e continuamos trabalhando em estreita colaboração com todas as partes interessadas.
Cookies primários	Também estão sendo propostas restrições aos cookies primários? Em caso afirmativo, há preocupações sobre a estabilidade a longo prazo, o risco de outras alterações imprevisíveis no navegador e, portanto, desperdiçava esforços de engenharia agora.	Não consideramos restrições de cookies primários. O foco do Sandbox de privacidade é a suspensão do uso de cookies de terceiros.

Mostre conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
(Também informado no 2o trimestre) Utilidade para diferentes tipos de partes interessadas	Foram levantadas preocupações sobre a utilidade dos sites, dependendo do nível de tráfego ou da especialização do conteúdo.	Atualização do 3o trimestre: A utilidade da API será explorada por meio de testes. Conforme exigido pelo parágrafo 17.c.ii dos Compromissos, o Google compartilhará os resultados desses testes com a CMA. O Chrome espera que a taxonomia e outros parâmetros evoluam com base nos resultados dos testes. A evolução da taxonomia ou dos parâmetros não pode exigir mudanças incompatíveis com versões anteriores. Além disso, o Chrome espera que o feedback continue influenciando a evolução da API Topics após a descontinuação dos cookies de terceiros.
Privacidade/Política	Solicitação para remover o requisito de filtragem de tópicos por autor da chamada.	Com base no feedback de formadores de opinião de privacidade, defensores da privacidade, especialistas em segurança, grupos de direitos digitais e outros membros do ecossistema, o Chrome escolheu esse design para dar acesso às informações apenas a quem tinha tal acesso. Os motivos para isso incluíam, entre outros, limitar o vazamento incremental de dados entre lados, garantir transparência e explicabilidade, adotar uma abordagem simples de implementar e descrever e limitar o risco de técnicas de impressão digital. Os editores e terceiros que recebem a API Topics podem decidir por conta própria quais informações vão ser compartilhadas com terceiros no site. Se terceiros compartilharem essas informações, o Chrome os recomenda fortemente a serem transparentes com os usuários sobre esse compartilhamento e oferecer controles.
Sites classificados incorretamente	Os sites são classificados incorretamente de acordo com o tópico errado, o que pode resultar em uma segmentação de anúncios imprecisa.	Os sites são classificados com uma combinação de uma lista de substituições selecionada por humanos, contendo os sites mais acessados e um modelo de ML no dispositivo. O Chrome continua avaliando opções de sites para contribuir para a classificação da API Topics. Quaisquer melhorias de utilidade devem ser ponderadas em relação aos riscos de privacidade e de abuso. Alguns dos riscos incluem: Sites que usam a autoidentificação como um método para codificar significados diferentes (e potencialmente sensíveis) em tópicos. sites que façam declarações falsas sobre seus tópicos para obter ganhos financeiros; sites que atacam tópicos para prejudicar a utilidade desse conteúdo para outras pessoas (por exemplo, enviar spam aos tópicos do usuário com ruído sem sentido). O público pode inspecionar esses componentes, com ferramentas disponíveis em chrome://topics-internals ou neste colab. Durante os testes, esperamos que a classificação melhore com o tempo, e recebemos feedback de exemplos de sites que podem ser classificados incorretamente.
Requisitos de acesso	O requisito atual da API Topics para a entidade DOM como um script ou iframe a fim de ter acesso pode levar a comportamentos inadequados dos jogadores no ecossistema de anúncios.	Mesclamos uma alteração na explicação do GitHub. Pretendemos oferecer suporte a Topics em cabeçalhos HTTP.
A taxonomia dos temas não é granular o suficiente	As classificações dos temas atuais são muito amplas e não incluem assuntos mais detalhados, como temas regionais.	As melhorias na taxonomia são um esforço contínuo, e esperamos que ela evolua com os testes e as contribuições do ecossistema. Queremos receber feedback sobre qual taxonomia seria mais útil para o ecossistema. Ao avaliar se é necessário expandir o número de temas ou incluir outros mais detalhados, você precisa considerar: 1) possíveis implicações de privacidade (por exemplo, mais temas podem resultar em risco de impressão digital) e 2) a capacidade de recuperar temas observados anteriormente (por exemplo, com mais temas, pode haver menos chances de uma adtech ter visto o tema escolhido no passado). Continuando com a etapa 2, o Google busca maximizar a capacidade dos autores de chamadas de recuperar temas observados anteriormente, dentro do requisito de filtragem atual, com o objetivo de alcançar utilidade e privacidade.
Limite de temas	Três tópicos por site são poucas informações para os anunciantes veicularem anúncios.	O feedback do ecossistema, especialmente os resultados dos testes de origem, continuará a influenciar a evolução da API. É importante ressaltar que o Topics precisa complementar outros indicadores, como contextuais, para ajudar a encontrar um anúncio adequado para o visitante. Assim, é possível disponibilizar mais informações para o anunciante além dos tópicos.
(Também informado no 2o trimestre) Controles de usuário e segurança	Alguns tópicos podem ser proxies para grupos sensíveis, e os usuários precisam de mais controles para evitar resultados negativos.	Atualização do 3o trimestre: Os tópicos representam um avanço significativo para o controle e a transparência do usuário. Os usuários poderão desativar tópicos, revisar os tópicos que foram atribuídos a eles, remover tópicos e entender quais empresas estão interagindo com os tópicos em determinada página. Além disso, os usuários também podem limpar os tópicos excluindo o histórico de navegação, de onde os temas são derivados. No momento, esses controles estão implementados no navegador Chrome nos dispositivos. Aceitamos discussões contínuas sobre controles de usuário mais avançados, como os sugeridos pelos desenvolvedores. No entanto, precisamos garantir que as novas adições estejam bem calibradas para resolver as questões levantadas e não resultarão em mudanças interruptivas.
Impacto no SEO	Os editores que ajustarem os nomes do host do site para refletir melhor a API Topics podem afetar negativamente a SEO.	Aconselhamos os sites a não alterar os nomes do host somente para a API Topics. É verdade que um site pode influenciar os tópicos atribuídos dessa maneira. No entanto, os benefícios para os editores não são claros, e isso prejudicaria o valor da API Topics para todo o ecossistema se os sites tentassem manipular o modelo de classificação. As atribuições de temas também não são fixas. Esperamos que a taxonomia continue a evoluir com os testes e as entradas. Para esse teste, incentivamos o feedback, incluindo exemplos de sites que podem ser classificados incorretamente.
Fraudes e abusos	Permita que a parte compradora verifique se o tópico exibido é realmente gerado pelo navegador.	Agradecemos a sugestão de oferecer um mecanismo para que os compradores de adtechs verifiquem os temas aprovados pelos vendedores nos leilões de publicidade programática. Incentivamos o ecossistema a contribuir com a discussão ativa aqui. Embora estejamos atualmente focados em outras melhorias de maior prioridade, reconhecemos que isso pode ser uma adição futura importante ao design.
Fraudes e abusos	Permita a revisão pública de partes que são usuários legítimos dos dados da API Topics, usando o mesmo tipo de postagem e revisão públicas a que um conjunto próprio estaria sujeito.	Agradecemos a sugestão e concordamos que a responsabilidade pública é uma ferramenta importante para ajudar a alcançar as metas do Sandbox de privacidade. As chamadas da API Topics são inerentemente públicas, já que qualquer pessoa pode visitar um site e observar as chamadas de um domínio para a API JavaScript. Assim, indivíduos e organizações podem visualizar a atividade relevante e avaliar quais sites estão usando a API Topics e como. Acreditamos que essa abordagem é melhor do que fazer avaliações da parte de "legitimidade" de um site da funcionalidade da própria API Topics.
Impacto nos indicadores próprios	O indicador de temas pode ser muito valioso e, como resultado, desvaloriza outros indicadores próprios com base em interesses.	Acreditamos que a publicidade com base em interesses é um caso de uso importante para a Web, e a API Topics foi projetada para atender a esse caso de uso. Conforme descrito acima, outras partes interessadas do ecossistema expressaram preocupações de que a API Topics pode não ser útil o suficiente para agregar valor. Em todos os casos, as melhorias na taxonomia são um esforço contínuo, e esperamos que ela evolua com os testes e as contribuições do ecossistema.

FLEDGE

Tema do feedback	Resumo	Resposta do Chrome
Leilão do FLEDGE	Como as SSPs podem formatar os dados enviados ao Google Ads para dar lances em um leilão do FLEDGE.	As empresas que participam dos testes são incentivadas a publicar documentação sobre os planos de teste e trabalhar em conjunto quando apropriado. Trabalhamos com a CMA para desenvolver nossa abordagem de testes quantitativos e apoiamos a publicação de uma nota sobre o design do experimento para fornecer mais informações aos participantes do mercado que planejam se envolver em testes e uma oportunidade de comentar sobre as abordagens propostas. A equipe do Ad Manager publicou aqui a documentação para os vendedores que têm interesse em testar o FLEDGE com editores que usam o Ad Manager como servidor de anúncios. Veja mais detalhes técnicos aqui.
FLEDGE em frames Fenced aninhados	Os frames isolados permitem testes menos restritivos, ao mesmo tempo que restringem mais em um futuro indefinido. Essa linha do tempo desconhecida representa um desafio para o ecossistema.	As empresas podem testar o FLEDGE com Fenced Frames hoje mesmo. Para oferecer uma opção de integração mais fácil, as empresas podem primeiro implementar o FLEDGE. Depois de implementar o FLEDGE, eles podem testar o Fenced Frames com o design do FLEDGE.
Política de tratamento de dados	Qual é a política de processamento de dados para grupos de interesse / FLEDGE?	No design do FLEDGE, todos os dados armazenados em grupos de interesse ou sobre as pessoas em quais grupos de interesse permanecem no dispositivo. Nenhum desses dados é enviado a um servidor do Google. Algumas proteções de privacidade que o Chrome planeja para a API FLEDGE envolvem a interação com um servidor de k-anonimato gerenciado pelo Google. Essa interação está sendo desenvolvida com cuidado para evitar o compartilhamento de informações sobre os usuários e ser executada em um ambiente de execução confiável (TEE, na sigla em inglês) para garantir a paridade de informações no ecossistema de anúncios. \ O Google se comprometeu com a CMA a criar e implementar as propostas do Sandbox de privacidade que não distorçam a concorrência ao dar preferência à própria empresa do Google, além de considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos.
Políticas de idade	Como o Chrome garante que os públicos-alvo criados pelo FLEDGE estejam em conformidade com as restrições de idade?	Os editores e anunciantes são mais bem posicionados para avaliar se os públicos-alvo criados usando o FLEDGE obedecem à legislação aplicável. Para proteger ainda mais os usuários, as APIs do Sandbox de privacidade não ficarão ativas para usuários que fizerem login no Chrome se a idade associada à conta for menor que 18 anos, mesmo durante o período de teste. Para usuários não conectados, o Chrome não coleta indicadores de perfil que permitam ao navegador inferir a idade do usuário.
Serviços de chave-valor do FLEDGE	Mais clareza sobre o que o serviço de chave-valor do FLEDGE vai permitir, como o número de chaves e a frequência de atualização delas.	As empresas que usam o FLEDGE podem ter quantas chaves couberem na RAM. Para mais detalhes, consulte a explicação neste link. Buscamos oferecer uma maneira mais rápida de modificar dados e aceitar sugestões em caso de qualquer requisito.
Teste	É difícil testar o FLEDGE com o Google Ads	Consulte a documentação de integração do Google Ads para saber como participar e testar melhor no teste de origem.
API Bidding and Auction Services	Qual é a orientação do Google para a API Bidding and Auction Services? Ela vai ter prioridade acima ou abaixo do FLEDGE do navegador Chrome nos leilões de dispositivos?	Mantemos o compromisso atual do FLEDGE com os lances no dispositivo. A proposta dos serviços de lances e leilões é testar possíveis soluções em um subconjunto de casos de uso em que a capacidade computacional ou a velocidade da rede do dispositivo sejam limitadas.
Relatórios agregados	Solicitação para oferecer suporte a relatórios agregados com base em todos os indicadores disponíveis para generateBid.	Planejamos compartilhar mais informações publicamente em breve.
Anúncios contextuais	Veiculação de anúncios contextuais com o FLEDGE.	Consideramos essa opção e, pelos motivos explicados nesta discussão, não recomendamos o uso do FLEDGE para anúncios contextuais.
Como testar no mundo real	Orientações sobre como isolar o FLEDGE de cookies de terceiros para testes reais.	Estamos investigando maneiras de fornecer os grupos de teste. Trabalhamos com a CMA para desenvolver nossa abordagem de testes quantitativos e apoiamos a publicação de uma nota sobre o design do experimento para fornecer mais informações aos participantes do mercado e uma oportunidade de comentar sobre as abordagens propostas.
Como testar o FLEDGE e a API Attribution Reporting	Qual é a melhor maneira de implementar a API Attribution Reporting com o FLEDGE? Recomendamos separar o FLEDGE e a Attribution ou testar juntos?	Futuramente, vamos oferecer suporte ao teste do FLEDGE e da API Attribution Reporting como uma solução integrada, mas recomendamos que os desenvolvedores primeiro testem a API Attribution Reporting de forma independente e depois com o FLEDGE quando a integração terminar.
Visibilidade do preço do lance	Solicitação para ofuscar preços de lance.	É possível definir pontos de interrupção em `generateBid()` ou `scoreAd()` para acessar valores de lance no DevTools. A equipe do Chrome considerou o vetor de ataque estreito levantado neste feedback sobre o FLEDGE. No entanto, os modelos de segurança e privacidade do Chrome consideram que os usuários podem fazer o que quiserem com as informações nos próprios dispositivos. Por isso, não há uma maneira viável de ocultar os dados de lances.
Solicitações de documentação	Documentação e exemplos para testes em um ecossistema ativo.	Agradecemos que os desenvolvedores tenham considerado nosso material atual útil e estamos comprometidos em fornecer mais materiais nas próximas semanas e meses para que eles possam continuar a entender como as novas tecnologias podem funcionar para eles. Também realizamos horários de atendimento públicos de desenvolvedores externos para compartilhar práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produtos e engenharia, o que permite discussões e perguntas ao vivo.
API Private agregação	Quer mais informações sobre a API Private agregação?	Uma explicação pública está disponível com as informações mais recentes que podemos compartilhar no momento. Mais documentos serão fornecidos à medida que essa API for desenvolvida e os casos de uso definidos.
Latência de dados	A recuperação de dados do servidor de chave-valor do FLEDGE vai ser em tempo real?	É possível que uma pequena quantidade de inatividade em questão de minutos, em vez de horas, seja esperada até que os dados atualizados possam ser retornados pelo servidor para consultas, conforme explicado em um problema aberto do GitHub (link em inglês). Também queremos receber o feedback dos desenvolvedores.
Serviços de lances e leilões	Os preços dos lances vão ficar ocultos para o usuário se os serviços de lances e leilões (B&A) forem usados?	Na abordagem do lado do servidor de B&A, o preço do lance individual não fica visível para o usuário, já que a solicitação de lance é feita do serviço de leilão da SSP diretamente para o serviço de leilão do DSP e, portanto, não está mais disponível no navegador. No entanto, o preço do lance vencedor vai continuar visível para o navegador. Isso é discutido em mais detalhes acima em relação a solicitações para ofuscar preços de lance.
Serviços de lances e leilões	Como podemos equilibrar a carga de lances e serviços de leilão?	No momento, não temos nenhuma orientação sobre o balanceamento de carga, mas essa é uma preocupação importante do ponto de vista do desempenho e da privacidade. Daremos mais detalhes no futuro.
Limites do FLEDGE	Solicitação para aumentar o limite de duração de joinAd InterestGroup de 30 para 90 dias.	Achamos que o período de retenção de dados de 30 dias está alinhado com outras APIs de publicidade do Sandbox de privacidade, como o limite de 30 dias na API Attribution Reporting e a retrospectiva de três semanas na API Topics. Esse prazo aborda as necessidades de adtech e de privacidade dos usuários. No entanto, gostaríamos de receber mais feedback à medida que continuarmos a discutir o problema aqui.
Armazenamento compartilhado no FLEDGE	É possível usar a API de armazenamento compartilhado no FLEDGE?	Pretendemos oferecer suporte à API Shared Storage no FLEDGE no futuro e estamos trabalhando para disponibilizar isso em um teste de origem futuro.
Controle de frequência por cliques	É possível ter um limite de frequência por cliques (não vitórias) no FLEDGE?	O FLEDGE especifica que um frame fenced pode chamar navigator.leaveAd InterestGroup() (sem parâmetros) para sair do grupo de interesse que causou a exibição do anúncio. Essa chamada pode ser feita na primeira vez que um clique é recebido para evitar lances futuros, como uma forma de limite de frequência. No momento, essa solução não funcionaria para o limite após mais de um clique.
FLEDGE em Fenced Frames aninhados.	Não é possível informar os cliques pelos relatórios de anúncios de frame cercados se eles ocorrerem em um frame aninhado.	Publicamos uma proposta para corrigir o problema aqui.
Medição	Precisa de orientação sobre como coletar dados de latência em bidders em um leilão do FLEDGE.	Estamos trabalhando para publicar um documento sobre medição de performance em breve.
Relatórios	Como os relatórios do FLEDGE vão ser processados?	Os relatórios do FLEDGE sobre vitória, resultado do leilão e evento vão ficar disponíveis usando APIs do FLEDGE, como reportResult(). Na geração de relatórios com a conversão de anúncios, a integração com a API Attribution Reporting será independente da API Attribution Reporting, mas há discussões em andamento com o ecossistema sobre possíveis abordagens. A API Private agregação também pode ser usada para informar resultados de leilões em ambientes de execução isolados. Confira a explicação aqui.
Tamanho do grupo de interesse	As adtechs têm alguma forma de verificar o tamanho de um grupo de interesse (ou seja, o número de usuários no grupo)?	A associação ao grupo de interesse é armazenada pelo navegador, no dispositivo do usuário e não é compartilhada com o fornecedor do navegador ou com qualquer outra pessoa. No entanto, o proprietário de um grupo de interesse pode, teoricamente, acompanhar todas as chamadas para navigator.joininterestgroup(...). O acompanhamento dessa chamada não garante o tamanho exato de um IG (já que os usuários podem sair de um grupo a qualquer momento), mas fornece ao proprietário um limite superior e uma aproximação do tamanho.
Desempenho	O código de lances JS/WebAssembly é compilado em todos os leilões?	O código JS/WebAssembly dos lances é compilado uma vez em cada leilão.
Desempenho	Qual é o escopo de BiddingDurationMsec?	BiddingDurationMsec inclui o tempo do script de compilação. Isso não inclui os tempos de download, de compilação do Wasm e de rede, o tempo de busca do servidor de chave-valor ou qualquer outro elemento antes da compilação do JS.
Personalização	É possível atualizar o adComponent para que ele seja personalizado para o usuário?	O adComponent pode ser atualizado quando os grupos de interesse são atualizados pelo autor da chamada ao chamar join InterestGroup ou quando o Chrome faz uma chamada para dailyUpdateURL. Isso permite que o autor da chamada atualize o adComponent com base no conhecimento do usuário do site atual ou em informações de k-anônimos, respectivamente.Você pode encontrar a proposta original do k-anônima no nível do produto aqui, que inclui uma análise do RTB House sobre o impacto nas principais métricas para o caso de uso de recomendação.
Grupo de interesse	O proprietário de um grupo de interesse pode remover determinados usuários condicionalmente?	A associação ao grupo de interesse é armazenada somente no navegador do usuário e só pode ser removida pelo usuário (por exemplo, limpando os dados do site). No entanto, o proprietário de um grupo de interesse poderá chamar navigator.leaveAd InterestGroup() (com alguma lógica condicional) se o usuário retornar a uma página que está sob o controle do proprietário do grupo.
Desempenho	Como medir o desempenho de generateBid?	O tempo de compilação e execução pode ser medido com BiddingDurationMsec. O tempo de download pode ser medido com chrome://net-export. Nas versões recentes do Chrome, o tempo de compilação e execução aparece na guia "Performance" do DevTools.
Frequência de atualizações do grupo de interesse	Qual será a frequência de atualização do grupo de interesse nos navegadores?	Para grupos de interesse que não foram atualizados nas últimas 24 horas, o Chrome tenta atualizá-los quando Navigator.updateAd InterestGroups() é chamado ou quando eles têm a chance de participar de um leilão. Para mais detalhes, consulte a explicação aqui.
Provedores de serviços de agregação	Quando outros provedores de nuvem terão suporte no serviço de agregação?	No momento, não temos atualizações sobre horários específicos, mas compartilharemos mais assim que tivermos. No momento, apenas a AWS atende aos requisitos de segurança do serviço de agregação.
Linha do tempo de testes do FLEDGE	Por quanto tempo o FLEDGE vai ficar testando em BYOS? Haverá tempo suficiente para mudar do modelo BYOS para o modelo baseado em TEE?	Para garantir que o ecossistema tenha tempo suficiente para testar, não esperamos exigir o uso dos TEEs algum tempo após a descontinuação dos cookies de terceiros. Vamos enviar um aviso significativo para os desenvolvedores começarem os testes e a adoção antes que essa transição ocorra. Não temos outras atualizações no momento, mas compartilharemos mais quando tivermos. Veja as informações mais recentes aqui.
Limite de tamanho dos dados	Qual é o limite de tamanho dos dados para o Wasm na função de lances?	Há um requisito para que as atualizações do grupo de interesse não resultem em um grupo de interesse maior que 50 KB, conforme discutido aqui. No entanto, o limite de tamanho de dados para o Wasm ainda não foi definido. Por isso, gostaríamos de receber seu feedback sobre esse assunto.
Indicadores de leilão	Haverá uma estrutura de dados padronizada para os insights do leilão?	Isso ainda não foi definido, mas estamos abertos a feedback.
Consulta a servidores de adtech	É possível consultar dados de um servidor de adtech em tempo real usando um servidor K/V?	Não, o servidor K/V é executado em um modelo de confiança que aplica "Sem rede, acesso ao disco, timers ou geração de registros" para evitar o vazamento de dados do usuário. Consulte a explicação sobre o modelo de confiança neste link para mais detalhes.
Frequência de atualização de adComponents	No momento, não é possível atualizar o campo adComponents (atualmente apenas na configuração IG) pelo histórico de navegação do usuário.	O Sandbox de privacidade tem como objetivo oferecer suporte às necessidades do ecossistema da Web sem o rastreamento entre sites, o que significa impedir o acesso ao histórico de navegação. Recomendamos o uso de alternativas como a API Topics.
Resultados do leilão	As adtechs têm alguma forma de saber as taxas de vencedores no leilão?	O resultado do leilão é informado chamando as funções reportResult() e reportWin() no código do leilão fornecido pelo vendedor e pelo comprador vencedor, respectivamente, para que cada um tenha a oportunidade de gerar registros e gerar relatórios sobre o resultado do leilão.
(Também informado no 2o trimestre) Suporte à segmentação negativa de grupos de interesse	Uma API compatível com a segmentação negativa de grupos de interesse: exibir anúncios somente se um usuário não pertencer a um grupo de interesse.	Atualização do 3o trimestre: Compartilhamos uma nova proposta e queremos receber feedback.

Medir os anúncios digitais

Attribution Reporting (e outras APIs)

Tema do feedback	Resumo	Resposta do Chrome
Requisitos do OT	As restrições de política de permissão foram removidas apenas durante / para o OT.	Consulte nossas mudanças anunciadas na política de permissões durante os testes. A preocupação das partes interessadas subjacente abordada por essa mudança é permitir que as DSPs testem a API em uma quantidade maior de iframes de origem cruzada. Originalmente, as DSPs precisavam se coordenar com os editores/SSPs para garantir que a política de permissão correta fosse definida e testar a API em iframes de origem cruzada. No entanto, com essa mudança, as DSPs poderão chamar a API por padrão, e as SSPs e os editores poderão desativá-la, se necessário, durante o teste de origem.
Ruído	Feedback de que o nível de ruído está muito alto e está afetando a utilidade do relatório.	Recebemos feedback sobre ruídos, que vamos usar para determinar como definir determinados parâmetros relacionados a ruídos. Também queremos publicar mais recursos, ferramentas e outros documentos para ajudar os testadores a fazer isso.
Conversões em vários domínios	Como acompanhar as conversões em vários domínios, como aqueles com dois ou mais destinos?	Estamos discutindo e buscando feedback sobre essa questão.
Requisitos de depuração	Solicitar permissão para que os desenvolvedores verifiquem o orçamento de privacidade restante ao implantar / testar o relatório de resumo?	Acompanhe essa solicitação de recurso aqui.
Políticas de uso da API	Feedback sugerindo políticas para quem pode usar uma determinada API com base em restrições de técnicas como impressão digital	Essa é uma ideia muito interessante, e ficaríamos felizes em interagir mais com outros provedores de navegadores e com o ecossistema da Web em geral.
Configuração de vencimento no relatório de conversão	Solicitação para oferecer suporte ao filtro / expiração do relatório por menos de 24 horas.	As expiração por hora são uma fonte de preocupação de privacidade, já que permitem que a adtech saiba exatamente em que hora um usuário visita o site do anunciante. Com a validade do dia, as adtechs podem filtrar as impressões inválidas sem determinar o horário em que o usuário visitou o site.
Expiração do token do OT	Solicitação para estender a validade dos tokens OT atuais para reduzir a sobrecarga operacional.	Reconhecemos que os tokens precisam ser renovados e estamos trabalhando para facilitar o processo para os desenvolvedores e fornecer avisos adicionais.
Suporte regional	No momento, o serviço de agregação não oferece suporte a todas as regiões.	Essa é uma limitação atual da versão Beta. Esperamos oferecer suporte a mais regiões durante o andamento do teste, mas ainda não temos um cronograma claro para isso.
Atraso na geração de relatórios no nível do evento	O atraso de 2 a 30 dias nos relatórios de eventos pode ser muito longo para certos casos de uso.	Compartilhamos uma proposta aqui para permitir que as adtechs controlem quando os relatórios de eventos vão ser enviados após o vencimento. O padrão é 30 dias, mas pode ser definido em menos tempo.
(Também informado no 2o trimestre) Atribuição multitoque	Permitir a atribuição multitoque, como entre dispositivos ou apps.	Atualização do 3o trimestre: Os métodos atuais de atribuição multitoque exigem um vínculo determinista das impressões (e, portanto, identidade) de um usuário em diferentes sites. Por isso, essa funcionalidade na forma atual não está alinhada aos objetivos do Sandbox de privacidade, que tem como objetivo oferecer suporte aos principais casos de uso de anúncios sem rastreamento entre sites.
Cronograma de integração do FLEDGE e da API Attribution Reporting	Qual é o cronograma para a integração do FLEDGE e da API Attribution Reporting?	No momento, não temos atualizações para compartilhar, mas vamos fornecer mais informações publicamente assim que nos comprometermos com um cronograma específico.
Vários tipos de acionadores	Solicitar mais flexibilidade no registro de acionadores.	Propomos um sistema de eliminação de duplicação para APIs agregadas que vai dar às adtechs mais flexibilidade no controle dos relatórios agregáveis e de evento.
Medição	Solicite o recebimento de dados de medição para verificar se o inventário está com uma boa performance.	Agradecemos seu feedback e estamos buscando mais esclarecimentos sobre os casos de uso dessa solicitação.
Expiração da conversão	Solicite suporte à expiração da conversão na tag do acionador em vez de usar apenas a tag de origem.	Agradecemos seu feedback e estamos buscando mais esclarecimentos sobre os casos de uso dessa solicitação.
Relatórios em lote	Solicitar medição adicional nos relatórios em lote.	Agradecemos seu feedback à medida que continuamos a considerar o impacto no serviço de agregação. Temos interesse em saber o que as adtechs estão achando dos relatórios de lotes e a frequência esperada, além de qualquer feedback sobre as mudanças na estratégia de lotes ao longo do ano.
Epsilon	Quando o valor do épsilon será determinado?	Estamos trabalhando ativamente com testadores do ecossistema para finalizar o valor do épsilon e como ele será implementado no GA. O valor ficará visível no público, junto com a discussão que levou à decisão do valor. Se você tiver algum feedback, poste neste problema do GH.

Limitar o rastreamento verso

Redução do user agent

Tema do feedback	Resumo	Resposta do Chrome
Dependências de implantação	Como lidar com as dependências de implantação do user agent estruturado (SUA, na sigla em inglês).	Lançamos a "Fase 4", conhecida como redução de versão secundária para 100% dos usuários do Chrome nas versões 101 e superiores. Confira a atualização aqui.
Teste	Pedido para estender o teste de origem da redução de user agent da Meta.	Estendemos o teste de origem e recebemos permissão para remover os limites de tráfego e acomodar sites maiores. Os limites de tráfego mais flexíveis se aplicam a qualquer site, grande ou pequeno.

Dicas de cliente do user agent

Tema do feedback

Resumo

Resposta do Chrome

(Também informado no 2o trimestre)

Questões relacionadas a antifraude / antiabuso

Certos recursos que podem ser perdidos com o UA-CH: rastreador de redirecionamento de cliques e cliques fraudulentos.

Atualização do 3o trimestre:

Recebemos feedback positivo de empresas relatando que não notaram efeitos adversos nos seus pipelines de combate à fraude (os resultados aqui e aqui).

Nossa equipe continua investigando esses possíveis problemas com as partes interessadas em combate a fraudes e medição.

Política de permissão

A Permission-Policy é armazenada em cache?

A API Permission-Policy não é armazenada em cache, como explicado neste problema do GitHub.

Gnatcatcher (em desenvolvimento)

Tema do feedback	Resumo	Resposta do Chrome
Casos de uso de geolocalização	O Gnatcatcher pode impedir que casos de uso legítimos de geolocalização funcionem no futuro, como personalização de conteúdo com base na geolocalização.	Estamos trabalhando com as partes interessadas para garantir que o Chrome continue oferecendo suporte a casos de uso legítimos de endereços IP.

Fortaleça os limites de privacidade entre sites

Conjuntos primários

Tema do feedback	Resumo	Resposta do Chrome
Política	Preocupação de que o QPS não é consistente com as disposições dos compromissos da CMA relacionadas à "Legislação de Proteção de Dados Aplicável", já que o GDPR não impõe um limite ao número de sites em um conjunto, mas prevê um limite de três.	O Google se comprometeu com a CMA a criar e implementar as propostas do Sandbox de privacidade sem distorcer a concorrência, priorizando o próprio negócio do Google, além de considerar o impacto na concorrência na publicidade digital, nos editores e nos anunciantes, bem como nos resultados de privacidade e na conformidade com os princípios de proteção de dados estabelecidos na Legislação de Proteção de Dados Aplicável. A preocupação expressa não divulga nenhuma incompatibilidade com o GDPR. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos. Mais detalhes estão incluídos na seção "Alterações em resposta a feedback" abaixo.
Documentação	Solicitação de mais exemplos e atualização das explicações.	Os exemplos nas explicações estão em revisão e serão esclarecidos ou removidos conforme necessário.
Compartilhamento de preferências	Proposta para fazer preferências nos mesmos conjuntos das partes.	Agradecemos o feedback e estamos discutindo a ideia neste link.
Aplicação	Processos de restrição transparentes apresentam risco de abuso por usuários de má-fé.	Agradecemos o feedback e participamos ativamente da conversa com as partes interessadas no GitHub (considerando os pontos levantados neste problema e procurando incorporar as sugestões levantadas na questão) e em outros fóruns para avaliar o risco e identificar possíveis mitigações.
Propriedade comum	Proposta de declaração legível por máquina para propriedade comum.	Agradecemos e incentivamos a contribuição sobre nossa proposta.
Propriedades de subdomínios	Subdomínios diferentes com controladores de dados, políticas de privacidade distintos ou operados por entidades diferentes devem fazer parte do mesmo conjunto primário?	Com base no feedback, planejamos remover o caso de uso de eTLD comum.
Mitigação de abusos	Peça mais detalhes sobre as medidas de mitigação de abusos.	O gerenciamento do processo está sendo analisado, e mais detalhes vão ser compartilhados nos próximos meses.
Possível vetor de ataque	Um conjunto associado enganoso para páginas facilmente encontradas pode ser usado para direcionar o tráfego para outras páginas que são erroneamente apresentadas como independentes.	Estamos coletando opiniões do público e investigando possíveis maneiras de resolver esse problema.
Definir validação	Validar o conjunto por meio de políticas comuns consentidas.	Vários membros da comunidade de padrões da Web e do ecossistema em geral apontaram que essa prática não é viável.
Limite de domínio	Solicitação para expandir o número de domínios associados.	Estamos debatendo ativamente o limite de domínio em QPS e gostaríamos de receber mais feedback da comunidade sobre o número de domínios associados necessários para os casos de uso.
Interação de serviço do subconjunto	Problema com o serviço e a interação de subconjuntos associada.	Agradecemos o feedback e tentaremos tornar isso mais explícito nas especificações futuras.
(Também informado no 2o trimestre) Mais privacidade	Muitos sites no mesmo conjunto podem gerar resultados semelhantes aos de cookies de terceiros.	Atualização do 3o trimestre: A proposta mais recente sugere um limite de três domínios para o subconjunto "associado", que não inclui ccTLDs e domínios de serviço. O Chrome está interagindo ativamente com o ecossistema para determinar se esse limite é adequado.
(Também informado no 2o trimestre) Requisito comum da Política de Privacidade	É inviável manter uma Política de Privacidade comum em todos os produtos e jurisdições que precisam fazer parte do mesmo conjunto.	Atualização do 3o trimestre: Uma Política de Privacidade comum não é mais um requisito para fazer parte do mesmo conjunto.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
Por que um novo elemento em vez de atributos em iframes?	Pergunta sobre a proposta com Frenced Frame em vez de propostas com iframe existentes.	Gostaríamos de receber seu feedback e estamos abertos a ideias de como mudar o estado atual da situação neste link.
Observador de intersecções em frames isolados	Perguntas sobre a visibilidade de informações dentro de um frame isolado.	Isso está em discussão ativa e no período de comentários neste documento e no GitHub. Os parceiros podem compartilhar casos de uso conosco para entender melhor como oferecer suporte.
Suporte para inventário de vídeo e nativo	O Fenced Frames é compatível com inventário de vídeo e nativo?	Em termos de recursos de reprodução de vídeo, os Fenced Frames não são diferentes dos iframes e, por isso, não são explicitamente mencionados em nenhuma documentação pública. Se algum problema com os anúncios em vídeo estiver acontecendo, envie seu feedback para que possamos investigar melhor.
Pacotes da Web	A veiculação / renderização de anúncios por pacotes da Web vai se tornar uma exigência no futuro com o Fenced Frame x FLEDGE?	O objetivo a longo prazo é oferecer suporte a Web Bundles para renderizar conteúdo do anúncio em um frame isolado. No entanto, a implementação atual do FLEDGE não tem suporte para isso e exige a renderização de um recurso HTML recuperado de renderUrl.
Dimensões do material	Solicitação de render_url para oferecer suporte a uma macro de altura e largura do espaço para que possamos responder com um criativo de tamanho adequado	Isso está sendo discutido aqui.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Integração com o FLEDGE	Como o armazenamento compartilhado e o FLEDGE serão integrados?	Embora isso não aconteça no momento, queremos explorar essa ideia para garantir a preservação das proteções de privacidade. Recomendamos que as partes interessadas enviem sugestões para possíveis casos de uso que essa proposta possa oferecer no repositório github do armazenamento compartilhado ou no repositório github do FLEDGE. .
Retenção de dados	Limpar o armazenamento compartilhado reduz a utilidade. As extensões do período de armazenamento ou a capacidade de excluir chaves-valor individuais foram consideradas alternativas?	Estamos sempre procurando equilibrar a privacidade do usuário e as compensações de utilidades. Gostaríamos de receber feedback sobre ajustes e incentivamos os parceiros a enviarem feedback e detalhes durante o teste do armazenamento compartilhado.
Indicador negativo	Sinal negativo do Mozilla sobre a proposta de armazenamento compartilhado.	Agradecemos à Mozilla por sua análise cuidadosa de nossa proposta. Pretendemos responder ao feedback deles em breve.

ÍCONES

Tema do feedback	Resumo	Resposta do Chrome
Requisito particionado	Foi adicionado um requisito de comportamento explícito para o atributo "Particionado" em cookies primários.	Conversamos sobre isso em uma chamada do PrivacyCG e continuamos o problema no GitHub com observações. Continuamos trabalhando com navegadores, desenvolvedores e a comunidade de privacidade para alinhar e especificar um comportamento.
Incorporações autenticadas	Os CHIPS podem afetar o fluxo atual de login via SSO devido ao particionamento diferente que afeta as incorporações autenticadas.	Conhecemos o caso de uso de incorporações autenticadas e estamos trabalhando para encontrar soluções.
Limite de partição de cookies	A preocupação é que o limite atual de 10 cookies não seja suficiente para determinados casos de uso.	Estamos deixando de ser o limite de cookies para um limite de memória de 12 KB. Isso nos permite lidar com questões relacionadas ao limite de cookies e, ao mesmo tempo, garantir que o desempenho e o consumo de memória do navegador não sejam afetados negativamente.
Cronograma do teste de origem	Estender o OT após a remoção do requisito de limite do nome do host.	Estendemos o prazo do teste de origem após o feedback do ecossistema.
Testar limitações no Chrome	Possibilidade de testar os CHIPS no Firefox devido à limitação atual no Chrome.	A implementação do Firefox é aproximadamente diferente, o Chrome tem um limite de cookies menor e o CHIPS é um mecanismo de ativação, mas o Firefox é particionado por padrão.
(Também informado no 2o trimestre) Incorporações autenticadas	O estado de logon é preservado com os CHIPS?	Atualização do 3o trimestre: O estado de login não é preservado, mas não é o caso de uso pretendido para os CHIPS. Conhecemos o caso de uso de incorporações autenticadas e estamos trabalhando para encontrar soluções.

FedCM

Tema do feedback	Resumo	Resposta do Chrome
(Também informado no 2o trimestre) Possíveis vetores de ataque	Possíveis vetores de ataque via decoração de link e ataques de tempo.	Atualização do 3o trimestre: Trabalhamos com o Mozilla para chegar a um entendimento comum de como lidar com o problema do tempo de ataque. Os detalhes estão aqui. Agora estamos fazendo a prototipagem dessa mudança arquitetônica e esperamos realizar experimentos nos próximos trimestres.
Provedores de identidade	Seletor de conta: provedor de identidade único. Solicite a permissão de vários provedores de identidade.	Trabalhamos com fornecedores de navegadores e com o FedID CG para conseguir permitir vários provedores de identidade e chegamos a uma fórmula que parece valer a pena tentar. A descrição da proposta está aqui. Esperamos desenvolver protótipos e realizar experimentos nos próximos trimestres.
Problemas conhecidos com a federação	Solicitação para enumerar casos em que a federação pode ter problemas com a descontinuação de cookies de terceiros.	O FedID CG tem um item de trabalho para enumerar as falhas de federação aqui e aqui. Eles também estão criando uma matriz de decisão para mapear falhas nas APIs Web Platform aqui.
Parâmetro Nounce	O parâmetro do Nounce pode afetar o fluxo de login?	Isso pode ser considerado rastreamento entre sites, mas ainda estamos coletando informações e analisando como tratar esses casos.
Consentimento do usuário	Vincular diferentes partes confiáveis (RPs, na sigla em inglês) e consentimento do usuário para cada origem.	Esta especificação não pode controlar como as origens no mesmo domínio compartilham cookies. A especificação permite o idtoken da origem do IdP para a origem do RP, mas cabe ao RP escolher se o estado de login do usuário deve ser armazenado em um cookie bloqueado para essa origem única ou um cookie compartilhado com origens dentro do mesmo domínio.
Conta do IdP portabilidade	Opção do usuário para migrar IdPs se quiser fazer a transferência entre dois IdPs.	Parece que isso é algo que o usuário precisaria fazer diretamente na página de inscrição do novo IdP de escolha, não pela API FedCM.
Exclusão de contas	Contabilização da revogação do IdP para exclusão de contas com o IDP.	Esta solicitação de recurso está aberta para entrada e em investigação.
Reivindicação de interface	Declarações sobre aspectos da interface específicos para navegadores.	Consulte Solicitação de envio para resolver isso.
Verificação de referência do IdP	O IdP verifica o referenciador da RP.	A verificação obrigatória do referenciador do IdP foi adicionada à especificação. Consulte Solicitação de envio.
Fluxo de login	Solicitação de fluxos de login a serem personalizados com base nas preferências da parte restrita.	Aceitamos a ideia e estamos discutindo-a ativamente.

Combater spam e fraudes

API Trust Tokens

Tema do feedback	Resumo	Resposta do Chrome
Fraudes e abusos	Ferramentas para garantir que um bot não tenha enganado o emissor para que ele fornecesse um token, que um bot não assumiu um token emitido para um usuário real e para impedir os bots de emitir tokens maliciosos?	Embora os bots possam receber tokens de um emissor, é recomendado que os emissores tenham limites para a frequência de emissão de tokens e métodos robustos para emitir tokens e atualizar a lógica de emissão à medida que agentes mal-intencionados tentam burlar esses tokens. Os emissores que não tiverem uma lógica robusta o suficiente para emitir tokens provavelmente vão se tornar menos confiáveis no ecossistema, já que os sites priorizam emissores mais robustos.
Fraudes e abusos	Existe uma maneira de um resgate de tokens de confiança especificar que só aceita tokens de confiança de entidades específicas?	Sim, isso é possível. A seção Resgate de tokens de confiança na explicação descreve como isso funciona.
Fraudes e abusos	Existe uma maneira de um emissor de token de confiança definir uma lista de resgates e não permitir que outra pessoa resgate tokens?	No momento não, mas a equipe está investigando o caso de uso.
Cronograma	Quando a API Trust Token estará disponível para todos os usuários?	Assim que pudermos estabelecer um cronograma, vamos compartilhar mais informações publicamente.
(Também informado no 2o trimestre) Sobrecarga de manutenção	Não está claro por quanto tempo as versões do protocolo serão compatíveis.	Atualização do 3o trimestre: O suporte às APIs para oferecer suporte a várias versões simultâneas está sendo adicionado para permitir uma transição tranquila entre versões, embora os prazos para suporte / descontinuação ainda estejam sendo definidos.