Relatório trimestral do segundo 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 a CMA, o Google concordou em disponibilizar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas no Sandbox de privacidade propostas (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 feedback recebido pelo Chrome de várias fontes, conforme listado no feedback visão geral, incluindo, mas não se limitando a: GitHub Problemas, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com o setor partes interessadas e fóruns de padrões da Web. O Chrome agradece o feedback recebido do ecossistema e está explorando ativamente maneiras de integrar os aprendizados as decisões de design.
Os temas de feedback são classificados por prevalência por API. Isso é feito tomando um agregação da quantidade de feedback que a equipe do Chrome recebeu sobre um em um determinado tema e organizando em ordem decrescente de quantidade. O feedback comum os temas foram identificados analisando os tópicos de discussão das reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que aparecem nas equipes internas do Google e em formulários públicos.
Mais especificamente, as atas das reuniões corporativas padrão da Web foram analisou 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 público formulário de feedback. O Google coordenou as equipes envolvidas nessas várias atividades de contato para determinar a relação prevalência dos temas que surgem em relação a cada API.
As explicações das respostas do Chrome aos feedbacks foram desenvolvidas com base em dados Perguntas frequentes, respostas reais feitas a problemas levantados pelas partes interessadas e determinação da especificamente para fins deste exercício de relatório público. Refletir o foco atual de desenvolvimento e teste, perguntas e feedback foram recebidas em relação a Topics, Protected Audience e Attribution APIs Reporting.
O feedback recebido após o fim do período do relatório 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 primários
- IAB
- Interactive Advertising Bureau
- IDP
- Provedor de identidade
- IETF
- Força-Tarefa de Engenharia da Internet
- IP
- Endereço do protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste de origem
- PatCG
- Grupo privado da comunidade de tecnologia de publicidade
- parte restrita
- 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
- Consórcio World Wide Web
- WIPB
- Censura 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 compliance com os requisitos regulamentares. | Como acontece com qualquer nova tecnologia, cada empresa é responsável por garantir que o uso do Sandbox de privacidade obedeça à lei. O Google não pode oferecer orientação jurídica a outras pessoas. No entanto, sabemos que essa é uma área de interesse importante para o ecossistema. Para cada API, publicamos uma documentação técnica extensa, que deve fornecer a base para a realização das avaliações legais necessárias, e estamos trabalhando para disponibilizar materiais adicionais de apoio às empresas esforços para atender aos 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 vão mostrar um panorama do impacto da descontinuação dos cookies de terceiros e da introdução de 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 avaliações, seguidas de orientações detalhadas em junho. Incentivamos que perguntas ou feedback sobre a proposta de teste quantitativo da CMA sejam compartilhados diretamente com a CMA. |
| Modos de teste facilitados pelo Chrome | Mais informações e esclarecimentos sobre o cronograma de testes | Publicamos uma postagem do blog em 18 de maio com mais informações sobre os dois modos de testes facilitados pelo Chrome. Esses detalhes não são definitivos, e vamos publicar mais orientações de implementação à medida que avançarmos no terceiro trimestre de 2023. |
| Armazenamento particionado | O armazenamento particionado vai ser usado durante os testes facilitados pelo Chrome? | O particionamento de armazenamento será enviado a todos os usuários antes do experimento de descontinuação dos cookies de terceiros. Por isso, 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 ofereça suporte a problemas técnicos do Sandbox de privacidade e encaminhamentos que afetam o ecossistema? | O Google oferece vários canais para as adtechs informarem problemas e ativarem os encaminhamentos necessários. Consulte nossa postagem para desenvolvedores e veja mais informações nos fóruns públicos e particulares para feedback e encaminhamento. |
| Cronograma de inscrição | O período atual para a inscrição é muito curto | Ainda estamos avaliando o prazo de restrição e gostaríamos de saber do ecossistema qual período seria mais adequado. |
| 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 ter um número D-U-N-S no site da Dun & Bradstreet (em inglês). Os requisitos variam dependendo do mercado, portanto, os participantes devem verificar o site do mercado específico em que estão interessados. No entanto, em geral, os participantes precisarão fornecer informações básicas sobre sua empresa, como o nome da empresa, o endereço e as informações de contato do proprietário ou gerente da empresa. Os participantes também poderão ser solicitados a fornecer 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 ela for aprovada. |
| 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? | A partir de julho, os testadores vão poder acessar as APIs de relevância e medição em disponibilidade geral. Isso vai sobrepor a disponibilidade do teste de origem e a disponibilidade geral. |
| Estudo do AdExchanger | Mais informações sobre a metodologia de pesquisa | A pesquisa solicitou aos entrevistados que estimassem as taxas de sincronização e a receita de seus negócios. Entrevistados metodologia para responder às perguntas individuais ficava por conta 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. Agradecemos o feedback sobre esse assunto. |
Mostrar conteúdo relevante e Anúncios
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Preservação da privacidade | Pesquisa que avalia a API Topics para preservar a privacidade | Estamos ativamente envolvidos 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 se envolvendo com essa área. A API Topics protege os usuários contra o rastreamento geral na Web, porque dificulta o rastreamento em grande escala. Esses artigos mostram que estamos fazendo isso com sucesso com a API Topics. Esse recurso é mais privado que cookies de terceiros e protege os usuários ao mesmo tempo que oferece suporte aos sites que eles gostam de visitar. |
| A taxonomia dos temas não é granular o suficiente | A taxonomia de temas amplos não inclui temas mais granulares, incluindo 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 revisão da taxonomia, trabalhamos com várias empresas em todo o ecossistema, como a Raptive (antiga CafeMedia) e a Criteo. A taxonomia atualizada remove categorias menos úteis, em favor de categorias que melhor correspondem aos interesses dos anunciantes, mantendo nosso compromisso de excluir temas potencialmente sensíveis. Incentivamos o ecossistema a revisar a taxonomia mais recente e fornecer feedback sobre as mudanças. |
| Processo de atualização da taxonomia e do classificador | Confira 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. | Como mostrado na última postagem do blog (link em inglês), esperamos que a taxonomia evolua com o tempo e que a governança mude para uma parte externa que represente partes interessadas de todo o setor. Também compartilhamos o plano de ampliaçã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 primeiro trimestre de 2023, a CMA comentou que "Entendemos que o Google tem discutido 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 de tópicos aumentaria a pressão competitiva em suas soluções com base em dados próprios, nossa visão preliminar é 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 com este 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 players do ecossistema. | A resposta dos trimestres anteriores não mudou: "O Google se comprometeu com a CMA para criar e implementar as propostas do Sandbox de privacidade sem distorcer a concorrência, priorizando os próprios negócios do Google, além de considerar o impacto na concorrência na publicidade digital e em editores e anunciantes, independentemente do tamanho. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho cumpra esses compromissos. À medida que os testes do Sandbox de privacidade avançam, uma das principais questões que vamos avaliar é o desempenho das novas tecnologias para diferentes tipos de partes interessadas. O feedback é fundamental com relação a isso, especialmente feedbacks específicos e acionáveis que podem nos ajudar a melhorar ainda mais os projetos técnicos. Trabalhamos com a CMA para desenvolver nossa abordagem de testes quantitativos e apoiamos que ela publique uma observação 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 | Considerando que os critérios de seleção de tópicos são 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 e explorando outros sinais que podem melhorar a classificação. Com o tempo, vamos comunicar ao ecossistema os planos revisados. |
| Confidencialidade | O objetivo da API Topics é garantir que as informações do usuário recebidas ou derivadas dela sejam menos sensíveis do que as que poderiam ser derivadas usando os métodos de acompanhamento atuais. | Acreditamos que a API Topics é muito mais particular 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 temos o compromisso de continuar melhorando essa API. |
| Estrutura da taxonomia | Adicionar ID, controle de versões e outra estrutura de metadados à taxonomia de tópicos | Atualmente, estamos incluindo o ID da taxonomia na resposta da API. À medida que avançamos em direção à governança de longo prazo, faz sentido revisar o objeto Topics e incluir metadados adicionais no controle de versões, se necessário. |
| Controle do editor | Os editores devem opinar sobre como os tópicos devem ser classificados. | A classificação incorreta dos sites pode fazer com que o indicador da API Topics seja um pouco menos útil como um indicador geral, mas os sites específicos que são classificados incorretamente não são mais nem menos afetados por isso do que qualquer outro site. Isso ocorre porque as informações contextuais de um site estão sempre disponíveis para leilões no site, o que forneceria informações comparáveis sobre o tópico correto, mesmo no caso de classificação incorreta. Envie seu feedback sobre esse assunto aqui. Permitir que os editores controlem a classificação deles traz riscos. Os sites podem classificar seus sites de maneira 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 temas, de maneira semelhante às extensões de gerenciamento de cookies atuais | Conforme discutido no GitHub (link em inglês), isso já deve ser possível, mas queremos receber mais feedback do ecossistema. |
| Transição para disponibilidade geral | A transição do teste de origem para a disponibilidade geral vai afetar a API Topics? | Os dados dos usuários que fizerem a transição do teste de origem para a disponibilidade geral não vão ser perdidos. |
| Privacidade | 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 temas por visitas fraudulentas | Explicamos as mitigações aqui. |
| Classificador de temas | Os sites podem solicitar a alteração da classificação de temas? | Temos interesse em receber feedback da comunidade sobre esse assunto. Envie seu feedback aqui. |
| Sites de provedores de temas | 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 feedback adicional é bem-vindo. |
API Protected Audience (anteriormente FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Modelagem de tráfego | Impacto no desempenho da filtragem orientada a SSP para otimizar a carga de consultas por segundo (QPS) | Passamos um tempo considerável pensando na modelagem de tráfego e a recomendação é que as SSPs aproveitem o armazenamento em cache. |
| Testando volume | É difícil testar a API Protected Audience, já que SSPs e DSPs estão com dificuldade para conseguir grandes volumes de tráfego. | Estamos constantemente engajando parceiros de SSP e DSP para adotar e testar a API Protected Audience. 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 | Implementar soluções de público-alvo protegido 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 educar e apoiar esses esforços, além de avaliar continuamente outros aceleradores para viabilizar 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ública | Embora estejamos analisando possíveis opções de suporte além das soluções baseadas na nuvem, atualmente não é viável oferecer suporte a TEEs no local devido às limitações de segurança no local 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 por implantações no local, acreditamos que continuar a expandir e melhorar as implantações baseadas na nuvem (por exemplo, oferecer suporte ao GCP e à 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 | Lances e A proposta de serviços de leilão vai aumentar o custo e a complexidade para as adtechs em comparação com os modelos do lado do cliente. | Estamos desenvolvendo um guia para estimar os custos de suporte aos fluxos de trabalho de lances e leilões na guia "Lances e Servidor de leilão, que será correlacionado com o uso da adtech, cumprindo uma das metas dos nossos designs. |
| Linhas do tempo do K-Anon | Quando as restrições de k-anonimato planejado serão aplicadas a "renderUrl"? | Estamos trabalhando em uma explicação para o cronograma de aplicação que vamos lançar em breve. |
| Restrições runAdAuction | O Chrome pode restringir o recurso runAdAuction para que ele só possa ser chamado pela página superior? |
Embora nosso design seja totalmente compatível com runAdAuction para que seja possível chamá-lo da página superior, acreditamos que seria mais prejudicial para os editores restringir esse objeto para que ele possa ser chamado apenas do domínio principal.Recebemos feedback específico do ecossistema informando que o Sandbox de privacidade precisa minimizar o trabalho dos editores e anunciantes. Esse feedback está de acordo com o princípio geral de desenvolvimento da Web de que os proprietários de sites podem usar ferramentas de terceiros na execução dos próprios sites. A meta 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 chamará runAdAuction em seu site, acreditamos que oferecemos flexibilidade aos editores para encontrar o melhor caminho de acordo com suas necessidades. |
| Suporte de implementação | O Chrome pode criar ou contribuir para a implementação de código aberto de um leilão com vários vendedores? | O objetivo do Sandbox de privacidade é 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 explorar soluções com o setor. Não pretendemos criar uma implementação específica, já que nosso objetivo principal é desenvolver tecnologias de plataforma, e não ditar estratégias de uso delas. Nossas tecnologias vão ajudar as empresas de adtech a atender melhor os clientes com as proteções de privacidade adequadas. |
| Leilões de vários vendedores | O Chrome força o compartilhamento de uma vencedor 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 (observação: somente antes de iniciar o leilão). Dito isso, não vemos como o navegador distingue se uma informação é um vencedor contextual ou não, de modo que não podemos impor o bloqueio ou a exigência de certas informações. |
| Preferência do usuário para acompanhamento de consentimento | Adtech perguntando à PA como implementar o rastreamento de consentimento do usuário corretamente | Nossa resposta inclui o que foi dito no primeiro trimestre: "Para anúncios específicos, a adtech relevante é a melhor opção para oferecer controles sobre quais criativos são exibidos ou como são selecionados." Discutimos vários cenários relacionados a esse problema durante a Reunião de público-alvo protegido da WICG, e queremos receber mais feedback e discussões sobre o assunto. |
| Públicos-alvo personalizados | Os casos de uso de SSP relacionados à criação de públicos-alvo personalizados vão ter suporte da API Protected Audience? | A API Protected Audience permite que SSPs e outros provedores de adtech tenham e gerenciem públicos-alvo personalizados. Mais orientações sobre como uma SSP pode se integrar à API PA estão sendo desenvolvidas e serão disponibilizadas para que as SSPs e outros provedores de tecnologia de publicidade apoiem os esforços de integração. |
| Formatos | A API Protected Audience oferece suporte a vídeos? | Os anúncios em vídeo são exibidos de duas maneiras: como XML ou HTML VAST (um anúncio out-stream que também pode carregar o XML VAST em um player de vídeo). Os compradores podem retornar qualquer um dos formatos por um URL de renderização. 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 forma como os anúncios são veiculados pela API Protected Audience. Isso significa garantir que as tags de posicionamento transmitam o URL de um iframe da API Protected Audience para um player de vídeo. Para Fenced Frames, trabalharemos para atender às necessidades de vídeo antes do requisito de uso de Fenced Frames, que será lançado em 2026. |
| Ritmo | Como o caso de uso do Pacing funciona com a API Protected Audience? | Seu feedback é muito importante para nossa equipe! Gostaríamos de ver mais instâncias dessa solicitação com mais detalhes vindos de mais parceiros de SSP, já que isso tem sido uma preocupação principalmente com a DSP até o momento. |
| Frequência de atualização | A frequência das chamadas de dailyUpdate (até uma por grupo de interesse por dia) pode não ser suficiente para determinados casos de uso, como atualizar as 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 diferentes cadências, 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, 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 exigir. |
| Depuração | Quando a funcionalidade do forDebuggingOnly será removida? |
Planejamos desativar o forDebuggingOnly para eventos de perda devido à descontinuação de cookies de terceiros. Planejamos desativar o forDebuggingOnly para eventos vencedores em 2026 no mínimo. |
| Grupos de interesse entre dispositivos | Proposta para ativar grupos de interesse entre dispositivos para user agents autenticados | Estamos avaliando essa proposta, mas a alta especificidade da segmentação entre dispositivos representa grandes preocupações de privacidade, conforme discutido neste problema do GitHub. |
| (Também informado no 1o trimestre) Remarketing dinâmico | O remarketing dinâmico ainda vai ser possível com a API Protected Audience após a descontinuação dos cookies de terceiros? | Acreditamos que esse caso de uso seja possível com a API Protected Audience, conforme explicado aqui. |
| Dados relacionados ao clique | Adicionar dados relacionados a cliques a browserSignals. |
No momento, estamos pedindo esclarecimentos sobre quando o clique deu uma posição preliminar. |
| (Também relatado no 4o 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 ampliar a funcionalidade da API. | A adtech que relatou o problema também mencionou que ainda está avaliando o que pode fazer com a UDF. Por isso, ainda não há feedback acionável para reagir, apenas até a disponibilidade geral. |
| Moeda | Valores monetários não devem ser representados com pontos flutuantes. | Resolvemos 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 detalhada da lacuna entre a atual API Protected Audience e essas solicitações. |
| GenerateBid | Suporte para o Google Ads proposta retornar mais de um anúncio candidato por grupo de interesse de anúncio de generateBid e pontuar esses candidatos em "scoreAd". |
Isso está sendo avaliado. Gostaríamos de receber mais feedback aqui. |
| Ordem de leilão | Os leilões da API Protected Audience precisam ser os últimos a serem executados para que possam receber entradas 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 | Vamos analisar e discutir essa solicitação aqui . Por isso, queremos receber mais feedback. |
| Armazenamento em cache | O SSP não pode criar 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 para todos os casos de uso de indicadores por comprador e estamos avaliando mais opções. Agradecemos qualquer feedback adicional do ecossistema sobre se o armazenamento em cache funcionaria para os casos de uso correspondentes. |
| API Attribution Reporting e Protected Audience | Como a API Attribution Reporting e a API 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 de resumo e de evento). No dia 1o de junho, compartilhamos mais informações sobre a integração aprimorada da API Protected Audience com a API Attribution Reporting. Clique aqui para mais informações. |
| Endpoint do servidor | O endpoint do servidor será o servidor de agregação confiável no design final? | O endpoint do servidor é mantido por adtech e independente dos servidores de agregação confiáveis usados para processar os relatórios coletados e transformados. No momento, não planejamos fazer mudanças no endpoint de relatórios. O design atual visa 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 deve ser necessário. Outra complicação é que diferentes adtechs provavelmente vão ter diferentes estratégias de lote desejadas. Gostaríamos de receber mais feedback aqui. |
| 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 de indicadores de consentimento vai 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 queremos receber mais feedback. |
| Marketing baseado em contas | Seria possível aplicar casos de uso de marketing com base em contas? | A API Protected Audience oferece suporte a vários casos de uso de marketing com base 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 componente? | Os leilões de componentes não pontuam grupos de interesse diretamente. Em vez disso, pontuam os anúncios e lances que um 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 de suporte a contribuições externas na base de código do GitHub do servidor de chave-valor. | Queremos atualizar nossos processos relevantes para dar suporte a contribuições externas no código do GitHub. |
| Tamanho do grupo de interesse | Qual é o número máximo de chaves permitido pelo IG? | O limite atual é de 50 KB no tamanho de um IG, e as chaves contam como parte disso. Agradecemos mais discussões sobre o limite de tamanho. |
| Agrupar chamadas | Como é possível reduzir o número de chamadas do servidor K/V? | Use os cabeçalhos de controle de cache HTTP para reduzir o número de chamadas K/V. Por exemplo, ele pode ser armazenado em cache entre leilões de componentes e também em espaços de anúncio de uma única página. |
| Controle de versão | Suporte a várias versões do código da adtech | Os serviços de lances e leilões vão ser 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 para geração de relatórios). |
| Armazenamento compartilhado | Suporte à gravação no armazenamento compartilhado no serviço de lances e leilões. | No momento, os serviços de lances e leilões não são compatíveis com o armazenamento compartilhado, mas queremos 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 da Web para um app. | No momento, o escopo da Web para o app não está definido na implantação da API Protected Audience no Chrome e no Android, mas temos interesse em saber com o ecossistema a importância desse caso de uso. |
| K-anonimato | Como lidar com substitutos de K-anonimato | Estamos discutindo o problema e queremos receber mais feedback. |
Medir os anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Configurações alternativas de relatórios no nível do evento de VTC | Feedback sobre as configurações alternativas de relatórios de eventos de VTC | Recebemos feedback informando que as configurações atuais no nível do evento não são ideais e pedimos feedback sobre as configurações globais ideais. Podemos receber mais feedback sobre esse assunto e acreditamos que nossa explicação flexível no nível do evento também ajuda a resolver o 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 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 relatórios conflitantes de partes diferentes podem ser reconciliados? | A maioria dos cenários de relatório é abordada com o uso de relatórios agregados, enquanto a proposta de configuração flexível no nível do evento visa especificamente uma flexibilidade adicional para relatórios a nível de evento, que são mais frequentemente usados para casos de uso de otimização. Agradecemos qualquer comentário/feedback adicional do ecossistema sobre esse cenário. |
| Registro da fonte | E se o registro da origem acontecer após o registro do acionador? | Atualmente, se o registro de uma fonte ocorrer após o registro do acionador, a origem e o acionador não poderão ser atribuídos um ao outro. Este parece ser um caso extremo. Agradecemos qualquer feedback adicional sobre esse problema e vamos tentar resolvê-lo se for um cenário que muitas adtechs parecem enfrentar. |
| Trabalhar com várias agências de publicidade | Como as DSPs podem usar a API Attribution Reporting quando um anunciante está trabalhando com várias agências de publicidade? | A API oferece suporte a 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 melhore 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. Agradecemos qualquer feedback adicional sobre esse cenário e vamos continuar iterando com base nesse feedback. |
| Limites de destino | Os limites de destino podem afetar o caso de uso de anúncios com atualização automática. | Discutimos esse problema na reunião de 1o de maio e queremos saber qual seria o limite razoável. Adicionamos a explicação sobre os Relatórios de atribuição com relatórios de eventos para informar 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 a API Attribution Reporting e a API 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 de resumo e de evento). No dia 1o de junho, compartilhamos mais informações sobre a integração aprimorada da API Protected Audience com a API Attribution Reporting. Clique aqui para mais informações. |
| 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 podem ser configurados. | Temos um código compartilhado no GitHub (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. Estamos interessados em ouvir qualquer pessoa que opte por testar com o código e gostaria de 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 estará disponível? | Em 9 de maio, anunciamos um experimento para 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. |
| Eliminar a duplicação de conversões | Como as soluções de métricas independentes podem ser reconciliadas com a ARA? | Assim como na prática padrão atual, os anunciantes trabalham com um provedor de medição independente terceirizado para eliminar a duplicação na geração de relatórios de conversão. Oferecemos recursos sobre como eliminar a duplicação de conversões em relatórios de eventos. |
| 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 Attribution Reporting conforme anunciado? | A partir do Chrome Stable 115, vamos ativar as APIs de relevância e medição para uma parte dos usuários do Chrome por padrão. Essa disponibilidade geral será ampliada à medida que monitorarmos possíveis problemas. A meta é alcançar 100% de disponibilidade em um período de 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 acessar essas APIs em disponibilidade geral. Isso vai sobrepor a disponibilidade do teste de origem e a disponibilidade geral pelo registro. Seu token de teste de origem será válido até 19 de setembro, mas recomendamos que você se inscreva nas APIs antes da expiração para sair dele 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 das 114 às 115. |
| Faturamento | Como usar o Attribution Reporting para o faturamento de custo por conversão | Conforme mencionado neste artigo, a API Attribution Reporting não é adequada para o faturamento de custo por conversão devido ao ruído adicionado aos relatórios de resumo e de evento. Incentivamos os agentes do ecossistema a compartilhar feedback sobre o impacto em vários modelos de faturamento pela API Attribution Reporting no GitHub. |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Mudança de atraso de 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 animados com a reação positiva à alteração proposta e incentivamos o ecossistema a continuar enviando feedback sobre nossas propostas. |
| Solução no local | O serviço de agregação pode ser implantado em data centers no local? | Embora estejamos analisando possíveis opções de suporte além das soluções baseadas na nuvem, atualmente não é viável oferecer suporte a TEEs no local devido às limitações de segurança no local 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 por implantações no local, acreditamos que continuar a expandir e melhorar as implantações baseadas na nuvem (por exemplo, oferecer suporte ao GCP e à 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 de diferentes períodos | Capacidade de reprocessar relatórios de diferentes períodos | Recebemos solicitações semelhantes para dividir lotes por períodos diferentes. 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 processo inicial de avaliação desse processo 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 | Estamos felizes em ouvir as reações positivas do ecossistema em relação às nossas propostas e queremos receber mais feedback à 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? | Embora ainda não tenhamos especificado um prazo para a aceitação dos Termos e Condições, incentivamos as empresas do ecossistema a aceitá-los assim que possível para evitar atrasos na inscrição. Incentivamos as empresas a entrar em contato se tiverem alguma dúvida. |
| Descoberta de chaves | 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. Assim, é possível processar relatórios de resumo para atribuição em várias redes e melhorar o desempenho e a precisão. | No momento, estamos analisando possíveis soluções e soluções alternativas e queremos receber mais feedback do ecossistema. |
API Private Aggregation
| 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 da chave de 128 bits | Mais clareza sobre a limitação de espaço da chave de 128 bits | Deixaremos essa limitação de keyspace mais clara e resolveremos as inconsistências entre as páginas. Recomendamos o uso de estratégias de hash para permanecer 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 a divisão dos relatórios em vez de truncar os limites. Vamos interagir com o ecossistema à medida que esta proposta evoluir. |
| Relatórios de alcance | Solicitação de alcance de relatórios entre plataformas e dispositivos. O alcance é uma métrica fundamental da publicidade da marca. Os anunciantes usam aproximações entre plataformas e dispositivos nos relatórios de alcance e frequência para analisar as campanhas e alocar os gastos. 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 pediram uma solução alternativa depois que os cookies foram descontinuados. |
A equipe do Sandbox de privacidade está analisando recursos para oferecer suporte a metodologias de alcance entre domínios após a descontinuação dos cookies de terceiros. Gostaríamos de receber mais feedback do ecossistema. |
Limitar o rastreamento oculto
Dicas de cliente de redução de user agent/user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Dicas para outros formatos (também informadas no 1o trimestre de 2023) | Solicitação de dicas de cliente HTTP do user agent (UA-CH) para fornecer outros formatos, como TV e RV | Ainda estamos trabalhando em algumas decisões de design importantes (se é para fornecer um único valor, como "TV" ou uma lista de recursos de formato), mas permanecer interessado em prototipar essa ideia. |
| 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 deterministas quando muitas solicitações são enviadas. | No momento, não temos novas atualizações sobre a proposta de orçamento de privacidade, mas nos comprometemos a não restringir as solicitações de dicas de clientes do UA antes da descontinuação dos cookies de terceiros. |
| Compatibilidade de site | 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 uma lista de marcas, e um deles é exatamente a compatibilidade. Um UA é livre para 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 definir medidas antifraude com a proteção de IP? | Entendemos a importância dos casos de uso antifraude e o possível impacto nesses casos de uso. Planejamos publicar mais detalhes sobre o suporte antifraude ainda este verão. Estamos coletando feedback do ecossistema para melhorar o suporte aos casos de uso antifraude. |
| GeoIP | Mais informações sobre o cronograma de teste e implantação do GeoIP | O Chrome publicou recentemente novas informações detalhando nossos planos GeoIP. Planejamos publicar mais informações sobre os cronogramas de implantação no terceiro trimestre. Inicialmente, esperamos lançar a proteção de IP como um recurso opcional do usuário em uma pequena porcentagem do tráfego. O motivo é que sabemos que essa proposta pode envolver algumas mudanças significativas para as empresas. Por isso, queremos dar tempo ao ecossistema para se ajustar e enviar feedback antes que o recurso seja lançado para mais pessoas. |
| Autenticação da conta | Como a autenticação da conta com o servidor proxy funcionará exatamente? | Planejamos publicar mais detalhes sobre a autenticação da conta ainda este verão, mas já compartilhamos algumas considerações iniciais. |
Mitigação de rastreio por redirecionamento
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Orientação sobre teste | 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ções | A proposta atual ainda está em desenvolvimento, e o Chrome continua atualizando a proposta para oferecer clareza e informações ao ecossistema. Estamos trabalhando para fornecer mais detalhes e agradecemos qualquer feedback adicional. |
| Exclusão de cookies | A mitigação de rastreamento por redirecionamento exclui todos os cookies de um domínio? | A mitigação de rastreio por redirecionamento (BTM, na sigla em inglês) limpará todo o armazenamento e o cache, conforme explicado aqui. |
| Burlar a mitigação do rastreamento por redirecionamento | A classificação do rastreador de rejeições pode ser ignorada 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 nos redirecionamentos da mesma guia, mas planejamos trabalhar em fluxos de pop-up no futuro. Gostaríamos de receber mais feedback aqui. |
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 de segmentação por proximidade. | Recebemos feedback sobre esse assunto e temos interesse em saber mais sobre os possíveis impactos no ecossistema. |
Reforce os limites de privacidade entre sites
Conjuntos primários
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado em trimestres anteriores) Limite de domínio | 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 tinha sido finalizado. |
| 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 o problema e gostaria de receber mais informações. |
| Gerenciamento de repositório | Informações sobre políticas para remover conjuntos primários do repositório do GitHub se houver discrepâncias ou negligência | O Chrome recebeu o feedback sobre este caso de uso. A equipe está investigando o problema e gostaria de receber mais feedback. |
| Educação do usuário | O Chrome precisa aumentar o reconhecimento e a compreensão dos usuários sobre os conjuntos primários para incentivar 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 (vinculado a partir da interface do Chrome) sobre esse assunto. O Chrome também está empenhado em continuar a aprender a melhor maneira de educar os usuários nos contextos apropriados. |
| Postar 3PCD | Os cookies de terceiros vão continuar existindo em um conjunto primário após a descontinuação. | Embora o requestStorageAccess e o requestStorageAccessFor realmente disponibilizem cookies de terceiros novamente para casos de uso específicos e claramente definidos, eles agora exigem a 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 a 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. Mais informações estão disponíveis para os usuários no artigo da Central de Ajuda (link na interface do Chrome). Planejamos expandir o guia para desenvolvedores à medida que o QPS aumentar em até 100%. |
| Envio de conjuntos primários | Renomeie o .well-known/first-party-set obrigatório para incluir uma extensão .json. |
Fizemos essa mudança para garantir que alguns planos de hospedagem na Web sejam compatíveis. |
| Registro IANA | first_party_sets.JSON precisa estar registrado na IANA. |
Estamos analisando a proposta e queremos receber mais feedback aqui. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Bloqueio de anúncios | Fenced Frames facilita o bloqueio de anúncios por bloqueadores de anúncios. | As extensões podem interagir com frames isolados de maneira semelhante a como interagiriam com iframes. O URL real para o qual o frame delimitado está prestes a ser acessado também ficará visível para as extensões. Por isso, elas poderão aplicar qualquer regra de correspondência de URL para bloqueio, como faria nos iframes. O simples bloqueio incondicional de todos os frames delimitados pode interromper os casos de uso de frames isolados que não são anúncios. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adoção mais ampla | O armazenamento compartilhado é um padrão do setor e está disponível em todos os navegadores. | Aceitamos e reconhecemos esse feedback. O Chrome continua participando ativamente dos fóruns do W3C para defender a proposta, buscar feedback e impulsionar a adoção. |
| Portais de saída | As portas de saída do armazenamento compartilhado são muito limitadas. | Estamos considerando esse feedback e queremos receber mais feedback do ecossistema sobre por que os portões de saída são muito limitados. |
| Conformidade regulatória | Como o armazenamento compartilhado vai lidar 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 de todos os dados armazenados. As adtechs podem atualizar ou limpar os dados do armazenamento compartilhado com base nos carimbos de data/hora de gravação. |
| Teste A/B | Como é possível realizar 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 no futuro. |
| Limite de armazenamento compartilhado | O que acontece quando o limite do 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 é com 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 só adiciona o novo valor ao final da pré-existente. |
| Funcionalidade do iframe | O armazenamento compartilhado vai oferecer suporte a algumas 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 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 dentro do iframe. |
DICAS
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limite de partição | 10 KiB por site particionado ainda é substancial e gostaria de diminuí-lo. | O Firefox já indicou uma posição positiva nos CHIPS. Para oferecer suporte ao Webkit, recomendamos que os desenvolvedores enviem feedback à Apple diretamente sobre esse problema do GitHub sobre os casos de uso em que é preferível usar cookies particionados em vez do armazenamento particionado. |
| Incorporações autenticadas | Os CHIPs podem afetar o fluxo de login SSO atual porque o particionamento diferente afeta as incorporações 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 para protótipo. |
| Políticas vitalícias | Possíveis políticas de ciclo de vida serão aplicadas aos cookies primários? | No momento, não temos planos de impor limites de duração aos cookies primários. |
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Suporte para autorização OAuth | Alinhar sobre a autorização de escopos OAuth sem perfil | Estamos buscando ativamente a contribuição da comunidade de identidade da Web por meio do W3C FedID CG sobre as melhores maneiras de dar suporte à autorização além da autenticação básica após a descontinuação dos cookies de terceiros. |
| Suporte para SAML | Alinhar os requisitos para o suporte a SAML | A equipe está buscando informações das comunidades educacionais e de pesquisa sobre as necessidades de suporte do 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 |
|---|---|---|
| Como explorar novos indicadores | Vários parceiros expressaram sentimento positivo em explorar os sinais facilitados pelo navegador de integridade do dispositivo ou confiança do usuário. Em geral, elas também são cautelosas com a possibilidade de novos sinais específicos serem suficientes para manter os níveis atuais de detecção de fraudes. | Estamos animados para analisar novas propostas com a comunidade antifraude e de segurança na Web, além de reconhecer e compartilhar suas preocupações. É exatamente por isso que "combater spam e fraudes" tem sido um fluxo de trabalho fundamental do Sandbox de privacidade e por que continuamos a priorizar o investimento na preservação da segurança na Web à medida que melhoramos a privacidade do usuário. |
| Feedback positivo na PST | Vários parceiros expressaram interesse em testar ou utilizar PSTs para vários casos de uso antifraude ou de segurança na Web. | Estamos felizes em receber apoio e interesse em explorar novas soluções que usam PSTs. Temos recursos e exemplos de código disponíveis no site para desenvolvedores do Chrome. Gostaríamos de receber mais feedback. |
| Fraude e abuso | Orientações para a prevenção de fraudes de anúncios / detecção 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 antifraude, mas com novos controles de privacidade. Estamos investindo ativamente em novas propostas antifraude e contra abuso 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 definição, até seis chaves públicas podem ser usadas por vez, o que pode representar um "estado" de 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 probabilidade de coleta de dados adicionais do usuário ao longo do tempo. Com qualquer nova API da Web, ela fornece um equilíbrio entre a utilidade fornecida e as novas informações de usuário. Estimamos que os PSTs encontram o equilíbrio adequado para proteger a privacidade do usuário e, ao mesmo tempo, permitir os principais casos de uso antifraude afetados pela descontinuação de cookies de terceiros. |
| Buscar integração | A integração do fetch é complicada e desnecessária. |
Há prós e contras no uso de fetch, e gostaríamos de buscar mais padronização no ecossistema da Web, mas achamos que seria 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 fazer a transição responsável dos desenvolvedores Web para ele. |
| Local de armazenamento | As configurações de chave de 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 uma versão em que os conjuntos de chaves são destinados a permitir "metadados públicos" implícitos. . Se uma variante do PrivacyPass for padronizada com metadados públicos (como POPRF, mascaramento de RSA parcial ou conjuntos de chaves), poderemos mudar para uma versão futura do PST para oferecer suporte a isso. |
| Implementação de cabeçalho da API | Perguntas sobre a implementação de cabeçalhos da API | À medida que a API é padronizada e o uso do ecossistema dessa API amadurece, esperamos oferecer suporte à versão padrão sem cabeçalho dessa API e, eventualmente, descontinuar a versão do cabeçalho se o uso for baixo o suficiente ou se houver ferramentas/suporte suficiente do desenvolvedor para correlacionar solicitações de emissão/resgate com outros dados. Estamos discutindo o problema aqui. |
| Registro | É prático fazer com que os emissores se registrem junto a fornecedores de navegadores? | Atualizamos a especificação para descrever o processo de registro do emissor para tokens de estado particular. Embora ele tenha um processo próprio, é semelhante aos planos de registro para o restante do trabalho do Sandbox de privacidade, em que pedimos que os emissores façam uma declaração pública sobre como pretendem usar os PSTs e que reconheçam as restrições técnicas que protegem a privacidade do usuário. |