Relatório trimestral do 2º trimestre de 2023 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 do 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 as 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 a 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 tema específico e organizado 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 dos órgãos de padrões da Web foram analisadas e, para feedback direto, 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 foram considerados. 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 feitas a problemas levantados por 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, foram recebidas perguntas e feedback específicos em relação às APIs Topics, Protected Audience e Attribution Reporting.
O feedback recebido após o fim do período de geração de relatórios atual pode ainda não ter uma resposta considerada do Chrome.
Glossário de acrônimos
- CHIPS
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos próprios
- 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 da Origin
- PatCG
- Grupo da comunidade de tecnologias de publicidade privada
- RP
- Entidade 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
- IP Blindness proposital
Feedback geral, sem API/tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Governança de dados e compliance regulatório | Orientações sobre o uso do Sandbox de privacidade para atender aos requisitos regulatórios. | Como acontece com qualquer nova tecnologia, cada empresa é responsável por garantir que o uso do Sandbox de privacidade esteja em conformidade com a lei. O Google não pode dar conselhos jurídicos. No entanto, sabemos que essa é uma área importante para o ecossistema. Para cada API, publicamos uma documentação técnica extensa, que deve fornecer a base para fazer as avaliações legais necessárias. Também estamos trabalhando para disponibilizar outros materiais em apoio aos esforços das empresas para cumprir os requisitos regulamentares. |
| Proposta de teste quantitativo da CMA | Mais informações sobre a proposta de teste quantitativo da CMA | Estamos trabalhando com a CMA para projetar experimentos que vão mostrar o impacto da descontinuação dos cookies de terceiros e a introdução das propostas do Sandbox de privacidade no ecossistema. Em abril, a CMA publicou orientações gerais sobre o que esperar durante o período de testes e testes, seguido de orientações detalhadas em junho. Recomendamos que você compartilhe perguntas ou feedback sobre a proposta de testes quantitativos diretamente com a CMA. |
| Modos de teste facilitados pelo Chrome | Mais informações e esclarecimentos sobre os horários dos testes | Publicamos uma postagem no blog em 18 de maio com mais informações sobre os dois modos de teste facilitado do Chrome. Esses detalhes não são finais, e vamos publicar mais orientações de implementação à medida que avançamos no terceiro trimestre de 2023. |
| Armazenamento particionado | O armazenamento particionado será usado durante o teste facilitado pelo Chrome? | O particionamento de armazenamento será enviado para todos os usuários antes do experimento de descontinuação de cookies de terceiros. Por isso, ela será ativada para todos os grupos do experimento. Os sites vão ter a opção de ativar um teste de suspensão de uso para recuperar o armazenamento não particionado durante esse período. |
| Suporte de produção | Qual é o processo em vigor para o Chrome oferecer suporte a problemas técnicos e encaminhamentos do Sandbox de privacidade que afetam o ecossistema? | O Google oferece vários canais para que as adtechs possam informar problemas e fazer encaminhamentos necessários. Consulte nossa visão geral de feedback para mais informações sobre os fóruns públicos e privados para feedback e encaminhamento. |
| Cronograma de inscrição | O período atual de inscrição é muito curto | Ainda estamos avaliando o prazo de aplicação e gostaríamos de saber do ecossistema qual cronograma seria mais adequado. |
| Número D-U-N-S | Mais informações sobre a exigência de número D-U-N-S para inscrição e atestado | Os participantes podem encontrar os requisitos para receber um número D-U-N-S no site da Dun & Bradstreet. Os requisitos variam de acordo com o mercado. Por isso, os participantes precisam verificar o site do mercado específico em que estão interessados. No geral, no entanto, os participantes precisam fornecer informações básicas sobre a empresa, como o nome, o endereço e os dados de contato do proprietário ou gerente. Os participantes também podem ser solicitados a fornecer informações financeiras, como a receita anual da empresa. Depois que o pedido for concluído, a D&B vai analisá-lo e emitir um número D-U-N-S se ele for aprovado. |
| Como fazer a transição do teste de origem para a disponibilidade geral | A transição do teste de origem para a disponibilidade geral vai afetar os testadores atuais do teste de origem? | A partir de julho, os testadores poderão acessar as APIs de relevância e medição na disponibilidade geral. Isso vai permitir uma sobreposição entre a disponibilidade do teste de origem e a disponibilidade geral. |
| Estudo do AdExchanger | Mais informações sobre a metodologia da pesquisa | A pesquisa pediu aos participantes que estimassem as taxas de sincronização e a receita das empresas. A metodologia dos participantes para responder às perguntas individuais foi de responsabilidade deles. |
| Valores de parâmetros | Como os valores de parâmetros, como nível de ruído, limites de anonimato e orçamento de privacidade, são determinados? | Esta explicação do GitHub (link em inglês) define os princípios mais gerais por trás das APIs do Sandbox de privacidade. Muitos valores ainda estão sendo finalizados, e seu feedback sobre esse assunto é muito bem-vindo. |
Mostrar conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Preservação da privacidade | Pesquisa que avalia a API Topics em relação à preservação de privacidade | Estamos ativamente envolvidos com a comunidade de pesquisa, apresentando nossas pesquisas sobre as propriedades de privacidade da API Topics em artigos, relatórios e apresentações de seminários. Ficamos felizes em ver mais membros externos da comunidade de pesquisa se engajando nessa área. A API Topics protege os usuários contra o rastreamento geral na Web, tornando muito difícil rastrear os usuários em grande escala. Esses documentos mostram que estamos fazendo isso com a API Topics. Ele é mais particular do que os cookies de terceiros e protege os usuários, além de oferecer suporte aos sites que eles gostam de visitar. |
| A taxonomia de tópicos não é suficientemente detalhada | A taxonomia de temas amplos não inclui temas mais específicos, como aqueles específicos de uma região. | Em resposta ao feedback anterior do ecossistema, publicamos uma postagem do blog em 15 de junho detalhando uma nova taxonomia atualizada que incorpora várias melhorias após o feedback do ecossistema. Como parte do nosso trabalho na taxonomia revisada, interagimos com várias empresas do ecossistema, como Raptive (antiga CafeMedia) e Criteo. A taxonomia atualizada remove categorias que ouvimos dizer que são menos úteis, em favor de categorias que correspondem melhor aos interesses dos anunciantes, mantendo nosso compromisso de excluir temas potencialmente sensíveis. Recomendamos que o ecossistema analise a taxonomia mais recente e envie feedback sobre as mudanças. |
| Processo de atualização da taxonomia e do classificador | Mais informações sobre a taxonomia de tópicos e a cadência de lançamento do classificador e como as empresas podem se preparar para essas atualizações. | Como mencionado na postagem do blog, esperamos que a taxonomia evolua com o tempo e que a governança seja transferida para uma parte externa que represente as partes interessadas de todo o setor. Também compartilhamos o plano de aceleração no grupo topics-announce. |
| Impacto nos indicadores próprios | O aumento no número de tópicos na atualização recente da taxonomia pode ser muito valioso e, como resultado, desvaloriza outros indicadores próprios com base em interesses. | No relatório do primeiro trimestre de 2023, o CMA comentou que "Entendemos que o Google tem discutido a nova proposta de taxonomia com vários participantes do mercado em toda a cadeia de suprimentos de adtechs. Embora alguns grandes editores tenham dito que uma maior utilidade dos tópicos aumentaria a pressão competitiva nas soluções baseadas em dados próprios, nossa visão preliminar é que uma maior utilidade é melhor para a concorrência em geral, especialmente para a capacidade de editores menores continuarem a monetizar o inventário após a descontinuação dos cookies de terceiros". Nossa opinião está alinhada com este comentário feito pela CMA. |
| Utilidade para diferentes tipos de partes interessadas | As adtechs que atuam como SSPs e DSPs podem ter vantagens significativas em relação a outros participantes do ecossistema. | Nossa resposta não mudou em relação aos trimestres anteriores: "O Google se comprometeu com o CMA a projetar e implementar as propostas do Sandbox de privacidade de uma forma que não distorça a concorrência ao se auto-referenciar o próprio negócio do Google e a considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes, independentemente do tamanho deles. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho esteja em conformidade com esses compromissos. À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é como as novas tecnologias funcionam para diferentes tipos de partes interessadas. O feedback é essencial nesse sentido, especialmente feedback específico e útil que possa 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 fornecer mais informações aos participantes do mercado e uma oportunidade de comentar sobre as abordagens propostas." |
| Temas descendentes | Como os critérios de seleção de tópicos são a frequência de visitas ao navegador, a fragmentação do segmento vai fazer com que os tópicos descendentes nunca apareçam no topo? | No momento, o Chrome está avaliando outras metodologias de classificação e explorando outros indicadores que podem melhorar a classificação. Vamos comunicar nossos planos revisados ao ecossistema em breve. |
| Confidencialidade | O objetivo da API Topics é garantir que as informações do usuário obtidas ou derivadas dela sejam menos sensíveis do que as que podem ser derivadas usando os métodos de rastreamento atuais. | Acreditamos que a API Topics é muito mais privada do que as tecnologias atuais, limita significativamente a reidentificação de usuários e foi projetada para excluir temas sensíveis. Sabemos que os temas podem ser correlacionados ou combinados com dados próprios para criar categorias sensíveis, mas acreditamos que a API Topics é um avanço para a privacidade do usuário e estamos comprometidos em continuar melhorando a API. |
| Estrutura da taxonomia | Adicionar ID, controle de versão e outras estruturas de metadados à taxonomia de tópicos | No momento, na resposta da API, estamos incluindo o ID da taxonomia. À medida que avançamos para a governança de longo prazo, é importante analisar o objeto Topics e incluir outros metadados na versão, se necessário. |
| Controle do editor | Os editores precisam ter voz sobre em quais categorias seus sites devem ser classificados. | A classificação incorreta de sites pode tornar o indicador de tópicos um pouco menos útil, mas os sites específicos que são classificados incorretamente não são mais ou menos prejudicados do que qualquer outro site. Isso acontece porque as informações contextuais de um site sempre estarão disponíveis para leilões, o que forneceria informações comparáveis ao tema correto, mesmo em caso de classificação incorreta. Envie seu feedback sobre esse assunto aqui. Permitir que os editores controlem a classificação deles tem riscos. Os sites podem classificar os próprios sites de forma incorreta intencionalmente, reduzindo a utilidade para todos, ou codificar significados sensíveis em temas menos comuns, prejudicando a privacidade do usuário. |
| Extensões do Google Chrome | Permitir que as extensões do Chrome gerenciem e filtrem tópicos, semelhante às extensões de gerenciamento de cookies atuais | Isso já deve ser possível, como discutido no GitHub, mas agradecemos o feedback adicional do ecossistema. |
| Transição para a disponibilidade geral | A transição do teste de origem para a disponibilidade geral vai afetar a API Topics? | Os usuários que fizerem a transição do teste do Origin para a disponibilidade geral não vão perder dados. |
| Privacidade | Os nomes de host podem conter informações particulares que podem ser reveladas pela API Topics | Temos várias mitigações para garantir a privacidade, como descrito aqui. |
| Fraude e abuso | Como evitar a manipulação de tópicos por visitas fraudulentas | Encontre aqui uma explicação sobre as mitigações. |
| Classificador de temas | Os sites podem solicitar a alteração da classificação de temas? | Queremos saber a opinião do ecossistema sobre esse assunto e agradecemos seu feedback. |
| Sites de provedores de tópicos | Designar determinados sites que hospedam conteúdo para muitos tópicos como "Sites de provedores de tópicos especiais" e treinar classificadores com base nas tags fornecidas nas páginas da Web. | Estamos discutindo a proposta aqui e agradecemos mais feedback. |
API Protected Audience (antes conhecida como FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Ajuste da programação | Impacto no desempenho da filtragem orientada por SSP para otimizar a carga de consultas por segundo (QPS) | Passamos um tempo considerável pensando sobre a modelagem de tráfego, e a recomendação é que as SSPs aproveitem o armazenamento em cache. |
| Testar o volume | É difícil testar a API Protected Audience porque as SSPs e DSPs têm dificuldade para gerar grandes volumes de tráfego. | Estamos sempre engajando parceiros de SSP e DSP para adotar e testar as APIs Protected Audiences. A disponibilidade geral já começou, e temos certeza de que a porcentagem de tráfego com a PA ativada vai facilitar o teste para os parceiros. |
| Complexidade | A implementação de soluções da Protected Audience exige muito esforço e custos. | Sabemos que é difícil adotar novas tecnologias, incluindo o Sandbox de privacidade. A equipe do Sandbox de privacidade está trabalhando em conjunto com várias partes interessadas para educar e apoiar os esforços delas. Além disso, estamos avaliando continuamente outros aceleradores para apoiar a adoção do ecossistema. |
| Ambientes de execução confiáveis | Suporte a ambientes de execução confiável (TEE) em ambientes de nuvem não públicos | Embora estejamos avaliando opções de suporte além das soluções baseadas na nuvem, não é viável oferecer suporte a TEEs locais devido às limitações de segurança locais que exigem uma avaliação demorada para o Sandbox de privacidade. Considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações locais, acreditamos que continuar a expandir e melhorar as implantações baseadas em nuvem (por exemplo, com suporte ao GCP, além da AWS) é o mais benéfico para o ecossistema. No entanto, agradecemos mais feedback sobre por que esse requisito é necessário. |
| Estrutura de custos | A proposta de serviços de lances e leilões vai aumentar o custo e a complexidade das adtechs em comparação com os modelos do lado do cliente. | Estamos desenvolvendo um guia para estimar os custos de suporte a fluxos de trabalho de lances e leilões no servidor de lances e leilões, que será correlacionado com o uso de adtechs, cumprindo uma das metas dos nossos designs. |
| Cronogramas do K-Anon | Quando as restrições de k-anonimato planejadas serão aplicadas em "renderUrl"? | Estamos trabalhando em uma explicação sobre o cronograma de aplicação que será lançada em breve. |
| Restrições de runAdAuction | O Chrome pode restringir o runAdAuction para que ele só possa ser chamado na página principal? |
Embora nosso design ofereça suporte total para que runAdAuction seja chamado na página principal, acreditamos que seria mais prejudicial para os editores restringir esse recurso apenas ao domínio principal.Ouvimos do ecossistema que o Sandbox de privacidade precisa minimizar a carga sobre os editores e anunciantes. Esse feedback está alinhado ao princípio geral de desenvolvimento da Web de que os proprietários de sites podem usar ferramentas de terceiros na operação dos sites. O objetivo do Sandbox de privacidade é incentivar um ecossistema saudável sem precisar prescrever como os editores e as adtechs funcionam. Ao permitir que o editor escolha como e quem chama runAdAuction no site, oferecemos flexibilidade para que eles encontrem o melhor caminho para atender às necessidades. |
| Suporte de implementação | O Chrome pode criar ou contribuir para uma implementação de código aberto de um leilão com vários vendedores? | O objetivo do Sandbox de privacidade é desenvolver tecnologias que preservem a privacidade e não dependam de cookies de terceiros ou outros identificadores entre sites. Queremos incentivar um ecossistema saudável sem precisar prescrever como as adtechs precisam funcionar. Publicamos orientações sobre como as APIs funcionam no nosso repositório do GitHub e estamos abertos a soluções com o setor. Não planejamos criar nenhuma implementação específica, porque nosso objetivo principal é desenvolver tecnologias de plataforma, não ditar estratégias para usar essas tecnologias. Nossas tecnologias vão ajudar as empresas de adtech a atender melhor os clientes com os limites de privacidade certos para os consumidores. |
| Leilões de vários vendedores | O Chrome vai forçar o compartilhamento de um vencedor "contextual" com leilões de componentes? | A API Protected Audience foi projetada para permitir que as partes que iniciam o leilão de vários vendedores transmitam informações ao leilão de componentes (somente antes do início do leilão). Não há como o navegador distinguir se uma informação é vencedora do contexto ou não. Por isso, não podemos forçar o bloqueio ou exigir determinadas informações. |
| Preferência do usuário para o acompanhamento de consentimento | Adtech perguntando ao PA como implementar o rastreamento de consentimento do usuário corretamente | Nossa resposta inclui o que dissemos na pergunta 1: "Para anúncios específicos, a adtech relevante é a parte mais bem posicionada para oferecer controles sobre quais criativos são mostrados ou como eles são selecionados." Discutimos vários cenários relacionados a esse problema durante a Reunião da API Protected Audience do WICG de maio e agradecemos feedback e discussões sobre esse problema. |
| Públicos-alvo personalizados | Os casos de uso de SSP relacionados à criação de públicos-alvo personalizados terão suporte da API Protected Audience? | A API Protected Audience permite que SSPs e outros provedores de adtechs sejam proprietários e gerenciem públicos-alvo personalizados. Outras orientações sobre como um SSP pode se integrar à API PA estão sendo desenvolvidas e serão disponibilizadas para SSPs e outros provedores de adtech para ajudar nos esforços de integração. |
| Formatos | A API Protected Audience oferece suporte a vídeos? | Os anúncios em vídeo são veiculados de duas maneiras: como XML VAST ou HTML (um anúncio outstream que também pode carregar XML VAST em um player de vídeo). Os compradores podem retornar qualquer formato usando um renderURL. A especificação VAST foi atualizada recentemente para oferecer suporte à API Attribution Reporting. Os sites que veiculam anúncios em vídeo precisam se preparar para a forma como os anúncios são veiculados pela API Protected Audience. Isso significa garantir que as tags de posicionamento possam transmitir o URL de um iframe da Protected Audience para um player de vídeo. No caso dos frames delimitados, vamos trabalhar para atender às necessidades de vídeo antes da obrigatoriedade de usar esse recurso, que será a partir de 2026. |
| Ritmo | Como o caso de uso de ritmo funciona com a API Protected Audience? | Seu feedback é muito importante para nossa equipe! Gostaríamos de receber mais solicitações com mais detalhes de outros parceiros do SSP, já que essa é uma preocupação do DSP até o momento. |
| Frequência de atualização | A frequência de chamadas de dailyUpdate (até uma por grupo de interesse por dia) pode não ser suficiente para determinados casos de uso, como atualizar informações do produto. |
Seu feedback é muito importante para nossa equipe! Há outras soluções disponíveis para permitir que as adtechs usem indicadores atualizados em cadências diferentes, como pesquisas K/V. |
| Controle de qualidade dos anúncios | Como os editores implementam o controle de qualidade dos anúncios? | Atualmente, a API Protected Audience oferece funcionalidade para que os editores informem as SSPs sobre determinados controles que podem ser estabelecidos como parte da configuração do leilão, antes do lance (ou seja, listas de bloqueio com base em rótulos associados aos anúncios). Agradecemos o feedback sobre qualquer funcionalidade adicional que o ecossistema possa exigir. |
| Depuração | Quando a funcionalidade forDebuggingOnly será removida? |
Planejamos remover forDebuggingOnly para eventos de perda devido à descontinuação dos cookies de terceiros. Planejamos descontinuar o uso de forDebuggingOnly para eventos de vitória em 2026, no mínimo. |
| Grupos de interesse entre dispositivos | Proposta para ativar grupos de interesse entre dispositivos para agentes de usuário autenticados | Estamos avaliando essa proposta, mas a alta especificidade do direcionamento entre dispositivos representa preocupações significativas de privacidade, conforme discutido neste problema do GitHub. |
| (Também informado no 1º trimestre) Remarketing dinâmico | O remarketing dinâmico ainda será possível com a API Protected Audience após a descontinuação dos cookies de terceiros? | Acreditamos que esse caso de uso é possível usando a API Protected Audience, conforme explicado aqui. |
| Clique em dados relacionados | Adicionar dados relacionados a cliques a browserSignals. |
No momento, estamos pedindo esclarecimentos sobre quando o clique ocorreu para dar uma posição preliminar. |
| (Também informado no 4º trimestre de 2022) Funções definidas pelo usuário na API Protected Audience | Como as funções definidas pelo usuário (UDF) vão ser compatíveis com a API Protected Audience? São funções que podem ser programadas pelos usuários finais para estender a funcionalidade da API. | A adtech que levantou esse problema também mencionou que ainda está avaliando o que poderia fazer com a UDF. Portanto, não há feedback útil para reagir, pelo menos até a disponibilidade geral. |
| Moeda | Os valores monetários não devem ser representados usando pontos flutuantes. | Saiba mais sobre esse problema. |
| Recursos de seleção de anúncios sem DSP | Qual é o papel dos servidores de anúncios nos leilões da API Protected Audience? | Sabemos que os servidores de anúncios querem continuar oferecendo serviços de seleção de anúncios pós-lance / otimização dinâmica de criativos. No momento, estamos avaliando a análise detalhada da lacuna entre a API Protected Audience atual e essas solicitações. |
| GenerateBid | Suporte à proposta do Google Ads de retornar mais de um anúncio candidato por grupo de interesse de publicidade de generateBid e atribuir uma pontuação a esses candidatos em "scoreAd". |
Isso está sendo avaliado. Envie seu feedback. |
| Ordem de leilão | Os leilões da API Protected Audience precisam ser o último a ser executado para que possam receber entradas do resultado de todos os outros leilões? | Não há um requisito técnico para que a API Protected Audience seja executada por último. |
| Navegação não iniciada pelo usuário | Exibir a navegação iniciada por alguém que não é o usuário | Estamos analisando essa solicitação e discutindo-a aqui . Seu feedback é muito importante. |
| Armazenamento em cache | O SSP não deve criar perBuyerSignals de um determinado DSP em um cache se o estado do usuário mudar. | Entendemos que o armazenamento em cache não funciona para todos os casos de uso de indicadores por comprador e estamos avaliando outras opções. Gostaríamos de receber mais feedback do ecossistema sobre se o armazenamento em cache funcionaria para os casos de uso. |
| Relatórios de atribuição e público-alvo protegido | Como a API Attribution Reporting e a API Protected Audience podem trabalhar juntas? | No momento, as integrações estão disponíveis para a API Protected Audience nos dois modos da API Attribution Reporting (relatórios de eventos e de resumo). No dia 1º de junho, compartilhamos mais informações sobre a integração aprimorada da API Protected Audience e do Attribution Reporting. Saiba mais sobre elas aqui. |
| Endpoint do servidor | O endpoint do servidor será o servidor de agregação confiável no design final? | O endpoint do servidor é um endpoint mantido pela adtech que é independente dos servidores de agregação confiáveis usados para processar os relatórios coletados e transformados. No momento, não temos mudanças planejadas para o endpoint de relatórios. O objetivo do design atual é garantir que os próprios relatórios agregáveis (com payloads criptografados) não vazem dados entre sites. Portanto, um endpoint confiável não é necessário. Outra complicação é que diferentes adtechs provavelmente vão ter estratégias de loteamento diferentes. Envie seu feedback. |
| WebIDL | A especificação atual da API Protected Audience não é compatível com a especificação WebIDL. | Estamos avaliando esse feedback e discutindo o problema aqui. |
| Gestão de consentimento | Como a transmissão do indicador de consentimento será tratada na API Protected Audience? | As informações contextuais não estão no escopo da API Protected Audience. Estamos discutindo esse problema e gostaríamos de receber mais feedback. |
| Marketing baseado em contas | Os casos de uso de marketing baseado em contas seriam possíveis? | A API Protected Audience oferece suporte a vários casos de uso de marketing com base no público-alvo. Continuamos a entender como a API Protected Audience pode oferecer suporte a esse caso de uso específico e agradecemos o feedback sobre esse problema do ecossistema. |
| Leilão de componentes | O que os participantes do leilão de componentes pontuam? | Os leilões de componentes não avaliam os grupos de interesse diretamente, mas sim os anúncios e lances que uma DSP envia da função generateBid. A função generateBid() é executada por grupo de interesse, e o DSP retorna o seguinte ao executar generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contribuições externas | Solicitação para oferecer suporte a contribuições externas na base de código do GitHub do servidor de chave/valor. | Estamos atualizando nossos processos relevantes para oferecer suporte a contribuições externas ao código do GitHub. |
| Tamanho do grupo de interesse | Qual é o número máximo de chaves com suporte para o IG? | O limite atual é de 50 KB no tamanho de um IG, e as chaves são consideradas parte disso. Vamos adorar discutir mais sobre o limite de tamanho. |
| Agrupar chamadas | Como é possível reduzir o número de chamadas do servidor K/V? | Você pode usar os cabeçalhos HTTP Cache-Control para reduzir o número de chamadas K/V. Por exemplo, ele pode ser armazenado em cache em leilões de componentes e em espaços de anúncios em uma única página. |
| Controle de versão | Suporte para várias versões do código de adtech | Os serviços de lances e leilões vão oferecer suporte a várias versões do código de adtech. Na API Bidding and Auction, a solicitação SelectAd pode especificar a versão do código usado para a solicitação de leilão (ou seja, para lances / leilões e também para relatórios). |
| Armazenamento compartilhado | Suporte para gravação no armazenamento compartilhado no serviço de lances e leilões. | No momento, os serviços de lances e leilão não oferecem suporte ao armazenamento compartilhado, mas gostaríamos de receber mais feedback sobre por que esses casos de uso são importantes para o ecossistema. |
| Da Web para o app | Ofereça suporte ao compartilhamento de grupos de interesse entre a Web e o app. | No momento, a migração da Web para o app não está incluída no escopo da implantação da API Protected Audience no Chrome e no Android, mas queremos saber a opinião do ecossistema sobre a importância desse caso de uso. |
| K-anonimato | Como processar substitutos de k-anonimato | Estamos discutindo o problema e agradecemos mais feedback. |
Como medir anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Configurações alternativas de relatórios de eventos do VTC | Feedback sobre as configurações de relatórios de eventos de VTC alternativo | Recebemos alguns feedbacks de que as configurações atuais no nível do evento não são ideais. Por isso, pedimos feedback sobre as configurações globais ideais. Estamos abertos a mais feedback sobre esse assunto e acreditamos que nossa explicação flexível no nível do evento também ajuda a resolver esse problema. |
| Configurações flexíveis no nível do evento | Qual é o status do recurso de configurações flexíveis no nível do evento? | Compartilhamos a documentação sobre a configuração flexível no nível do evento. O recurso ainda está na fase de proposta, e estamos procurando mais feedback sobre se ele será valioso para o ecossistema. |
| Configurações flexíveis no nível do evento | Como é possível conciliar relatórios conflitantes de diferentes partes? | A maioria dos cenários de relatórios é abordada com o uso de relatórios agregados, enquanto a proposta de configuração flexível no nível do evento é especificamente para mais flexibilidade nos relatórios de eventos, que são usados com mais frequência para casos de uso de otimização. Aceitamos comentários/feedback sobre o ecossistema em relação a esse cenário. |
| Registro da fonte | E se o registro da origem acontecer depois do registro do acionador? | No momento, se um registro de origem ocorre após o registro do acionador, a origem e o acionador não podem ser atribuídos um ao outro. Parece ser um caso extremo. Agradecemos qualquer outro feedback sobre esse problema e vamos tentar resolvê-lo se for um cenário que muitas adtechs enfrentam. |
| Como trabalhar com várias agências de publicidade | Como os DSPs podem usar a API Attribution Reporting quando um anunciante trabalha com várias agências de publicidade? | A API oferece suporte a redirecionamentos e, portanto, pode ser usada mesmo quando um anunciante trabalha com várias agências de publicidade. Além disso, há algumas limitações em relação aos redirecionamentos para garantir que a API melhore a privacidade. Também identificamos uma possível solução alternativa usando a API Shared Storage para o cenário específico que a adtech apresentou. Agradecemos qualquer outro feedback sobre esse cenário e continuaremos a iterar com base nele. |
| Limites de destino | O caso de uso de anúncios com atualização automática pode ser afetado por limites de destino. | Discutimos esse problema na reunião do WICG de 1º de maio e estamos procurando feedback sobre qual seria um limite razoável. Adicionamos à Explicação dos relatórios de atribuição com relatórios no nível do evento a informação de que o navegador pode limitar o número de eTLD+1s de "destino" representados por sites de origem. Consulte Solicitação de envio. |
| Relatórios de atribuição e API Protected Audience | Como a API Attribution Reporting e a API Protected Audience podem trabalhar juntas? | No momento, as integrações estão disponíveis para a API Protected Audience nos dois modos da API Attribution Reporting (relatórios de eventos e de resumo). No dia 1º de junho, compartilhamos mais informações sobre a integração aprimorada da API Protected Audience e do Attribution Reporting. Saiba mais sobre elas aqui. |
| Configurações flexíveis no nível do evento | Compartilhe práticas recomendadas para simulação de ruído agora que os parâmetros são configuráveis. | Temos um código compartilhado no GitHub que qualquer pessoa pode usar para avaliar o ganho de informações e o impacto do ruído em qualquer configuração flexível no nível do evento que quiser testar. Queremos saber a opinião de quem testar o código e compartilhar feedback. |
| Medição de atribuição entre apps e na Web | Quando a medição de atribuição entre apps e na Web vai estar disponível? | Em 9 de maio, anunciamos um experimento para a medição de atribuição entre apps e na Web usando a API Attribution Reporting. Embora a disponibilidade geral esteja planejada para as APIs de relevância e medição no Chrome 115, a medição de atribuição entre apps e na Web não está prevista para a disponibilidade geral com o Chrome 115. |
| Eliminar duplicações de conversões | Como as soluções de medição independentes podem ser conciliadas com a ARA? | Como na prática padrão atual, os anunciantes trabalham com um provedor de medição independente terceirizado para eliminar a duplicação nos relatórios de conversão. Oferecemos recursos sobre como eliminar duplicações de conversões nos relatórios de eventos. |
| Perda de dados durante as atualizações do banco de dados dos relatórios de atribuição | Haverá perda de dados quando o Chrome atualizar o banco de dados de relatórios de atribuição, conforme anunciado? | A partir do Chrome 115 estável, vamos começar a ativar as APIs Relevance e Measurement para uma parte dos usuários do Chrome por padrão. A disponibilidade geral vai aumentar à medida que monitoramos possíveis problemas. A meta é alcançar 100% de disponibilidade em um período de semanas até o terceiro trimestre de 2023. Isso vai coincidir com o fim do teste de origem da relevância e da medição. A partir de julho, os testadores poderão se inscrever para ter acesso a essas APIs na disponibilidade geral. Isso vai permitir que você faça o teste de origem e a disponibilidade geral ao mesmo tempo. Seu token de teste de origem vai ser válido até 19 de setembro, mas recomendamos que você se inscreva nas APIs antes da expiração para fazer a transição sem problemas do teste de origem sem interromper os testes em andamento. Como mencionado neste anúncio, os dados registrados em versões mais antigas (M113 e anteriores) não serão migrados após a atualização. Portanto, pode haver perda de dados. Essa perda de dados não vai aparecer nos relatórios de depuração, e vamos tentar evitar a perda de dados de 114 para 115. |
| Faturamento | Como usar os Relatórios de atribuição para o faturamento por custo por conversão | Como mencionado neste artigo, a API Attribution Reporting pode não ser adequada para necessidades de faturamento de custo por conversão devido ao ruído adicionado aos relatórios de eventos e de resumo. Recomendamos que os participantes do ecossistema compartilhem feedback sobre o impacto em vários modelos de faturamento com a API Attribution Reporting no GitHub. |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Mudança de atraso do relatório agregável | Reações positivas à proposta de mudar o atraso do relatório agregável de [10 a 60 minutos] para [0 a 10 minutos] após o feedback do ecossistema | Ficamos felizes com a reação positiva à mudança proposta e incentivamos o ecossistema a continuar enviando feedback sobre nossas propostas. |
| Solução local | O serviço de agregação pode ser implantado em data centers locais? | Embora estejamos avaliando opções de suporte além das soluções baseadas na nuvem, não é viável oferecer suporte a TEEs locais devido às limitações de segurança locais que exigem uma avaliação demorada para o Sandbox de privacidade. Considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações locais, acreditamos que continuar a expandir e melhorar as implantações baseadas em nuvem (por exemplo, com suporte ao GCP, além da AWS) é o mais benéfico para o ecossistema. No entanto, agradecemos mais feedback sobre por que esse requisito é necessário. |
| Reprocessar relatórios para períodos diferentes | Capacidade de processar relatórios novamente para períodos diferentes | Recebemos pedidos semelhantes para dividir lotes em diferentes períodos. Uma proposta é permitir a extensão do ID compartilhado com um rótulo definido pela adtech para que os relatórios possam ser divididos em diferentes lotes. Estamos no início do processo de avaliação e vamos manter o ecossistema atualizado à medida que a proposta evoluir. |
| Implicações de privacidade do ambiente de execução confiável | Sentimento positivo em relação às implicações de privacidade dos ambientes de execução confiáveis | Ficamos felizes em saber das reações positivas do ecossistema em relação às nossas propostas e agradecemos o feedback para continuarmos iterando e desenvolvendo. |
| Termos de Serviço | Qual é o prazo para aceitar os Termos de Serviço do serviço de agregação? | Embora ainda não tenhamos especificado um prazo para aceitar os Termos e Condições, recomendamos que as empresas do ecossistema aceitem os Termos e Condições o mais rápido possível para evitar atrasos na inscrição. Recomendamos que as empresas entrem em contato se tiverem dúvidas. |
| Descoberta de chave | O recurso de descoberta de chaves permite que os testadores consultem relatórios agregados sem precisar da lista explícita de possíveis combinações de chaves para processar relatórios de resumo para atribuição em várias redes e melhorar a performance e a precisão. | No momento, estamos analisando possíveis soluções e alternativas e aceitamos mais feedback do ecossistema. |
API Private Aggregation
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Origem da denúncia | Como a origem do relatório é definida? | A origem do relatório é sempre a origem do script do autor da chamada de agregação privada. |
| Espaço de chave de 128 bits | Mais clareza sobre a limitação do espaço de chaves de 128 bits | Vamos deixar essa limitação de espaço de chaves mais clara e resolver as inconsistências nas páginas. Recomendamos o uso de estratégias de hash para permanecer nesse espaço de chaves. |
| Contribuição máxima por relatório | O limite atual de 20 contribuições por relatório é muito baixo. | Em vez de aumentar o número máximo de contribuições, podemos considerar a divisão de relatórios em vez de truncar no limite. Vamos envolver o ecossistema à medida que a proposta evoluir. |
| Relatório de alcance | Solicitação de relatórios de alcance entre várias plataformas/dispositivos. O alcance é uma métrica fundamental da publicidade de marca. Os anunciantes usam as aproximações entre plataformas/dispositivos nos relatórios de alcance e frequência para analisar as campanhas e alocar o gasto. Os modelos de alcance usam cookies de terceiros como um indicador para medir os anúncios mostrados em ambientes de terceiros. Por isso, as adtechs solicitaram uma solução alternativa quando os cookies de terceiros forem descontinuados. |
A equipe do Sandbox de privacidade está analisando recursos para oferecer suporte a metodologias de alcance em vários domínios após a descontinuação dos cookies de terceiros. Agradecemos o feedback do ecossistema. |
Limitar o rastreamento oculto
Redução do user agent/dicas de cliente HTTP do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 1º trimestre de 2023) Dicas para outros formatos | Solicitação de dicas de cliente do user agent (UA-CH) para fornecer outros formatos, como TV e RV | Ainda estamos trabalhando em algumas decisões importantes de design (se vamos fornecer um único valor, como "TV", ou uma lista de recursos de formato), mas ainda temos interesse em criar um protótipo dessa ideia. |
| proposta de orçamento de privacidade | As restrições do orçamento de privacidade podem fazer com que as solicitações do UA-CH se tornem não determinísticas quando muitas solicitações são enviadas. | No momento, não temos novas atualizações sobre a proposta do orçamento de privacidade, mas nos comprometemos a não restringir as solicitações de dicas de cliente do UA antes que os cookies de terceiros sejam descontinuados. |
| Compatibilidade do site | Os sites estão usando a marca UA-CH para impedir que determinados navegadores acessem os sites. | Há casos de uso válidos para ter uma lista de marcas, e um deles é a compatibilidade. Um UA pode ter várias marcas para contornar esses problemas. |
Proteção de IP (anteriormente Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Fraudes e abusos | Como as empresas podem configurar medidas antifraude com a Proteção de IP? | Entendemos a importância dos casos de uso de prevenção de fraudes e o possível impacto deles. Planejamos publicar mais detalhes sobre o suporte à proteção contra fraudes ainda este ano. Estamos buscando feedback do ecossistema sobre como podemos oferecer melhor suporte a casos de uso de antifraude. |
| GeoIP | Mais informações sobre o cronograma de testes e implantação do GeoIP | Recentemente, o Chrome publicou novas informações detalhando nossos planos de GeoIP. Vamos publicar mais informações sobre os cronogramas de implantação no terceiro trimestre. Inicialmente, vamos lançar a Proteção de IP como um recurso de ativação do usuário em uma pequena porcentagem do tráfego. Isso porque reconhecemos que essa proposta pode envolver algumas mudanças significativas para as empresas. Queremos dar tempo ao ecossistema para se ajustar e enviar feedback antes que o recurso seja lançado de forma mais ampla. |
| Autenticação da conta | Como funciona a autenticação da conta com o servidor proxy? | Planejamos publicar mais detalhes sobre a autenticação de contas no fim do verão, mas já compartilhamos algumas considerações iniciais. |
Mitigação de rastreio por redirecionamento
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Orientações de teste | Informações sobre como testar a mitigação de rastreio | Publicamos uma postagem do blog em maio com mais informações sobre como testar a mitigação de rastreamento de rejeições. |
| Documentação | Clareza na proposta de rastreio por redirecionamento | A proposta atual ainda está em andamento, e o Chrome continua atualizando a proposta para esclarecer e informar o ecossistema. Estamos trabalhando para fornecer mais detalhes e agradecemos qualquer outro feedback. |
| Exclusão de cookies | A mitigação de rastreamento de rejeições vai excluir todos os cookies em um domínio? | A mitigação de rastreamento de rejeições (BTM, na sigla em inglês) vai limpar todo o armazenamento e cache, conforme explicado aqui. |
| Como contornar a mitigação de rastreio por redirecionamento | A classificação do Bounce Tracker pode ser contornada com redirecionamentos com pop-ups ou novas guias. | A especificação da mitigação de rastreio por redirecionamento ainda está em desenvolvimento. Até agora, nos concentramos principalmente em redirecionamentos na mesma guia, mas planejamos trabalhar em fluxos de pop-up no futuro. Envie seu feedback. |
proposta de orçamento de privacidade
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Segmentação por proximidade | O Orçamento de privacidade pode afetar casos de uso de segmentação por proximidade. | Recebemos feedback sobre esse problema e gostaríamos de saber mais sobre os possíveis impactos do ecossistema. |
Reforçar os limites de privacidade entre sites
Conjuntos próprios
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado nos trimestres anteriores) Limite de domínio | Pedido para expandir o número de domínios associados | O Chrome está avaliando o limite numérico adequado para o subconjunto associado que vai equilibrar privacidade e utilidade para os casos de uso identificados. Desde o início, o Chrome informou que o número exato do subconjunto associado ainda não foi finalizado. |
| Caso de uso integrado | Suporte para casos de uso de embedding que exigem conjuntos próprios, CHIPs e armazenamento compartilhado | O Chrome recebeu o feedback sobre esse caso de uso, e a equipe está investigando e aceita mais feedback. |
| Gerenciamento de repositório | Informações sobre políticas para remover conjuntos de terceiros do repositório do GitHub em caso de discrepâncias ou negligência | O Chrome recebeu o feedback sobre este caso de uso. A equipe está investigando e aceita mais feedback. |
| Educação do usuário | O Chrome precisa aumentar a conscientização e o entendimento dos usuários sobre os conjuntos próprios para impulsionar a adoção. | O Chrome se comprometeu a educar os usuários sobre os conjuntos primários e publicou um artigo da Central de Ajuda (com link na interface do Chrome) sobre o assunto. O Chrome também está investindo em continuar aprendendo a educar melhor os usuários nos contextos adequados. |
| Postagem 3PCD | Os cookies de terceiros vão continuar existindo em um conjunto primário após a descontinuação dos cookies de terceiros. | Embora requestStorageAccess e requestStorageAccessFor disponibilizem cookies de terceiros novamente para casos de uso específicos e claramente definidos, eles agora exigem invocação ativa pelo site, em vez de estarem disponíveis por padrão, como no estado atual dos cookies de terceiros (no Chrome).Embora essa invocação em um único conjunto não exija a aprovação do usuário, os usuários podem impedir isso desativando esse comportamento nas configurações. Os usuários podem conferir mais informações no artigo da Central de Ajuda (link disponível na interface do Chrome). Planejamos expandir o guia para desenvolvedores à medida que o FPS aumenta para 100%. |
| Envio de conjuntos próprios | Renomeie o .well-known/first-party-set necessário para incluir uma extensão .json. |
Fizemos essa mudança para garantir o suporte a determinados planos de hospedagem na Web. |
| Registro da IANA | first_party_sets.JSON precisa ser registrado na IANA |
Estamos considerando a proposta e aceitamos mais feedback aqui. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Bloqueio de anúncios | Os frames cercados podem facilitar o bloqueio de anúncios por bloqueadores. | As extensões podem interagir com frames delimitados de forma semelhante a como elas interagiriam com iframes. O URL real para o qual o frame cercado está prestes a navegar também será visível para as extensões. Portanto, elas podem aplicar qualquer regra de correspondência de URL para bloqueio, como fariam em iframes. O simples bloqueio incondicional de todos os frames restritos pode interromper os casos de uso de frames restritos que não são anúncios. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adoção mais ampla | O Shared Storage precisa ser um padrão do setor disponível em todos os navegadores. | Agradecemos seu feedback. O Chrome continua participando ativamente dos fóruns do W3C para defender a proposta, buscar feedback e impulsionar a adoção. |
| Portas de saída | Os portões de saída do armazenamento compartilhado são muito limitados. | Estamos considerando esse feedback e agradecemos outros comentários do ecossistema sobre por que as portas de saída são muito limitadas. |
| Conformidade regulatória | Como o Armazenamento compartilhado vai lidar com a conformidade regulatória, como políticas de retenção de dados? | O Shared Storage oferece a flexibilidade necessária para implementar e personalizar a lógica de controle da duração e da expiração de dados armazenados. As adtechs podem atualizar ou limpar dados do armazenamento compartilhado com base nos carimbos de data/hora de gravação. |
| Teste A/B | Como é possível realizar testes A/B para a API Shared Storage e a API Protected Audience? | Estamos trabalhando para publicar mais orientações sobre esse assunto e esperamos compartilhar mais detalhes no futuro. |
| Limite de armazenamento compartilhado | O que vai acontecer quando o limite de armazenamento compartilhado for atingido? | Se o limite for atingido, nenhuma outra entrada será armazenada. |
| Vários acessos no mesmo carregamento de página | O que acontece quando o armazenamento compartilhado é acessado várias vezes na mesma carga de página? | A melhor maneira de fazer isso é usando a função window.sharedStorage.append(key, value). Em vez de atualizar o valor de cada anúncio, o que pode causar colisões se houver vários anúncios. A função de adição vai adicionar o novo valor ao final do valor preexistente. |
| Funcionalidade do iframe | O Shared Storage vai oferecer suporte a determinadas funcionalidades de iframe quando elas não funcionarem mais após a descontinuação dos cookies de terceiros? | Após a descontinuação dos cookies de terceiros, o armazenamento local em iframes será particionado pelo site de nível superior, mas os iframes não serão bloqueados. Os dados no armazenamento local de um iframe não podem ser replicados em vários sites de nível superior, mas o armazenamento local ainda pode ser usado no iframe. |
CHIPs
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limite de partição | 10 KiB por site particionado ainda é um valor considerável, e gostaria de reduzir esse número. | O Firefox já indicou uma posição positiva no CHIPS. Para suporte ao Webkit, recomendamos que os desenvolvedores enviem feedback diretamente à Apple sobre este problema do GitHub em relação aos casos de uso em que os cookies particionados são preferidos ao armazenamento particionado. |
| Incorporações autenticadas | Os CHIPs podem afetar o fluxo de login do SSO atual devido a diferentes particionamentos que afetam as in-line autenticadas. | Pretendemos aproveitar a API Storage Access (com solicitações do usuário) para oferecer suporte ao caso de uso de incorporações autenticadas e recentemente enviamos uma intent-to-prototype. |
| Políticas vitalícias | As políticas de validade vão se aplicar aos cookies primários? | No momento, não temos planos de impor limites de tempo de vida para cookies próprios. |
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Suporte para autorização OAuth | Alinhamento na autorização de escopos de Oauth que não são de perfil | Estamos buscando ativamente a contribuição da comunidade de identidade da Web pelo FedID CG do W3C sobre as melhores maneiras de oferecer suporte à autorização além da autenticação básica após a descontinuação de cookies de terceiros. |
| Suporte a SAML | Alinhamento dos requisitos de suporte a SAML | A equipe está buscando ativamente contribuições das comunidades de pesquisa e educação sobre as necessidades de suporte a SAML (além do suporte ao OpenID Connect) após a descontinuação dos cookies de terceiros. |
Combater spam e fraudes
API Private State Tokens (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Como explorar novos indicadores | Vários parceiros expressaram um sentimento positivo em relação à exploração de indicadores de integridade do dispositivo ou confiança do usuário facilitados pelo navegador. Geralmente, eles também têm dúvidas se os novos indicadores criados para esse fim são suficientes para manter os níveis atuais de detecção de fraude. | Estamos ansiosos para explorar novas propostas com a comunidade de segurança da Web e contra fraudes e também reconhecer e compartilhar as preocupações dela. É exatamente por isso que "combater spam e fraudes" tem sido um fluxo de trabalho principal do Sandbox de privacidade e por que continuamos priorizando o investimento na preservação da segurança da Web à medida que melhoramos a privacidade do usuário. |
| Feedback positivo sobre o PST | Vários parceiros expressaram interesse em testar ou usar PSTs para vários casos de uso de segurança da Web ou antifraude. | Ficamos felizes em saber que você apoia e tem interesse em conhecer mais soluções que utilizam PSTs. Temos recursos e exemplos de código disponíveis no site para desenvolvedores do Chrome. Agradecemos mais feedback. |
| Fraude e abuso | Orientações sobre prevenção / detecção de fraude de anúncios na medição após a descontinuação de cookies de terceiros quando os identificadores não estão mais disponíveis. | Lançamos ferramentas como os tokens de estado privado, que ajudam a recuperar parte do indicador perdido por cookies de terceiros para fins de proteção contra fraudes, mas com novos controles de privacidade. Estamos investindo ativamente em novas propostas antifraude e antiabuso para preservar os recursos com outras mudanças do Sandbox de privacidade. |
| Taxa de informações do emissor para a origem | A taxa de informações do emissor para a origem é alta o suficiente para identificar usuários únicos. | Atualizamos a especificação para deixar mais claro quais dados do usuário podem ser transmitidos usando tokens de estado particular. Por design, até seis chaves públicas podem ser usadas de uma vez, o que pode representar um "estado" para um usuário específico. Esses conjuntos de chaves só podem ser atualizados a cada 60 dias (exceto em casos raros em que uma rotação de chave de emergência é necessária), o que diminui a possibilidade de mesclar outros dados do usuário ao longo do tempo. Com qualquer nova API da Web, há um equilíbrio entre a utilidade oferecida e as novas informações do usuário. Estimamos que as PSTs atinjam o equilíbrio adequado na proteção da privacidade do usuário, permitindo os principais casos de uso antifraude afetados pela descontinuação dos cookies de terceiros. |
| Buscar integração | A integração do fetch é complicada e desnecessária. |
Há vantagens e desvantagens em usar fetch, e gostaríamos de buscar uma maior padronização no ecossistema da Web, mas achamos que ainda é muito cedo para fazer essa mudança até termos uma ideia mais clara de como será o padrão. Se e quando um padrão surgir, também vamos nos comprometer a fazer a transição responsável dos desenvolvedores da Web para esse padrão. |
| Local de armazenamento | As configurações de chaves de tokens de estado particular precisam ser armazenadas no mesmo local que o protocolo PrivacyPass. | Durante o teste do Origin, os desenvolvedores indicaram que preferem a flexibilidade de armazenar as chaves em URLs gerais em vez de um diretório .well-known. O formato de compromisso de chaves no PrivacyPass não é adequado para uma versão em que os conjuntos de chaves têm como objetivo permitir um valor de "metadados públicos" implícito. Se uma variante do PrivacyPass for padronizada com metadados públicos (como POPRF, ofuscamento RSA parcial ou conjuntos de chaves), poderemos migrar para uma versão futura do PST para oferecer suporte a isso. |
| Implementação de cabeçalho da API | Perguntas sobre a implementação do cabeçalho da API | À medida que a API for padronizada e o uso do ecossistema dela for amadurecendo, poderemos oferecer suporte à versão padrão sem cabeçalho da API e, eventualmente, descontinuar a versão com cabeçalho se o uso for baixo o suficiente ou se houver ferramentas/suporte suficientes para os desenvolvedores para formas padrão de correlacionar solicitações de emissão/resgate com outros dados. Discutimos o problema aqui. |
| Registro | É prático fazer com que os emissores se registrem com os fornecedores de navegadores? | Atualizamos a especificação para descrever o processo de registro do emissor para tokens de estado particular. Embora use um processo próprio, ele é semelhante aos planos de inscrição para o restante do trabalho do Sandbox de privacidade, em que pedimos aos emissores que façam uma declaração pública sobre como pretendem usar os PSTs e reconheçam as restrições técnicas que protegem a privacidade do usuário. |