Relatório trimestral do primeiro 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 dos compromissos com a Autoridade de Concorrência e Mercados, o Google concordou em fornecer publicamente 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 do desenvolvimento e testes, as perguntas e o feedback foram recebidos principalmente em relação às APIs e tecnologias Topics, Fledge e Attribution Reporting.
É possível que os comentários recebidos recentemente ainda não tenham sido considerados uma resposta do Chrome.
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
Temas comuns de todas as fontes de feedback
Um tema comum em nossas discussões e canais de feedback são perguntas sobre o tempo, os níveis de tráfego e a disponibilidade dos testes. Particularmente, os testadores sempre quiseram a confirmação de quando as APIs vão estar disponíveis para testes e se os testes vão estar disponíveis no mundo todo.
Para lidar com esse feedback, o Chrome tem comunicado amplamente, e o Chrome vai postar uma pergunta frequente confirmando que o teste vai estar disponível no mundo todo. Além disso, o Chrome vai continuar atualizando os cronogramas públicos regularmente em consulta com a CMA.
Exiba conteúdo e anúncios relevantes
| API / Tecnologia | Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Tópicos | Utilidade de tópicos gerais | Foi levantado a preocupação de que a taxonomia de tópicos gerais não seja útil o suficiente para a publicidade com base em interesses. | A utilidade da API será explorada por meio de testes. O Chrome espera que a taxonomia evolua com base nos resultados dos testes. |
| Tópicos | Taxonomia | As partes interessadas do setor querem ter uma voz para influenciar a taxonomia. | O Chrome continua aberto para inserir informações sobre a taxonomia. O Chrome tem muito interesse em receber feedback sobre o modelo de governança para modificar a taxonomia e discutir como outros órgãos do setor podem desempenhar um papel mais ativo no desenvolvimento e na manutenção da taxonomia em longo prazo. |
| Tópicos | Utilidade para diferentes tipos de sites | Foram levantadas preocupações sobre a utilidade dos sites, dependendo do nível de tráfego ou da especialização do conteúdo. | A utilidade da API será explorada por meio de testes. 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. |
| Tópicos | Metodologia de classificação de sites | Solicitar que os sites sejam capazes de decidir ou influenciar a classificação dos temas. | O Chrome está analisando essa solicitação, mas recebemos preocupações (da comunidade de navegadores da Web e de DSPs) sobre o risco potencial de os sites conseguirem manipular o sistema para segmentar usuários de maneira invasiva a privacidade ou reduzir a relevância dos anúncios. O Chrome está buscando feedback e ponderando possíveis mudanças. |
| Tópicos | Sinais de ruído | Apresentar um tópico aleatório 5% do tempo pode criar muito ruído / sinal falso. | O ruído é um método importante para proteger a privacidade do usuário. Os níveis de ruído em comparação com a utilidade dos temas serão explorados em testes. |
| Tópicos | Permissão de terceiros controlada pelo site | Solicitar que os sites possam escolher quais adtechs podem chamar a API Topics no próprio site. | Esse recurso solicitado já é compatível com a política de permissões "browsing-topics", conforme mencionado na explicação. |
| Tópicos | Efeito da API Topics no desempenho da página | Preocupações com atrasos no primeiro anúncio devido à dependência da API Topics. | O Chrome está discutindo um suporte possível para temas em cabeçalhos de solicitação HTTP para melhorar o desempenho. Estamos contando com testes para saber se essas mudanças são necessárias. |
| Tópicos | Privacidade / Política | Perguntas sobre o objetivo de filtrar respostas por autor da ligação caso alguns terceiros compartilhem os temas com qualquer pessoa que ligue | Com base no feedback de várias pessoas no ecossistema, o Chrome escolheu esse design para limitar o acesso às informações às pessoas que, de outra forma, não teriam acesso a elas. É claro que editores e terceiros que recebem a API Topics podem decidir por conta própria quais informações vão compartilhar com as partes no site. Se eles fizerem esse tipo de compartilhamento, o Chrome os recomenda fortemente a serem transparentes com os usuários sobre tal compartilhamento e oferecer a eles controles. |
| Tópicos | Documentação | Interesse em documentação que abrange os detalhes do modelo de classificador e da taxonomia usados pelo Chrome, assim como você fez no FLoC, por exemplo, com que frequência o classificador e a taxonomia vão mudar | O Chrome já oferece a taxonomia usada como parte dos testes de origem, e o modelo de classificador que categoriza os sites nos temas é disponibilizado na base de código do Chrome como parte do código aberto. Como parte dos testes de origem, o Chrome reserva o direito de fazer alterações conforme o feedback é recebido e os aprendizados sobre o funcionamento do app. |
| FLEDGE | Limite de frequência | Querer controlar a frequência por usuário em uma campanha ou um grupo de anúncios. | O FLEDGE vai oferecer suporte ao limite de frequência para leilões no dispositivo. Há um problema aberto em que isso é abordado para que o FLEDGE também ofereça suporte a campanhas contextuais/de marca. O armazenamento compartilhado, outra API em desenvolvimento e limites específicos de sites também podem ser usados para outros controles de limite de frequência. |
| FLEDGE | Impacto do FLEDGE no desempenho | Levantamos preocupações sobre o possível impacto dos bidders com alto consumo de computação no leilão do FLEDGE | O Chrome está em discussões ativas com desenvolvedores sobre o possível impacto no desempenho do site. No Chrome, você tem a oportunidade de saber mais durante os testes. |
| FLEDGE | Como testar o FLEDGE com outros recursos | Quando e como serão realizados os testes com outros recursos (servidor de k-anonimato, servidores de chave-valor etc.). | O Chrome está lançando recursos intencionalmente em fases nos testes de origem iniciais para facilitar os testes. O Chrome reconhece que é importante esclarecer o cronograma de outros recursos e esclarecerá quando possível. |
| FLEDGE | Coordenação de testes | Como coordenar testes em várias adtechs | O Chrome está investigando a possibilidade de oferecer suporte adicional para ajudar a coordenar experimentos para que diferentes adtechs experimentem os mesmos usuários. Esse também é um foco fundamental da divulgação de parcerias do Chrome. Organizações comerciais do setor também manifestaram interesse em desempenhar um papel. |
| FLEDGE | Limites de grupos de interesse | Haverá limites quanto ao número de grupos de interesse a que um usuário pode ser adicionado ou que pode ser incluído no leilão? | O Chrome está disposto a refinar esses limites de desempenho da página da Web ou de experiência do usuário durante o período de teste com base no feedback e no impacto da latência medido. Há uma discussão em andamento entre os testadores sobre formas adicionais de permitir que compradores e vendedores ajustem o uso de recursos. |
| FLEDGE | Recursos entre APIs | Como os relatórios de atribuição vão funcionar com o FLEDGE? | Todos os detalhes ainda serão definidos, e o Chrome pretende ter uma atualização no segundo trimestre. O Chrome espera continuar fornecendo relatórios a nível de evento sobre os resultados do leilão (vitórias e derrotas) durante o teste de origem. |
Medir os anúncios digitais
| API / Tecnologia | Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Attribution Reporting (e outras APIs) | Como testar o tráfego | Preocupações sobre se vai haver tráfego suficiente para o teste | O Chrome está iniciando o teste de origem com tráfego muito baixo para garantir que não haja bugs graves ou problemas com os controles do usuário. Os primeiros testadores têm um papel importante na confirmação de que as APIs estão funcionando conforme o esperado do ponto de vista técnico, o que ajuda a acelerar o aumento para um tráfego maior. Quando houver confiança de que as APIs estão funcionando conforme o esperado, o Chrome vai aumentar o teste de origem para oferecer suporte ao teste utilitário. |
| Relatórios de atribuição | Ergonomia para registrar eventos | Perguntas sobre as formas de inscrição aceitas em eventos. | O Chrome publicou uma resposta no GitHub para esclarecer quais formas de registro são compatíveis atualmente. O Chrome está coletando feedback do ecossistema sobre o design atual para ver se as mudanças propostas atendem a essas preocupações ou se são necessárias mais atualizações. |
| Relatórios de atribuição | Geração de ruído | Quer mais detalhes sobre como o ruído é gerado para relatórios agregados. | O Chrome publicou uma resposta no GitHub para fornecer mais detalhes sobre a forma sistemática de gerar ruídos. O Chrome planeja fornecer uma biblioteca para simular ruídos e fazer testes com diversos parâmetros durante o OT. O Chrome também planeja fornecer documentação adicional para desenvolvedores e guias sobre o modo de relatórios agregados. |
| Relatórios de atribuição | Dados menos precisos para sites pequenos | Preocupação com o fato de sites ou campanhas menores receberem dados menos precisos. | O Chrome reconhece que as proteções de privacidade baseadas em ruído têm maior impacto em frações de dados menores. No entanto, é possível que métodos como a agregação durante períodos mais longos resolvam esse problema. Também não está claro se as conclusões baseadas em frações de dados muito pequenas (como uma ou duas compras) são significativas para os anunciantes. Durante o teste de origem, o Chrome incentiva os testadores a aproveitar uma ampla variedade de parâmetros de privacidade e ruído para fornecer feedback mais específico sobre esse problema. |
| Relatórios de atribuição | O tempo até a conversão afeta os serviços | A preocupação com o fato de que o tempo até a conversão vai interferir na configuração e na verificação ou na otimização das campanhas. | O Chrome recebeu alguns feedbacks conflitantes sobre o impacto dos atrasos nos relatórios de conversão. No entanto, como a API Attribution Reporting apresenta atrasos aleatórios nos relatórios para proteger a privacidade dos usuários, o Chrome espera que casos de uso ou preocupações específicos fiquem mais claros durante o período de teste e possam ser resolvidos com mais suporte de depuração ou orientações do desenvolvedor. |
| Relatórios de atribuição | Janela de atribuição mais longa | Solicitação para estender a janela de atribuição de 30 dias | O Chrome publicou uma resposta em busca de mais feedback sobre a duração da janela de atribuição, considerando a minimização de dados e a utilidade. |
| Relatórios de atribuição | Impressões não visíveis | Perguntas sobre se as impressões não visíveis são contadas para os relatórios de conversão de visualização. | O Chrome publicou uma resposta no GitHub para oferecer mais clareza sobre as impressões visíveis. |
Limitar o rastreamento oculto
| API / Tecnologia | Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Redução do user agent | Desempenho | Há preocupações sobre a latência do recebimento de dicas via Critical-CH (no primeiro carregamento de página). | O Chrome está investigando maneiras de melhorar o desempenho. |
| Redução do user agent / Dicas de cliente do user agent | Questões relacionadas a antifraude / antiabuso | É importante ter o máximo de informações possível ao depurar certos tipos de ataque, incluindo negação de serviço. Perder algumas informações da string do UA pode representar um desafio. | O Chrome está em discussões e avaliando maneiras de manter a privacidade ao mesmo tempo que fornece informações suficientes que serão úteis para a depuração. |
| Redução do user agent | Confusão com a configuração do OT | Vários participantes do teste de origem recomendaram melhorar a documentação com exemplos de como se inscrever no teste. | O teste de origem reduzido do UA está terminando, mas o Chrome pretende melhorar as instruções do teste de descontinuação, inclusive destacando o exemplo de demonstração. |
| Redução do user agent | Preocupação com os valores de uma dica específica | Perguntas sobre se o Sec-CH-UA-Model é o mesmo que <deviceModel> na string do user agent. | Sec-CH-UA-Model é o mesmo que <deviceModel> na string do user agent. O Chrome tentará deixar isso mais claro na documentação futura. |
| Redução do user agent | Preocupação com a inscrição no teste de descontinuação | Perguntas sobre como inscrever um grande número de domínios no teste de descontinuação | O Chrome considerou abordagens centralizadas ao criar o teste de descontinuação, mas ele acredita que o teste de origem atual é a melhor opção, já que dá todo o controle aos desenvolvedores, já que eles podem escolher enviar o cabeçalho ou não. |
| Dicas de cliente HTTP do user agent | Preocupações com a natureza prescritiva da UA-CH | Há uma preocupação de que o UA-CH seja excessivamente prescritivo em comparação com a flexibilidade que o cabeçalho do user agent oferece, conforme definido por rfc7231. | Para o Chrome, a natureza prescritiva dos cabeçalhos UA-CH é uma melhoria importante em relação à flexibilidade da string do UA, tanto do ponto de vista da interoperabilidade entre navegadores quanto da proteção de privacidade do usuário, evitando adições arbitrárias de identificadores de alta entropia.
No entanto, o problema permanece aberto caso outras pessoas também compartilhem essa preocupação e queiram fornecer feedback. |
| Dicas de cliente HTTP do user agent | Preocupações com o uso da API para bloquear determinados navegadores | Preocupação de que um site está usando a API para procurar "Google Chrome" ou "Microsoft Edge" e bloquear todos os outros navegadores. | O conceito de uma lista de marcas foi criado para lidar com esse caso: um navegador pode enviar "Google Chrome" além das suas próprias marcas. |
| Dicas de cliente HTTP do user agent | Solicitação de um método para enumerar todas as dicas compatíveis. | Interesse em ter uma maneira programática de conhecer todas as dicas compatíveis com um navegador. | O Chrome está avaliando a solicitação de recurso. |
| Redução do user agent / Dicas de cliente do user agent | Questões relacionadas a antifraude / antiabuso | As dicas do cliente não estão disponíveis no primeiro carregamento para HTTP1 | Uma das APIs Client Hints Reliability (Accept_CH) está disponível apenas para HTTP2 e HTTP3. No caso de servidores que ainda são veiculados por HTTP1, eles precisam depender apenas de CH crítico. |
| Redução do user agent | Impacto no Chrome para Android | Perguntas sobre como isso afeta o Chrome no Android em particular. | A redução de UA e a UA-CH serão enviadas no Chrome no Android, além do computador. No Chrome no Android, as mudanças só ocorrerão na "Fase 6", atualmente programada para o Chrome 110. |
| Gnatcatcher (WIPB) | Usos e métodos não conformes | Clareza sobre o que seriam os usos e métodos não conformes. | O Chrome vai atualizar a explicação com mais detalhes. |
| Gnatcatcher + Redução do user agent | Redução de indicadores contra fraudes | Impacto antifraude da redução simultânea do acesso ao IP e ao UA. | As disposições da política de cegueira de IP voluntária contra fraudes (para permitir o uso de IP em casos de uso antifraude) resolverão as preocupações de defesa relacionadas ao proxy de IP. |
| Rastreamento de navegação | Preocupação com falhas futuras | Os anunciantes estão preocupados com possíveis falhas. Provedores de identidade também manifestaram interesse nos planos do Chrome. | O Chrome não está fazendo mudanças interruptivas e ainda está explorando casos de uso. |
| Cookies SameSite | Interoperabilidade com outros navegadores | Perguntas sobre os planos do Chrome para corrigir crbug.com/1221316, já que é uma área em que as implementações do Chrome divergem de outros navegadores. | O Chrome descobriu um bug nas métricas e registrou novas métricas. O Chrome está coletando dados para entender melhor o impacto da correção do bug. |
| Particionamento de armazenamento | Problema com o particionamento de canais de mensagem | Perguntas sobre se os canais de mensagens (por exemplo, SharedWorker e BroadcastChannel) precisam ser particionados. | O Chrome está avaliando o feedback, mas acredita que o particionamento de canais de mensagens e o armazenamento são necessários para evitar rastreamento oculto. |
Fortaleça os limites de privacidade entre sites
| API / Tecnologia | Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Conjuntos primários | 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. | O Chrome ainda está definindo os requisitos da nossa política e vai levar esse feedback em mente. |
| Conjuntos primários | A Entidade de Aplicação Independente (IEE) provavelmente vai receber um grande número de contestações de validade do FPS | Resumo dos desafios previstos para determinar a validade do QPS: o texto ou a política de privacidade não corresponde aos membros do conjunto, clareza sobre como definir a associação óbvia para o usuário, desafios de largura de banda e tempo e conhecimento especializado sobre a estrutura corporativa. | O Chrome ainda está definindo os requisitos da nossa política e vai levar esse feedback em mente. |
| Conjuntos primários | Processo para manter a lista de QPS dos navegadores | Preocupações com barreiras de entrada em sites de países não ocidentais, versões inconsistentes da lista de QPS nos navegadores devido a diferenças na cadência de atualização e capacidade de navegadores menores/mais novos de usar a lista. | O Chrome ainda está definindo os requisitos de política, o processo de aceitação e os direitos de uso da lista. Vamos manter esse feedback em mente.
O Chrome também vai usar os aprendizados de outras listas estáticas usadas na plataforma da Web, como a lista de sufixos públicos. |
| Conjuntos primários | Design de declaração dinâmica por site | Um design dinâmico (em oposição a uma lista estática) pode ser mais propenso a falsas declarações de propriedade comum e a latência/falhas de carregamento da página. | No momento, o Chrome segue a abordagem de lista estática. Vamos levar esse feedback em consideração se a abordagem de declarações assinadas for reavaliada no futuro. |
| Conjuntos primários | Possíveis casos de uso de conjuntos primários (se for possível criar uma versão confiável e equitativa da lista de QPS) | Logon único, solicitações de dados personalizáveis e possibilidades de relatórios de transparência aprimorada para os usuários. | O Chrome vai considerar esse feedback ao analisar as próximas etapas para os conjuntos primários. |
| ÍCONES | Compatibilidade com navegadores | Interesse em entender como outros navegadores lidaram com atributos de cookies particionados | O Chrome continua trabalhando em grupos de padrões públicos, como o W3C, para identificar designs e implementações que funcionam em vários navegadores. |
| ÍCONES | Requisito de design | Não é possível incluir o prefixo __Host- name | O Chrome removeu o requisito de nomenclatura para o teste de origem e decidirá se ele será permanente ao final do período. |
| ÍCONES | Uso dos CHIPS para casos de uso de anúncios | Perguntas sobre a possibilidade de uso dos CHIPS para casos de uso de anúncios. | Com o CHIPS, um terceiro pode criar cookies do lado do cliente que são particionados no site de nível superior (ou no conjunto primário). Se o caso de uso precisar de estado particionado e não de estado entre sites, os CHIPS poderão ser usados para esse caso de uso. |
| ÍCONES | Integração de CHIPS com QPS | Não é possível realizar testes com os CHIPS em conjunto com outras propostas do Sandbox de privacidade, como os conjuntos primários. | O Chrome está explorando ativamente formas de facilitar os ambientes de teste que permitiriam a realização desses testes. O Chrome também publicou instruções de testes locais para QPS e CHIPS, que podem ser usadas enquanto isso. |
| FedCM | Expressividade | A preocupação é que, como o navegador renderiza parte do fluxo de identidade federado, é difícil capturar todas as nuances que os IdPs gostariam de apresentar aos usuários. | O Chrome reconhece as compensações e vai continuar trabalhando com o ecossistema para abordar o máximo de aspectos possível e torná-lo o mais expressivo possível. Algumas ideias que o Chrome está explorando incluem personalizações de marca (por exemplo, logotipos, cores) e personalização de string (por exemplo, "acessar este artigo" em vez de "fazer login com"). |
| FedCM | Envolvimento do navegador | A preocupação é que o navegador esteja mais envolvido no fluxo de federação de identidade do que anteriormente, por isso ele está mais explicitamente ciente em quais sites o usuário está conectado (também com qual IDP). | O Chrome reconhece que o navegador agora desempenha uma função mais ativa, mas esse nível extra de envolvimento é necessário para que o navegador diferencie e impeça o rastreamento entre sites sem deixar de permitir a federação. |
| FedCM | Aplicabilidade e interoperabilidade | Preocupação com o fato de outros navegadores não adotarem nem implementarem a FedCM. | O Chrome também tem trabalhado com outros fornecedores de navegadores para encontrar soluções comuns para a federação no Grupo da Comunidade FedID. |
| FedCM | Vários desafios da API | Preocupação com o fato de que o FedCM ainda está no início / imatura e vai demorar muito para oferecer todos os recursos de que o ecossistema precisa. | O Chrome vai analisar isso melhor como parte dos testes do ecossistema. |
| FedCM | Políticas empresariais e controles de usuários | Preocupação se vai haver um controle (por exemplo, políticas corporativas e/ou configurações do usuário) que permita às empresas manter a implantação da identidade federada sem nenhuma alteração. Há muitas implantações locais de identidade federada que são excepcionalmente difíceis de reimplantar ou alterar, por isso há muita resistência em relação a novas APIs de navegador que exigem IDPs para serem reimplantadas. | O Chrome está explorando controles para administradores e usuários corporativos e acredita que resolverão essas preocupações. O Chrome recebe feedback das empresas sobre casos de uso específicos que elas gostariam de considerar. |
Combater spam e fraudes
| API / Tecnologia | Tema do feedback
(Classificação por prevalência por API) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| API Trust Token | Limites de resgate | Há preocupações sobre a restrição de dois por página, principalmente em cenários em que uma delas pode estar incorporada à mesma página várias vezes ou ter um segundo domínio de emissor na organização. Alguém provavelmente atingiria o limite sem considerar os outros participantes do mercado. | O Chrome está disposto a expandir um pouco o limite de resgate por página se aumentaria a adoção, mas precisa mantê-lo relativamente baixo para introduzir entropia excessiva. Além disso, armazenar um registro de resgate em cache pode reduzir a necessidade de um emissor resgatar vários tokens para um único usuário em um curto período. |
| API Trust Token | Latência | Normalmente precisam responder às solicitações de lance em até 10 ms. Por isso, resgatar um token no carregamento da primeira página torna quase impossível incluir as decisões sobre tráfego inválido pré-lance. | O Chrome está tentando entender por meio de testes como a latência afeta os casos de uso de pré-lance. |
| API Trust Token | Adoção do OpenRTB | Para casos de uso do Prebid, é fundamental transmitir as informações do token resgatado às SSPs e DSPs para uso na tomada de decisões de anúncios. | O Chrome está aberto à colaboração com o IAB para garantir que qualquer indicador útil contra fraudes/antiabuso possa ser propagado pelo OpenRTB, embora seja o proprietário do padrão para adição de novos campos padrão. |
| API Trust Token | Privacidade | Perguntas sobre a viabilidade a longo prazo de qualquer forma de propagação de dados entre sites, embora uma baixa quantidade de entropia (aproximadamente 2,5 bits) | Considerando as robustas proteções do usuário para evitar a identificação de usuários únicos, o Chrome acredita que há um bom caso para a aceitação do ecossistema. O Chrome está trabalhando em estreita colaboração com as principais partes interessadas para garantir a viabilidade a longo prazo. |
| Indicadores de atestado da plataforma | Avaliar o interesse em uma nova ideia/proposta | Forte suporte a vários sinais viáveis (e inviáveis), como a transmissão de sinais de integridade do dispositivo que a plataforma pode fornecer. | O Chrome planeja levar essa ideia ao grupo da comunidade antifraude do W3C como uma nova ideia para feedback. |
| Servidores confiáveis contra fraudes | Avaliar o interesse em uma nova ideia/proposta | O conceito é interessante, mas provavelmente exige mais investigação dos casos de uso aplicáveis. | Dependendo dos níveis de interesse, o Chrome pode criar mais ideação sobre esse conceito e transformá-lo em uma explicação para o futuro feedback do ecossistema. |