Relatório trimestral do segundo trimestre de 2023 com um resumo do feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.
Como parte 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 do desenvolvimento e testes, as perguntas e o feedback foram recebidos principalmente em relação às APIs Topics, Protected Audience 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 |
|---|---|---|
| Governança de dados e conformidade regulatória | Orientações do ecossistema sobre o uso do Sandbox de privacidade em conformidade com os requisitos regulamentares. | Como acontece com qualquer tecnologia nova, cada empresa é responsável por garantir que o uso do Sandbox de privacidade esteja em conformidade com a lei. O Google não pode oferecer orientação jurídica a outras pessoas. No entanto, sabemos que essa é uma área de interesse fundamental para o ecossistema. Para cada API, publicamos uma extensa documentação técnica, que fornece a base para as avaliações legais necessárias. Além disso, estamos trabalhando para disponibilizar mais materiais em apoio aos esforços das empresas no cumprimento dos requisitos regulatórios. |
| Proposta de teste quantitativo da CMA | Mais informações sobre a proposta de teste quantitativo da CMA | Estamos trabalhando com a CMA para criar experimentos que mostrem 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 de alto nível sobre o que esperar durante o período de testes e, em junho, uma orientação detalhada. Recomendamos que qualquer pergunta ou feedback sobre a proposta de teste quantitativo da CMA seja compartilhado diretamente com ela. |
| Modos de teste facilitados do Chrome | Mais informações e esclarecimentos sobre os calendários de testes | Publicamos uma postagem do blog em 18 de maio com mais informações sobre os dois modos de testes facilitados do Chrome. Esses detalhes não são definitivos. Vamos publicar mais orientações de implementação conforme avançarmos no terceiro trimestre de 2023. |
| Armazenamento particionado | O armazenamento particionado será usado durante os testes facilitados pelo Chrome? | O particionamento de armazenamento vai ser enviado a todos os usuários antes do experimento de descontinuação dos cookies de terceiros. Portanto, ela vai ser ativada para todos os grupos do experimento. Os sites terão a opção de ativar um teste de descontinuação para recuperar o armazenamento não particionado durante esse período. |
| Suporte à produção | Qual é o processo em vigor para que o Chrome dê suporte a problemas técnicos e encaminhamentos do Sandbox de privacidade que afetam o ecossistema? | O Google oferece vários canais para as adtechs informarem problemas e permitirem os encaminhamentos necessários. Consulte nossa postagem para desenvolvedores se quiser mais informações sobre os fóruns públicos e privados para feedback e encaminhamento. |
| Cronograma de inscrição | O prazo atual para inscrição é muito curto | Ainda estamos avaliando o prazo de aplicação e gostaríamos de saber qual é o cronograma mais adequado para o ecossistema. |
| Número D-U-N-S | Mais informações sobre o requisito do número D-U-N-S para inscrição e atestado | Os participantes podem encontrar os requisitos para obter um número D-U-N-S no site da Dun & Bradstreet. Os requisitos variam dependendo do mercado, por isso, os participantes devem verificar o site do mercado específico em que estão interessados. No entanto, em geral, os participantes precisam fornecer informações básicas sobre a empresa, como nome, endereço e dados de contato do proprietário ou gerente. Também pode ser solicitado que os participantes forneçam informações financeiras, como a receita anual da empresa. Quando a inscrição for concluída, a D&B vai analisá-la e emitir um número D-U-N-S se a inscrição for aprovada. |
| Transição do teste de origem para disponibilidade geral | A transição do teste de origem para a disponibilidade geral vai afetar os testadores atuais? | A partir de julho, os testadores vão poder acessar as APIs de relevância e medição em disponibilidade geral. Isso fornecerá 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 entrevistados que estimassem as taxas de sincronização e a receita das suas empresas. A metodologia dos participantes para responder às suas perguntas individuais dependia deles. |
| Valores de parâmetros | Como são determinados os valores de parâmetros, como nível de ruído, limites de anonimato e orçamento de privacidade? | Esta explicação do GitHub (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 qualquer feedback sobre esse assunto é bem-vindo. |
Mostre 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 sobre a preservação da privacidade | Estamos envolvidos ativamente com a comunidade de pesquisa, apresentando nossa pesquisa sobre as propriedades de privacidade da API Topics em documentos, relatórios e apresentações de workshops. Ficamos felizes em ver mais membros externos da comunidade de pesquisa interagindo com essa área. A API Topics protege os usuários contra o rastreamento geral na Web porque dificulta o rastreamento em grande escala. Os artigos mostram que estamos fazendo isso com a API Topics. Ele é mais privado do que cookies de terceiros e protege os usuários enquanto apoiam os sites que eles gostam de visitar. |
| A taxonomia dos temas não é granular o suficiente | A taxonomia de tópicos amplos não inclui tópicos mais granulares, incluindo tópicos específicos da região. | Em resposta ao feedback anterior do ecossistema, publicamos uma postagem no blog em 15 de junho que detalha uma nova taxonomia atualizada que incorpora várias melhorias após o feedback do ecossistema. Como parte do nosso trabalho na taxonomia revisada, trabalhamos com várias empresas em todo o ecossistema, como a Raptive (antiga CafeMedia) e a Criteo. A taxonomia atualizada remove categorias consideradas menos úteis, em favor das que melhor correspondem aos interesses dos anunciantes, mantendo nosso compromisso de excluir tópicos potencialmente sensíveis. Incentivamos o ecossistema a revisar a taxonomia mais recente e enviar feedback sobre as mudanças. |
| Processo de atualização de taxonomia e classificador | Mais informações sobre a cadência de lançamento da taxonomia e do classificador da API Topics e como as empresas podem se preparar para essas atualizações. | Conforme explicamos em uma postagem do blog recente, esperamos que a taxonomia evolua com o tempo e que, para a governança, faça a transição para uma parte externa que represente as partes interessadas de todo o setor. Também compartilhamos o plano de expansão no grupo topics-announce. |
| Impacto nos indicadores próprios | O aumento no número de temas 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 1o trimestre de 2023, a CMA comentou: "Entendemos que o Google está discutindo a nova taxonomia proposta com vários participantes do mercado em toda a cadeia de suprimentos de adtech. 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 é de que maior utilidade é melhor para a concorrência em geral, em especial para a capacidade de editores menores continuarem monetizando seu inventário após a descontinuação dos cookies de terceiros. Nossa visão está alinhada a esse comentário da 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 agentes do ecossistema. | Nossa resposta não mudou em relação aos trimestres anteriores: "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 e considerar o impacto na concorrência na publicidade digital, além de 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. O feedback é fundamental neste sentido, especialmente feedbacks específicos e acionáveis que podem 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." |
| Tópicos 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 fará com que os tópicos descendentes nunca cheguem ao topo? | No momento, o Chrome está avaliando outras metodologias de classificação e explorando outros sinais que podem melhorar a classificação. Vamos comunicar nossos planos revisados ao ecossistema no futuro. |
| Sensibilidade | O objetivo da API Topics precisa ser garantir que as informações do usuário recebidas ou derivadas dela sejam menos sensíveis do que o que poderia ser derivado com os métodos de acompanhamento atuais. | Acreditamos que a API Topics é significativamente mais particular do que as tecnologias atuais, limita significativamente a reidentificação de usuários e foi criada 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 em relação à privacidade do usuário e temos o compromisso de continuar melhorando a API. |
| Estrutura de taxonomia | Adicionar ID, controle de versões e outras estruturas de metadados à taxonomia de tópicos | No momento, incluímos o ID da taxonomia na resposta da API. À medida que avançamos para a governança de longo prazo, faz sentido analisar o objeto da API Topics e incluir mais metadados no controle de versões, se necessário. |
| Controle do editor | Os editores precisam decidir em que tópicos os sites devem ser classificados. | A classificação incorreta de sites pode tornar o indicador de tópicos um pouco menos útil como um indicador no geral, mas os sites específicos classificados incorretamente não são nem mais nem menos prejudicados do que qualquer outro site. Isso ocorre porque as informações contextuais de um site sempre estarão disponíveis para leilões no site, o que forneceria informações comparáveis ao tópico correto, mesmo em caso de classificação incorreta. Gostaríamos de receber feedback sobre esse assunto aqui. Permitir que os editores controlem a classificação tem riscos. Os sites podem classificá-los incorretamente de forma intencional, reduzindo a utilidade para todos ou codificar significados sensíveis em tópicos menos comuns, prejudicando a privacidade do usuário. |
| Extensões do Google Chrome | Permitir que as extensões do Chrome gerenciem e filtrem temas da mesma forma que as extensões de gerenciamento de cookies | Isso já deve ser possível, conforme discutido no GitHub, mas aceitamos outros feedbacks do ecossistema. |
| Transição para disponibilidade geral | Haverá algum impacto na API Topics ao fazer a transição do teste de origem para a disponibilidade geral? | Os dados dos usuários que estiverem passando do teste de origem para a disponibilidade geral não vão ser perdidos. |
| Privacidade | Os nomes de host podem conter informações particulares que podem ser reveladas pela API Topics | Temos uma série de mitigações para garantir a privacidade, conforme descrito aqui. |
| Fraude e abuso | Como evitar a manipulação de Topics por visitas fraudulentas | As mitigações são explicadas aqui. |
| Classificador de temas | Os sites podem pedir para mudar a classificação dos temas? | Queremos saber a opinião do ecossistema sobre esse tema e aguardamos seu feedback. |
| Sites de provedores da API Topics | Designe determinados sites que hospedam conteúdo para muitos temas como "Sites de provedores de temas especiais" e treine classificadores com base nas tags fornecidas nas páginas da Web. | Estamos discutindo a proposta aqui e agradecemos seu feedback. |
API Protected Audience (antiga FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Modelagem de tráfego | 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. |
| Como testar o volume | É difícil testar a API Protected Audience, porque as SSPs e as DSPs têm dificuldade para conseguir grandes volumes de tráfego. | Estamos sempre envolvendo os parceiros de SSP e DSP para adotar e testar os públicos-alvo protegidos. A disponibilidade geral começou, e temos certeza de que a porcentagem de tráfego com a PA ativada tornará o teste mais aceitável para os parceiros. |
| Complexidade | A implementação das soluções da Protected Audience exige esforço e custos significativos. | Reconhecemos que é difícil adotar novas tecnologias, incluindo o Sandbox de privacidade. A equipe do Sandbox de privacidade trabalha em estreita colaboração com várias partes interessadas para instruir e apoiar os esforços delas, além de avaliar continuamente outros aceleradores para apoiar a adoção do ecossistema. |
| Ambientes de execução confiáveis | Suporte a ambientes de execução confiáveis (TEE) em ambientes de nuvem não públicos | Estamos estudando opções de suporte além das soluções baseadas na nuvem, mas, no momento, não é viável oferecer suporte aos TEEs locais devido às limitações de segurança locais que exigiriam uma avaliação demorada do Sandbox de privacidade. Considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações no local, acreditamos que continuar a expandir e melhorar as implantações baseadas na nuvem (por exemplo, oferecer suporte ao GCP além da AWS) é o mais benéfico para o ecossistema. No entanto, gostaríamos de receber mais feedback sobre por que esse requisito é necessário. |
| Estrutura de custos | A proposta de serviços de lances e leilões aumentará o custo e a complexidade das adtechs em comparação com os modelos do lado do cliente. | No momento, estamos desenvolvendo um guia para estimar os custos relacionados aos fluxos de trabalho de lances e leilões no servidor de lances e leilões. Ele tem relação com o uso das tecnologias de publicidade e atende a uma das metas dos nossos designs. |
| Linhas do tempo 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 restrição que vamos lançar em breve. |
| Restrições do runAdAuction | O Chrome pode restringir as chamadas runAdAuction para que só possam ser chamadas na página superior? |
Embora nosso design ofereça suporte total a runAdAuction para poder ser chamado na página superior, acreditamos que seria mais prejudicial para editores restringi-lo apenas do domínio principal.O ecossistema precisa informar que o Sandbox de privacidade precisa minimizar o fardo sobre os editores e anunciantes. Esse feedback está alinhado com o princípio geral de desenvolvimento da Web de que os proprietários de sites podem usar ferramentas de terceiros para gerenciar os 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 as necessidades deles. |
| Suporte à 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 Sandbox de privacidade tem como objetivo desenvolver tecnologias que preservam 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 conhecer soluções do setor. Não planejamos criar nenhuma implementação específica, já que nossa principal missão é desenvolver tecnologias para a plataforma, não ditar estratégias para usá-las. Nossas tecnologias vão ajudar as empresas de adtech a atender melhor os clientes com as proteções de privacidade adequadas para os consumidores. |
| Leilões com vários vendedores | O Chrome forçará o compartilhamento de um vencedor "contextual" com leilões de componentes? | A API Protected Audience foi projetada para oferecer às partes que iniciam o leilão de vários vendedores as informações para o leilão do componente. Observação: apenas antes de iniciar o leilão. Portanto, não há como o navegador diferenciar se uma informação é válida para o contexto. Por isso, não é possível aplicar o bloqueio nem exigir determinadas informações. |
| Preferência do usuário para o acompanhamento de consentimento | Adtech perguntando à PA como implementar corretamente o rastreamento de consentimento do usuário | Nossa resposta inclui o que dissemos no 1o trimestre: "Para anúncios específicos, a adtech relevante é a melhor parte para oferecer controles sobre quais criativos são mostrados ou como são selecionados." Discutimos vários cenários relacionados a esse problema durante a reunião de maio WICG Protected Audience, e convidamos outros feedbacks e discussões sobre esse assunto. |
| Públicos-alvo personalizados | A API Protected Audience vai oferecer suporte aos casos de uso das SSPs relacionadas à criação de públicos-alvo personalizados? | Com a API Protected Audience, as SSPs e outros provedores de adtech podem ter e gerenciar públicos-alvo personalizados. Outras orientações sobre como uma SSP pode se integrar à API PA estão sendo desenvolvidas e vão ser disponibilizadas para SSPs e outros provedores de tecnologia de anúncio apoiarem os esforços de integração. |
| Formatos | Os vídeos são compatíveis com a API Protected Audience? | Os anúncios em vídeo são exibidos de duas maneiras: como XML VAST ou HTML (um anúncio out-stream que também pode carregar XML VAST em um player de vídeo). Os compradores podem retornar qualquer um dos formatos por meio de um renderURL. A especificação VAST foi atualizada recentemente para ser compatível com a API Attribution Reporting. Os sites que veiculam anúncios em vídeo precisam se preparar para a maneira como os anúncios são veiculados pela API Protected Audience. Isso significa que as tags de posicionamento podem transmitir o URL de um iframe de público-alvo protegido para um player de vídeo. No caso do Fenced Frames, vamos trabalhar para atender às necessidades de vídeo antes do requisito de usar esse recurso, que até 2026. |
| Ritmo | Como o caso de uso do "Pacing" funciona com a API Protected Audience? | Seu feedback é muito importante para nossa equipe! Temos interesse em ver mais instâncias dessa solicitação com mais detalhes vindos de mais parceiros de SSP, já que, até o momento, essa tem sido uma preocupação geral de DSP. |
| Frequência de atualização | A frequência das chamadas de dailyUpdate (até 1 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 que são atualizados em diferentes cadências, como as 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 recursos para os editores informarem às SSPs sobre determinados controles que podem ser estabelecidos como parte da configuração do leilão, pré-lance (ou seja, listas de bloqueio baseadas em rótulos associados a anúncios). Gostaríamos de receber seu feedback sobre qualquer funcionalidade adicional que o ecossistema possa precisar. |
| Depuração | Quando a funcionalidade do forDebuggingOnly vai ser removida? |
Planejamos desativar o forDebuggingOnly para eventos de perda com a descontinuação dos cookies de terceiros. Planejamos desativar o forDebuggingOnly para os eventos vencedores em 2026 no mínimo. |
| Grupos de interesse em dispositivos diferentes | Proposta de ativação de grupos de interesse em dispositivos diferentes para user agents autenticados | Estamos avaliando essa proposta, mas a alta especificidade da segmentação entre dispositivos gera preocupações significativas de privacidade, como discutido neste problema do GitHub. |
| (Também informado no 1o 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 Protected Audience, como explicado aqui. |
| Clique nos dados relacionados | Adicionar dados relacionados a cliques a browserSignals. |
No momento, estamos pedindo esclarecimentos sobre quando o clique deu uma posição preliminar. |
| Funções definidas pelo usuário na Protected Audience (também informada no 4o trimestre de 2022) | Como as funções definidas pelo usuário (UDF) serão compatíveis com a API Protected Audience? São funções que podem ser programadas pelos usuários finais para ampliar a funcionalidade da API. | A adtech que relatou esse problema também mencionou que ainda está avaliando o que é possível fazer com o UDF, então não há feedback a ser transformado em ação até o momento de disponibilidade geral. |
| Moeda | Os valores de moeda não devem ser representados por pontos flutuantes. | Abordamos esse problema em detalhes aqui. |
| Recursos de seleção de anúncios não DSP | Qual o papel dos servidores de anúncios nos leilões da API Protect Audience? | Estamos cientes das solicitações para que os servidores de anúncios continuem oferecendo serviços de seleção de anúncios pós-lance / otimização de criativos dinâmicos. No momento, estamos avaliando a análise de lacunas detalhada entre a API Protected Audience atual e essas solicitações. |
| GenerateBid | Suporte à proposta do Google Ads para retornar mais de um anúncio candidato por grupo de interesse de anúncio de generateBid e atribuir uma pontuação a esses candidatos em "scoreAd". |
Isso está em avaliação. Gostaríamos de receber mais feedback. |
| Ordem de leilão | Os leilões da API Protected Audience precisam ser os últimos a serem executados para receber informações do resultado de todos os outros leilões? | Não há requisito técnico para que a API Protected Audience seja executada por último. |
| Navegação não iniciada pelo usuário | Expor a navegação não iniciada pelo usuário | Estamos analisando e discutindo a solicitação aqui . Seu feedback é muito importante. |
| Armazenamento em cache | A SSP não deve criar um determinado perBuyerSignals de um determinado DSP com base em um cache se o estado do usuário mudar. | Sabemos que o armazenamento em cache não funciona em todos os casos de uso para indicadores do tipo "Por comprador" e estamos avaliando outras opções. Agradecemos qualquer feedback adicional do ecossistema sobre se o armazenamento em cache funcionaria para os casos de uso dele. |
| API Attribution Reporting e Protected Audience | Como as APIs Attribution Reporting e Protected Audience funcionam juntas? | No momento, as integrações estão disponíveis para a API Protected Audience nos dois modos da API Attribution Reporting (relatórios no nível do evento e de resumo). Compartilhamos mais informações sobre a integração aprimorada da API Protected Audience e da API Attribution Reporting em 1o de junho. Clique aqui para saber mais sobre isso. |
| Endpoint do servidor | O endpoint do servidor será o servidor de agregação confiável no design final? | O endpoint do servidor é mantido pela adtech e é independente dos servidores de agregação confiáveis usados para processar os relatórios coletados e transformados. Não há mudanças planejadas para o endpoint de relatórios no momento. O design atual visa garantir que os próprios relatórios agregáveis (com payloads criptografados) não vazem dados entre sites. Portanto, não é necessário usar um endpoint confiável. Outra complicação é que diferentes adtechs provavelmente vão ter diferentes estratégias de loteamento desejadas. Gostaríamos de receber mais feedback. |
| WebIDL | A especificação atual da API Protected Audience não é compatível com a especificação WebIDL. | Estamos avaliando esse feedback e discutimos o problema aqui. |
| Gerenciamento de consentimento | Como a transmissão do indicador de consentimento será processada na API Protected Audience? | As informações contextuais não estão no escopo da API Protected Audience. Estamos discutindo esse problema e agradecemos seu feedback. |
| Marketing baseado em contas | Existem casos de uso de marketing baseado em contas? | A API Protected Audience oferece suporte a vários casos de uso de marketing baseados em público-alvo. Continuamos entendendo como a API Protected Audience pode oferecer o melhor suporte a esse caso de uso específico e recebemos mais feedback do ecossistema sobre esse problema. |
| Leilão de componentes | Qual é a pontuação dos participantes do leilão de componentes? | Os leilões de componentes não pontuam diretamente os grupos de interesse. Em vez disso, eles pontuam os anúncios e lances que uma DSP envia a partir da função generateBid. A função generateBid() é executada por grupo de interesse, e a 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 de suporte a contribuições externas na base de código do servidor de chave-valor do GitHub. | 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 que o IG aceita? | O limite atual é de 50 KB ao tamanho de um IG, e as chaves são incluídas nesse limite. Agradecemos outras conversas sobre o limite de tamanho. |
| Agrupar chamadas | Como o número de chamadas de servidor K/V pode ser reduzido? | É possível usar cabeçalhos de controle de cache HTTP (link em inglês) para reduzir o número de chamadas K/V. Por exemplo, ele poderia ser armazenado em cache em leilões de componentes e também em espaços de anúncios de uma única página. |
| Controle de versão | Suporte a várias versões do código de adtech | Os serviços de lances e leilões serão compatíveis com 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ão e também na geração de relatórios). |
| Armazenamento compartilhado | Oferecer suporte à gravação no Armazenamento compartilhado no Serviço de lances e leilões. | Atualmente, os serviços de lances e leilões não são compatíveis com o armazenamento compartilhado, mas queremos receber mais feedback sobre a importância desses casos de uso para o ecossistema. |
| Web para app | Suporte ao compartilhamento de grupos de interesse da Web para o app. | No momento, a abordagem da Web para app não está incluída na implantação da API Protected Audience no Chrome e no Android, mas queremos saber do ecossistema sobre a importância desse caso de uso. |
| K-Anonimato | Como lidar com substitutos do K-anonimato | Estamos discutindo o problema e agradecemos seu feedback. |
Medir os anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Configurações alternativas de relatório no nível do evento de VTC | Feedback sobre as configurações alternativas do relatório de eventos de conversão de visualização (VTC, na sigla em inglês) | Recebemos feedback informando que as configurações atuais de evento não são ideais e pedimos feedback sobre as configurações globais ideais. Estamos abertos a mais feedback sobre isso e acreditamos que nossa explicação flexível no nível do evento também ajuda a resolver isso. |
| 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 queremos receber mais feedback sobre a relevância dele para o ecossistema. |
| Configurações flexíveis no nível do evento | Como é possível reconciliar relatórios conflitantes de diferentes partes? | A maioria dos cenários de geração de relatórios é tratada com o uso de relatórios agregados, enquanto a proposta de configuração flexível no nível do evento é especificamente para dar mais flexibilidade aos relatórios a nível de evento, que são mais frequentemente usados para casos de uso de otimização. Comentários/feedback adicionais sobre o ecossistema são bem-vindos sobre esse cenário. |
| Registro da fonte | E se o registro da fonte acontecer após o registro do acionador? | Atualmente, se uma fonte for registrada após o registro do acionador, ela e o acionador não serão atribuídos um ao outro. Este parece ser um caso extremo. Agradecemos qualquer feedback adicional sobre esse problema e tentaremos resolvê-lo se for um cenário que muitas adtechs estejam enfrentando. |
| Trabalhar com várias agências de publicidade | Como as DSPs podem usar a API Attribution Reporting quando um anunciante trabalha com várias agências de publicidade? | A API suporta redirecionamentos e, portanto, pode ser usada mesmo quando um anunciante está trabalhando com várias agências de publicidade. Além disso, existem algumas limitações em relação aos redirecionamentos para garantir que a API esteja melhorando a privacidade. Também identificamos uma possível solução alternativa usando a API Shared Storage para o cenário específico informado pela adtech. Gostaríamos de receber qualquer feedback adicional sobre esse cenário e continuaremos a trabalhar com base nesse feedback. |
| Limites de destino | O caso de uso de anúncios com atualização automática pode ser afetado pela existência de limites de destino. | Discutimos esse problema na reunião WICG do dia 1o de maio e queremos receber feedback sobre qual seria um limite razoável. Adicionamos à explicação sobre Relatórios de atribuição com relatórios a nível de evento informando que o navegador pode limitar o número de eTLD+1s de "destino" representados pelos sites de origem. Consulte Solicitação de envio. |
| API Attribution Reporting e Protected Audience | Como as APIs Attribution Reporting e Protected Audience funcionam juntas? | No momento, as integrações estão disponíveis para a API Protected Audience nos dois modos da API Attribution Reporting (relatórios no nível do evento e de resumo). Compartilhamos mais informações sobre a integração aprimorada da API Protected Audience e da API Attribution Reporting em 1o de junho. Clique aqui para saber mais sobre isso. |
| Configurações flexíveis no nível do evento | Compartilhe as práticas recomendadas para a simulação de ruído agora que os parâmetros são configuráveis. | Temos códigos compartilhados no GitHub (link em inglês) 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 queira testar. Temos interesse em receber feedback de qualquer pessoa que decida testar com o código e queira compartilhar seu 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 de medição de atribuição entre apps e na Web com 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á planejada para atingir a disponibilidade geral com o Chrome 115. |
| Elimine a duplicação de conversões | Como as soluções de métricas independentes podem ser reconciliadas com a ARA? | Como na prática padrão atual, os anunciantes trabalhariam com um provedor de medição independente terceirizado para eliminar a duplicação dos relatórios de conversão. Oferecemos recursos sobre como eliminar a duplicação de conversões em relatórios de evento. |
| Perda de dados durante atualizações do banco de dados do Attribution Reporting | Haverá perda de dados quando o Chrome atualizar o banco de dados da API Attribution Reporting conforme anunciado? | A partir do Chrome Stable 115, vamos ativar as APIs Relevância e Measurement para uma parte dos usuários do Chrome por padrão. Essa disponibilidade geral vai aumentar à medida que monitorarmos possíveis problemas. A meta é chegar a 100% de disponibilidade em algumas semanas, até o terceiro trimestre de 2023. Isso coincidirá com o fim do teste de origem de Relevância e medição. A partir de julho, os testadores poderão se inscrever para ter acesso a essas APIs em disponibilidade geral. Isso fornecerá uma sobreposição entre a disponibilidade do teste de origem e a disponibilidade geral por meio da inscrição. 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 sair do teste sem interromper os testes em andamento. Como mencionado neste aviso, os dados registrados das versões mais antigas (M113 e anteriores) não vão ser migrados após a atualização, então 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 a API Attribution Reporting para faturamento de custo por conversão | Conforme indicado neste artigo, a API Attribution Reporting talvez não seja adequada para o faturamento de custo por conversão devido ao ruído adicionado aos relatórios de eventos e de resumo. Incentivamos os participantes do ecossistema a compartilhar feedback sobre o impacto da API Attribution Reporting no GitHub em vários modelos de faturamento. |
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 | Estamos felizes em ver a reação positiva à mudança proposta e encorajamos o ecossistema a continuar a dar feedback sobre nossas propostas. |
| Solução no local | O serviço de agregação pode ser implantado em data centers locais? | Estamos estudando opções de suporte além das soluções baseadas na nuvem, mas, no momento, não é viável oferecer suporte aos TEEs locais devido às limitações de segurança locais que exigiriam uma avaliação demorada do Sandbox de privacidade. Considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações no local, acreditamos que continuar a expandir e melhorar as implantações baseadas na nuvem (por exemplo, oferecer suporte ao GCP além da AWS) é o mais benéfico para o ecossistema. No entanto, gostaríamos de receber mais feedback sobre por que esse requisito é necessário. |
| Reprocessar relatórios para períodos diferentes | Capacidade de reprocessar relatórios para diferentes períodos | Recebemos solicitações 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 sejam divididos em lotes diferentes. Estamos no início do processo de avaliação e manteremos o ecossistema atualizado à medida que a proposta evolui. |
| 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 | Estamos felizes em receber as reações positivas do ecossistema em relação às nossas propostas e agradecemos seu feedback adicional à medida que continuamos a iterar e desenvolver. |
| Termos de Serviço | Qual é o prazo para aceitar os Termos de Serviço do serviço de agregação? | Ainda não especificamos um prazo para a aceitação dos Termos e Condições, mas incentivamos as empresas do ecossistema a aceitar os Termos e Condições assim que possível para evitar atrasos nas inscrições. Recomendamos que as empresas entrem em contato se tiverem alguma dúvida. |
| Descoberta principal | O recurso de descoberta de chaves vai permitir que os testadores consultem relatórios agregados sem precisar da lista explícita de possíveis combinações de teclas, a fim de processar relatórios de resumo para atribuição em várias redes com o objetivo de melhorar o desempenho e a precisão. | No momento, estamos analisando possíveis soluções e soluções alternativas e agradecemos seu feedback adicional do ecossistema. |
API Private agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Origem do relatório | Como a origem do relatório é definida? | A origem do relatório é sempre a origem do script do autor da chamada da agregação particular. |
| Espaço de tecla de 128 bits | Clareza sobre a limitação de espaço para chaves de 128 bits | Deixaremos essa limitação mais clara e resolveremos as inconsistências entre as páginas. Recomendamos o uso de estratégias de hash para ficar nesse keyspace. |
| 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 dividir os relatórios em vez de truncar com base no limite. Vamos interagir com o ecossistema à medida que a proposta evolui. |
| Relatórios de alcance | Solicitação de relatórios de alcance entre plataformas e dispositivos. O alcance é uma métrica fundamental da publicidade de marca. Os anunciantes usam aproximações multiplataforma e entre dispositivos para gerar relatórios de alcance e frequência para analisar as campanhas e alocar gastos. Os modelos de alcance usam cookies de terceiros como indicadores para medir os anúncios mostrados em ambientes de terceiros. Por isso, as adtechs solicitaram uma solução alternativa quando os cookies de terceiros foram descontinuados. |
A equipe do Sandbox de privacidade está explorando recursos que oferecem suporte às metodologias de alcance entre domínios após a descontinuação dos cookies de terceiros. Seu feedback é bem-vindo do ecossistema. |
Limitar o rastreamento verso
Redução de user agent/dicas de cliente do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 1o trimestre de 2023) Dicas sobre outros formatos | Solicite dicas de cliente do user agent (UA-CH) para fornecer formatos adicionais, 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 permanecemos interessados na prototipagem dessa ideia. |
| Orçamento de privacidade | As restrições de orçamento de privacidade podem fazer com que as solicitações de UA-CH não sejam deterministas quando muitas solicitações forem enviadas. | Não temos novas atualizações sobre a proposta de Orçamento de privacidade no momento, mas nos comprometemos a não restringir as solicitações de dicas de cliente do UA antes que os cookies de terceiros fossem descontinuados. |
| Compatibilidade de sites | Os sites estão usando a marca UA-CH para restringir o acesso de determinados navegadores a sites. | Existem casos de uso válidos para ter uma lista de marcas, e um deles é precisamente a compatibilidade. Um UA pode ter várias marcas para contornar esses problemas. |
Proteção de IP (antigo Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Fraudes e abusos | Como as empresas podem estabelecer medidas antifraude com a Proteção de IP? | Entendemos a importância dos casos de uso antifraude e o possível impacto deles. Planejamos publicar mais detalhes sobre o apoio à combate à fraude ainda neste verão. Queremos receber feedback do ecossistema sobre como melhorar o suporte a casos de uso 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 GeoIP. Planejamos publicar mais informações sobre os cronogramas de implantação no terceiro trimestre. Esperamos lançar a Proteção de IP como um recurso de ativação dos usuários em uma pequena porcentagem do tráfego inicialmente. O motivo é que reconhecemos que a proposta pode envolver mudanças significativas para as empresas e queremos dar tempo ao ecossistema para se ajustar e enviar feedback antes que o recurso seja lançado para todos. |
| Autenticação da conta | Como funciona exatamente a autenticação de conta com o servidor proxy? | Planejamos publicar mais detalhes sobre a autenticação de conta ainda neste semestre, embora já tenhamos compartilhado algumas considerações iniciais. |
Mitigação de rastreio por redirecionamento
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Orientações sobre testes | Informações sobre como testar a mitigação de rastreio por redirecionamento | Publicamos uma postagem do blog em maio com mais informações sobre como testar a Mitigação de rastreio por redirecionamento. |
| Documentação | Clareza na proposta de rastreamento de rejeição | A proposta atual está em fase de desenvolvimento, e o Chrome está sempre atualizando a proposta para oferecer clareza e informações ao ecossistema. Estamos trabalhando para fornecer mais detalhes e agradecemos seu feedback. |
| Exclusão de cookies | A Mitigação de rastreio por redirecionamento exclui todos os cookies de um domínio? | A mitigação de rastreio por redirecionamento (BTM, na sigla em inglês) limpa todo o armazenamento e o cache, conforme explicado aqui. |
| Burlar a mitigação de rastreio por redirecionamento | A classificação do rastreador de rejeição pode ser ignorada com redirecionamentos em pop-ups ou novas guias. | A especificação 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. Gostaríamos de receber mais feedback. |
Orçamento de privacidade
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Segmentação por proximidade | O orçamento de privacidade pode afetar os casos de uso da segmentação por proximidade. | Recebemos feedback sobre esse assunto e queremos saber mais sobre os possíveis impactos do ecossistema. |
Fortaleça os limites de privacidade entre sites
Conjuntos primários
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limite de domínio (informado também nos trimestres anteriores) | Solicitação 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 a privacidade e a utilidade para os casos de uso identificados. Desde o início, o Chrome compartilhou que o número exato do subconjunto associado ainda não havia sido definido. |
| Caso de uso incorporado | Suporte para casos de uso incorporados que exigem conjuntos primários, CHIPs e armazenamento compartilhado | O Chrome recebeu o feedback sobre esse caso de uso. A equipe está investigando e quer receber mais feedback. |
| Gerenciamento de repositórios | Informações sobre políticas para remover conjuntos primários do repositório do GitHub em caso de discrepâncias ou negligência | O Chrome recebeu o feedback sobre este caso de uso. Nossa equipe está investigando e aceita receber mais feedback. |
| Formação do usuário | O Chrome precisa aumentar o reconhecimento do usuário e a compreensão dos conjuntos primários para impulsionar a adoção. | O Chrome tem o compromisso de educar os usuários sobre os conjuntos primários e publicou um artigo da Central de Ajuda (link na interface do Chrome) sobre esse assunto. O Chrome também está focado em continuar aprendendo a melhor informar os usuários nos contextos apropriados. |
| Após 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 realmente disponibilizem cookies de terceiros novamente para casos de uso específicos e claramente definidos, eles agora exigem uma invocação ativa pelo site, em vez de estarem disponíveis por padrão, como acontece com o 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, é possível impedir isso desativando esse comportamento nas configurações. Mais informações estão disponíveis para os usuários no artigo da Central de Ajuda (link na interface do Chrome). Planejamos ampliar o guia para desenvolvedores atual à medida que o QPS aumentar para 100%. |
| Envio de conjuntos primários | 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 IANA | O first_party_sets.JSON precisa estar registrado na IANA |
Estamos analisando a proposta e queremos receber feedback adicional. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Bloqueio de anúncios | Com o Fenced Frames, fica mais fácil para os bloqueadores de anúncios bloquearem anúncios. | As extensões podem interagir com frames delimitados de forma semelhante a como interagiriam com iframes. O URL real ao qual o frame isolado está prestes a ser acessado também ficará visível para as extensões. Portanto, elas podem aplicar qualquer regra de correspondência de URL para bloqueio, como fariam em iframes. Simplesmente bloquear todos os frames isolados incondicionalmente pode interromper os casos de uso não relacionados a anúncios. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adoção mais ampla | O armazenamento compartilhado deve ser um padrão do setor disponível em todos os navegadores. | Seu feedback é muito importante para nós. O Chrome continua participando ativamente dos fóruns do W3C para defender a proposta, buscar feedback e incentivar a adoção. |
| Portões de saída | Os portões de saída do armazenamento compartilhado são muito limitados. | Estamos considerando esse feedback e queremos receber mais feedback sobre o ecossistema sobre por que os portões de saída são muito limitados. |
| Conformidade regulatória | Como o armazenamento compartilhado lida com a conformidade regulatória, como as políticas de retenção de dados? | O armazenamento compartilhado oferece a flexibilidade de implementar e personalizar a lógica para controlar o ciclo de vida e a expiração dos dados armazenados. As adtechs podem atualizar ou limpar dados de armazenamento compartilhado com base em carimbos de data/hora de gravação. |
| Teste A/B | Como fazer o teste A/B para o armazenamento compartilhado e a API Protected Audience? | Estamos trabalhando para publicar mais orientações sobre esse assunto e esperamos compartilhar mais detalhes em breve. |
| Limite de armazenamento compartilhado | O que acontece quando o limite de armazenamento compartilhado é atingido? | Se o limite for atingido, nenhuma outra entrada será armazenada. |
| Acesso múltiplo no mesmo carregamento de página | O que acontece quando o armazenamento compartilhado é acessado várias vezes no mesmo carregamento de página? | A melhor maneira de lidar com isso é usando a função window.sharedStorage.append(key, value). Em vez de atualizar o valor de cada anúncio, o que poderia causar colisões se houver vários anúncios. A função de anexação apenas adiciona o novo valor ao final do que já existe. |
| Funcionalidade do iframe | O armazenamento compartilhado será compatível com determinadas funcionalidades de iframe se eles 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 nos iframes será particionado pelo site de nível superior, mas os iframes em si 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. |
ÍCONES
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limite da partição | 10 KiB por site particionado ainda é substancial e gostaria que diminuísse. | O Firefox já indicou uma posição positiva nos CHIPS. Para suporte ao Webkit, recomendamos que os desenvolvedores enviem feedback à Apple diretamente sobre esse problema do GitHub sobre os casos de uso em que cookies particionados têm preferência em relação ao armazenamento particionado. |
| Incorporações autenticadas | Os CHIPs podem afetar o fluxo de login de SSO atual devido ao particionamento diferente que afeta as incorporações autenticadas. | Queremos aproveitar a API Storage Access (com comandos do usuário) para dar suporte ao caso de uso de incorporações autenticadas. Recentemente, enviamos uma intent-to-prototype. |
| Políticas de ciclo de vida | As possíveis políticas de ciclo de vida serão aplicadas aos cookies primários? | No momento, não temos planos de impor limites vitalícios para cookies primários. |
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Suporte à autorização OAuth | Alinhar a autorização de escopos Oauth que não são de perfil | Estamos sempre buscando informações da comunidade do Web Identity com o FedID CG do W3C sobre as melhores maneiras de apoiar a autorização além da autenticação básica após a descontinuação dos cookies de terceiros. |
| Compatibilidade com SAML | Alinhar os requisitos para compatibilidade com SAML | A equipe está buscando ativamente a opinião das comunidades educacionais e de pesquisa sobre as necessidades de suporte ao SAML (além do suporte ao OpenID-Connect) após a descontinuação dos cookies de terceiros. |
Combater spam e fraudes
API Private State Token (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Explorar novos indicadores | Vários parceiros expressaram sentimento positivo em relação à exploração de sinais de integridade do dispositivo ou confiança do usuário fornecidos pelo navegador. Em geral, eles também são cautelosos com o fato de que novos indicadores personalizados são suficientes para manter os níveis atuais de detecção de fraudes. | Temos o prazer de analisar novas propostas juntos na comunidade antifraude e segurança na Web, além de reconhecer e compartilhar preocupações. É 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 na Web e na melhoria da privacidade do usuário. |
| Feedback positivo sobre a PST | Vários parceiros demonstraram interesse em testar ou usar PSTs para vários casos de uso antifraude ou segurança na Web. | Ficamos felizes em receber suporte e interesse em explorar novas soluções que utilizem PSTs. Temos recursos e exemplos de código disponíveis no site do desenvolvedor do Google Chrome. Seu feedback é bem-vindo. |
| Fraude e abuso | Orientação para prevenção / detecção de fraudes de anúncios na medição após a descontinuação dos cookies de terceiros quando os identificadores não estiverem mais disponíveis. | Lançamos ferramentas como os tokens de estado particular, que ajudam a recuperar parte dos indicadores perdidos por cookies de terceiros para fins de combate à fraude, mas com novos controles de privacidade. Estamos investindo ativamente em novas propostas antifraude e antiabuso para preservar os recursos com outras mudanças no 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 padrão, podem ser usadas até seis chaves públicas por 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 chaves de emergência é necessária), o que diminui a capacidade de agregar mais dados do usuário ao longo do tempo. Com qualquer nova API da Web, há um equilíbrio entre a utilidade da API e as informações líquidas de novos usuários. Estimamos que os PSTs tenham o equilíbrio adequado na proteção da privacidade do usuário e, ao mesmo tempo, permitam os principais casos de uso antifraude afetados pela descontinuação dos cookies de terceiros. |
| Buscar integração | A integração de fetch é complicada e desnecessária. |
Há prós e contras no uso do fetch, e queremos buscar ainda mais padronização no ecossistema da Web, mas achamos que seria muito cedo para fazer essa mudança até termos uma noção mais clara de como será o padrão. Se e quando surgir um padrão, também nos comprometemos a fazer a transição responsável dos desenvolvedores da Web para esse padrão. |
| Storage Location | As configurações de chave dos tokens de estado particular precisam ser armazenadas no mesmo local que o protocolo PrivacyPass. | Durante o teste de origem, os desenvolvedores indicaram que preferiam a flexibilidade de armazenar as chaves em URLs gerais em vez de em um diretório .well-known. O formato de compromisso de chave no PrivacyPass não é adequado para versões em que os conjuntos de chaves permitem um valor implícito de "metadados públicos". Se uma variante do PrivacyPass for padronizada com metadados públicos (como POPRF, mascaramento parcial de RSA ou conjuntos de chaves), poderemos mudar para uma versão futura do PST. |
| Implementação de cabeçalho da API | Perguntas sobre a implementação de cabeçalho da API | À medida que a API é padronizada e o uso do ecossistema dessa API se desenvolve, esperamos oferecer suporte à versão padrão que não seja o cabeçalho dela e possivelmente descontinuar a versão do cabeçalho se o uso for baixo o suficiente ou se houver ferramentas/suporte suficientes para desenvolvedores para formas padrão de correlacionar solicitações de emissão/resgate com outros dados. Estamos discutindo o problema aqui. |
| Inscrição | É prático fazer com que emissores se registrem em fornecedores de navegadores? | Atualizamos a especificação para descrever o processo de registro do emissor para tokens de estado particular. Embora ele use um processo próprio, é semelhante aos planos de registro 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. |