Relatório trimestral do 4º trimestre de 2022 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 apresentar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas nas propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo de feedback do Sandbox de privacidade são gerados pela agregação do feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral do feedback, incluindo, entre outros: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com as partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe com prazer o feedback recebido do ecossistema e está procurando ativamente maneiras de integrar as lições a decisões de design.
Os temas de feedback são classificados pela prevalência em cada API. Isso é feito com uma agregação da quantidade de feedback que a equipe do Chrome recebeu sobre um tema específico e organizado em ordem decrescente de quantidade. Os temas comuns de feedback foram identificados analisando os tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que aparecem nas equipes internas e nos formulários públicos do Google.
Mais especificamente, as atas das reuniões dos órgãos de padrões da Web foram analisadas e, para feedback direto, os registros do Google de reuniões individuais com as partes interessadas, e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público foram considerados. O Google então coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas emergentes em relação a cada API.
As explicações das respostas do Chrome ao feedback foram desenvolvidas com base nas perguntas frequentes publicadas, nas respostas reais feitas a problemas levantados por partes interessadas e na determinação de uma posição especificamente para os fins deste exercício de relatórios públicos. Refletindo o foco atual de desenvolvimento e teste, foram recebidas perguntas e feedback específicos em relação às APIs Topics, FLEDGE e Attribution Reporting.
O feedback recebido após o fim do período de geração de relatórios atual pode ainda não ter uma resposta considerada do Chrome.
Glossário de acrônimos
- CHIPS
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos próprios
- IAB
- Interactive Advertising Bureau
- IDP
- Provedor de identidade
- IETF
- Internet Engineering Task Force
- IP
- Endereço de Protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste da Origin
- PatCG
- Grupo da comunidade de tecnologias de publicidade privada
- RP
- Entidade confiável
- SSP
- Plataforma de fornecimento
- TEE
- Ambiente de execução confiável
- UA
- String do user agent
- UA-CH
- Dicas de cliente HTTP do user agent
- W3C
- World Wide Web Consortium
- WIPB
- IP Blindness proposital
Feedback geral, sem API/tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no terceiro trimestre) Utilidade para diferentes tipos de partes interessadas |
Preocupações de que as tecnologias do Sandbox de privacidade favoreçam desenvolvedores maiores e que sites de nicho (menores) contribuam mais do que sites genéricos (maiores) | Nossa resposta não mudou em relação à pergunta 3: "O Google se comprometeu com o CMA a projetar e implementar as propostas do Sandbox de privacidade de uma maneira que não distorça a concorrência por auto-referenciamento do próprio Google e que leve em conta o impacto na concorrência na publicidade digital e nos editores e anunciantes, independentemente do tamanho deles. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho esteja em conformidade com esses compromissos. À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é como as novas tecnologias funcionam para diferentes tipos de partes interessadas. O feedback é fundamental nesse sentido, especialmente feedback específico e útil que possa nos ajudar a melhorar ainda mais os designs técnicos. Trabalhamos com a CMA para desenvolver nossa abordagem de testes quantitativos e apoiamos a publicação de uma nota sobre o design do experimento para fornecer mais informações aos participantes do mercado e uma oportunidade de comentar sobre as abordagens propostas." |
| (Também informado no terceiro trimestre) Solicitações de documentação |
Pedidos de mais recursos detalhando como gerenciar testes, análises e implementação | Atualização do 4º trimestre: Agradecemos aos desenvolvedores que acharam nosso material útil e continuamos comprometidos em oferecer mais material para que os desenvolvedores entendam como as novas tecnologias podem funcionar para eles. No último trimestre, adicionamos uma seção "Notícias e atualizações" ao privacysandbox.com e publicamos uma análise detalhada de como o Sandbox de privacidade pode ajudar a aumentar a relevância dos anúncios no futuro. Também realizamos sessões públicas de atendimento ao desenvolvedor para compartilhar práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produto e engenharia para permitir discussões/perguntas ao vivo. |
| Core Web Vitals | Como a latência da API do Sandbox de privacidade afeta as Core Web Vitals? | Manter a latência no mínimo é uma das principais metas de design das APIs do Sandbox de privacidade. Nossa expectativa atual é que a latência da API tenha um impacto mínimo nos Core Web Vitals de um site, já que a maioria das APIs é chamada após a renderização inicial do site. Continuamos monitorando e fazendo melhorias para reduzir ainda mais a latência de cada uma das APIs e incentivamos testes e feedback contínuos. A latência no processo de lances em tempo real é abordada na seção FLEDGE em "Performance dos leilões do FLEDGE". |
| Interoperabilidade | Preocupações sobre a interoperabilidade com outras soluções possíveis | O objetivo do Sandbox de privacidade é proteger os usuários contra o rastreamento entre sites e atender às necessidades do ecossistema da Web. Para isso, estamos deixando de usar tecnologias legadas de navegador que permitem esse rastreamento entre sites, como cookies de terceiros, e oferecendo novas tecnologias criadas especificamente para atender a casos de uso específicos. As propostas do Sandbox de privacidade melhoram a privacidade ao limitar os dados que saem do dispositivo de um usuário. As propostas não impõem restrições técnicas à capacidade de um site compartilhar ou processar dados coletados no navegador. Portanto, as tecnologias não impedem as empresas de firmarem contratos de "gestão de dados" ou qualquer outra relação contratual semelhante. Da mesma forma, elas não restringem a capacidade dos usuários de consentir o compartilhamento dos dados por outros meios. Para maior clareza, o Google se comprometeu a aplicar as tecnologias do Sandbox de privacidade da mesma forma em todos os sites, incluindo os produtos e serviços do Google. Depois que o Chrome encerrar o suporte a cookies de terceiros, os compromissos também deixarão claro que o Google não vai usar outros dados pessoais, como o histórico de navegação sincronizado do Chrome, para rastrear usuários com o objetivo de segmentar ou medir a publicidade digital. |
Mostrar conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Impacto na classificação da pesquisa do Google | Consulta sobre se o suporte da API Topics de um site será usado como um indicador potencial para a classificação dos resultados da Pesquisa Google | Alguns sites podem desativar a API Topics. A equipe do Sandbox de privacidade não coordenou nem pediu à organização de pesquisa que use a classificação de páginas como incentivo para que os sites adotem a API Topics. O Google confirmou ao CMA que a Pesquisa Google não vai usar a decisão de um site de desativar a API Topics como um indicador de classificação. |
| Classificador de temas | Adicione o URL e o conteúdo da página, além do nome do host, para determinar o tema de uma página da Web e melhorar a utilidade para várias partes interessadas. | No momento, o histórico de navegação de um usuário é classificado usando os nomes de host de um site. O Chrome continua avaliando opções para considerar os metadados da página (como todos ou alguns componentes do URL e/ou conteúdo da página) na classificação de tópicos. Todas as melhorias de utilidade precisam ser ponderadas em relação aos riscos de privacidade e abuso. Por exemplo, em relação aos metadados em particular, alguns dos riscos incluem: - Sites que modificam metadados no nível da página como um método para codificar significados diferentes (e potencialmente sensíveis) em tópicos; - Sites que modificam metadados no nível da página para deturpar os tópicos em busca de ganhos financeiros; - Sites que modificam metadados no nível da página de forma dinâmica como um método de rastreamento entre sites |
| (Também informado no terceiro trimestre) Impacto nos indicadores próprios |
O indicador de tópicos pode ser muito valioso e, como resultado, desvaloriza outros indicadores próprios com base em interesses. | Nossa resposta não mudou em relação à pergunta 3: "Acreditamos que a publicidade com base em interesses é um caso de uso importante para a Web, e a API Topics foi projetada para oferecer suporte a esse caso. Conforme descrito [no nosso relatório do terceiro trimestre], outras partes interessadas do ecossistema expressaram preocupação de que os Tópicos não sejam úteis o suficiente para gerar valor. Em todos os casos, as melhorias na taxonomia são um esforço contínuo, e esperamos que ela evolua com os testes e as contribuições do ecossistema." |
| Como atualizar a taxonomia | Como a lista de taxonomias será atualizada? | Estamos procurando feedback sobre a taxonomia mais útil para o ecossistema. A taxonomia incluída na proposta inicial da API Topics foi projetada para permitir testes funcionais. O Chrome está considerando várias abordagens para atualizar a taxonomia. Por exemplo, o Chrome pode usar um conceito de valor comercial para cada tópico para determinar qual categoria incluir em iterações futuras. |
| Desempenho do classificador regional de tópicos | O classificador de temas tem um desempenho ruim em domínios regionais | O esforço para melhorar o classificador é contínuo. Com base no feedback que recebemos, uma possibilidade em consideração é expandir a lista de substituição de tópicos, que, de acordo com nossa análise, vai aumentar a cobertura global e melhorar a precisão. A classificação da API Topics tem dois componentes relevantes: (1) uma lista de substituição que contém os 10 mil sites mais importantes e os tópicos deles e (2) um modelo de ML no dispositivo que classifica os nomes de host em tópicos. Ao expandir a lista de substituição (1), podemos melhorar a performance da classificação para as regiões em que o classificador pode estar com um desempenho ruim. |
| Época de uma semana | A época de uma semana é muito longa para usuários que querem tomar decisões de curto prazo. | Estamos analisando qual deve ser a duração adequada da época e gostaríamos de receber mais feedback sobre qual seria a melhor época para o ecossistema. |
| Recuperação de cabeçalhos HTTP | Preocupação de que não há informações suficientes sobre a recuperação de cabeçalhos HTTP de tópicos | O trabalho está em andamento para cabeçalhos e fetch(). Também temos informações disponíveis aqui. Também adicionamos informações sobre skipObservation à explicação. |
| A segmentação por tópicos tem como objetivo ajudar os anunciantes, não os usuários | Os temas/Sandbox de privacidade parecem ser uma abordagem focada no setor. O benefício para os usuários não é tão claro quanto o benefício para a indústria. | Acreditamos que o benefício para os usuários é que a API Topics oferece suporte a anúncios com base em interesses que mantêm a Web livre e aberta. Também acreditamos que ela melhore significativamente a privacidade em comparação com cookies de terceiros. A remoção de cookies de terceiros sem alternativas viáveis pode afetar negativamente os editores e levar a abordagens menos privadas, não transparentes e que não podem ser redefinidas ou controladas pelos usuários. Muitas empresas estão testando ativamente as APIs Topics e Sandbox. Temos o compromisso de oferecer as ferramentas para melhorar a privacidade e oferecer suporte à Web. O W3C Technical Architecture Group publicou recentemente a visão inicial sobre a API Topics, e vamos responder publicamente a ela. Nesta fase, como o Google recebeu perguntas do ecossistema sobre o que essa revisão pode implicar para o desenvolvimento e o lançamento da API Topics, queremos reafirmar nosso plano de disponibilizá-la no Chrome Stable ainda este ano. Embora o Google aprecie a contribuição do Grupo de Arquitetura Técnica do W3C, ele considera de extrema importância continuar os esforços para desenvolver e testar tópicos em consulta com a CMA e o ecossistema. |
| Vazamento de dados | Preocupação de que o Topics possa vazar para outros sites sem permissão | O design da API Topics torna muito improvável que os dados de um único editor (ou até mesmo de um grupo menor de editores) sejam vazados de alguma forma. Os sites dos editores também têm controle total sobre a API Topics e podem proibir o acesso a ela usando a política de permissões. |
| Falta de anunciantes para testes | Os editores estão preocupados porque não conseguem demonstrar o valor dos temas aos anunciantes. | No segundo semestre de 2023, planejamos disponibilizar todas as APIs relacionadas a anúncios para testes de integração e permitir a análise do ecossistema do valor dos Tópicos para anunciantes. O teste e a publicação dos resultados serão supervisionados pela CMA, que vai analisar os dados, a análise e a metodologia. O ecossistema é incentivado a compartilhar feedback com o Google e a CMA. |
| Topics e FLEDGE | Solicitar mais informações sobre como usar os temas na lógica de lances do FLEDGE | É possível usar os tópicos na lógica de lances do FLEDGE. Um guia de integração também está em andamento e vai incluir mais detalhes sobre a implementação. |
| Classificação personalizada para o autor de chamada de temas | Permitir que as classificações sejam personalizadas pelo autor da chamada | O desafio com a classificação ou os valores de tópicos personalizados para cada adtech é que isso pode se tornar um mecanismo pelo qual uma adtech pode influenciar os tópicos retornados, ou seja, um vetor de impressão digital. |
| Lista de prioridade de ligações de temas | Permitir que os autores de chamadas forneçam uma lista de prioridade classificada de temas que a API Topics vai retornar com base na qualificação. | No momento, estamos discutindo essa ideia e gostaríamos de receber mais sugestões. |
FLEDGE
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Google Ad Manager | Preocupação de que o Google Ad Manager é o tomador de decisão final para os leilões do FLEDGE e favorece as tags do editor do Google e o Google Ad Manager. | O FLEDGE permite que cada editor escolha a estrutura do leilão, incluindo a escolha de vendedores de nível superior e de componentes. Cada comprador e vendedor em um leilão de componentes sabe quem é o vendedor de nível superior e pode escolher se quer ou não dar lances. |
| Não há participantes suficientes testando o FLEDGE | Pedido para incentivar mais empresas a testar o FLEDGE, por exemplo, melhorando a funcionalidade da API e desencorajando alternativas intrusivas de privacidade, como a impressão digital | O Sandbox de privacidade está sendo implementado em etapas, em parceria com a orientação da CMA e da ICO, e os testes funcionais do FLEDGE demonstraram a estabilidade e o desempenho necessários. O Google continua incentivando o ecossistema a testar as APIs do Sandbox. Recentemente, publicamos a documentação Maximize a relevância do anúncio para mostrar como a FLEDGE e outras APIs podem ajudar a oferecer suporte a casos de uso importantes para o setor de publicidade após a descontinuação dos cookies de terceiros. Outras partes do Sandbox de privacidade já oferecem suporte a mitigações para cobrir o rastreamento (consulte UA-CH, Proteção de IP e Mitigações de rastreamento de rejeição) e vão continuar melhorando com o tempo. O objetivo do Google não é tornar o FLEDGE a única solução de segmentação viável, mas sim continuar comprometido em trabalhar em parceria com o setor e os órgãos reguladores para impulsionar as melhores tecnologias de publicidade que preservam a privacidade no navegador Chrome. |
| Casos de uso de machine learning | Mais orientações sobre como os casos de uso do aprendizado de máquina para treinar algoritmos de lances de leilão terão suporte no FLEDGE e nos Relatórios de atribuição | Sabemos que é necessário ajudar os testadores a encontrar as maneiras mais úteis de aplicar as tecnologias do Sandbox de privacidade. Começamos a publicar orientações especificamente relacionadas ao uso dos vários aspectos das APIs do Sandbox de privacidade como entradas para o aprendizado de máquina. O artigo mais recente, Maximize a relevância do anúncio, discute como o setor de publicidade pode usar esses indicadores para o aprendizado de máquina, e planejamos continuar publicando esse tipo de orientação no futuro. |
| Consultar o servidor de chave-valor (K/V) do FLEDGE | Por que o servidor K/V pode ser consultado publicamente? | O objetivo do servidor K/V é fornecer indicadores em tempo real para leilões da FLEDGE. Portanto, o servidor K/V precisa ser acessível de onde esses leilões do FLEDGE são executados, ou seja, nos dispositivos dos usuários, e precisa estar disponível publicamente. Um valor armazenado no servidor K/V só pode ser recuperado por uma parte que já tenha a chave. Portanto, se uma adtech só fornecer as chaves aos navegadores que estão no grupo de interesse e não usar chaves que possam ser adivinhadas aleatoriamente, somente os navegadores que precisarem do valor para veicular o leilão poderão recuperá-lo. |
| Como fazer a segmentação por data/hora? | Suporte para objetos de data na função de lógica de lances. | Há várias maneiras de fazer isso. Os compradores podem pedir ao vendedor para informar a data e a hora atuais, e os vendedores precisam facilitar o acesso a essas informações para todos os compradores. Os compradores também podem fornecer a data e a hora na resposta de chave-valor em tempo real. Por fim, os compradores podem fornecer a data e a hora como parte da resposta contextual nos indicadores por comprador, que um vendedor pode transmitir ao script generateBid do comprador. |
| Preferências do usuário | Os usuários podem bloquear criativos por anunciante quando veiculados pelo FLEDGE ou por soluções alternativas. | Os usuários podem desativar as APIs do Ads no Chrome. Para anúncios específicos, a adtech relevante é a parte mais bem posicionada para oferecer controles sobre quais criativos são mostrados ou como eles são selecionados. |
| Cronogramas mais claros | Solicitar mais informações sobre a disponibilidade de proteções de privacidade no FLEDGE, como exigir frames delimitados. | Planejamos publicar cronogramas mais detalhados no primeiro trimestre. |
| Como denunciar confusão | Pedir mais clareza sobre como os relatórios do FLEDGE vão funcionar com outras APIs, como a API Fenced Frames e a API Private Aggregation. | Vamos publicar um texto explicativo sobre a interação entre a API Private Aggregation, o FLEDGE e os frames restritos nas próximas semanas. |
| Lances em tempo real e FLEDGE | Orientações sobre como o FLEDGE se integra aos lances em tempo real padrão. | As duas principais coisas que complicam a capacidade de uma adtech de fazer lances em tempo real são o acesso aos dados no nível do evento e a integração mais fácil ao Sandbox de privacidade. Planejamos enviar atualizações e explicações sobre os dois no primeiro trimestre. |
| Desempenho dos leilões do FLEDGE | Relatório de testadores de que os leilões do FLEDGE têm alta latência | Agradecemos os relatórios dos testadores que compartilharam os resultados e casos de uso e compartilhamos algumas sugestões sobre como melhorar a performance da FLEDGE. Além disso, adicionamos ferramentas ao navegador para que os desenvolvedores diagnostiquem melhor o que está deixando os leilões lentos e estamos abordando sistematicamente as principais fontes de latência observadas. As melhorias recentes incluem tempos limite para leilões lentos, uma técnica de filtragem rápida de licitantes, uma maneira de reutilizar worklets do FLEDGE para evitar o pagamento de custos de inicialização e o trabalho contínuo para permitir que a solicitação de anúncio contextual seja executada em paralelo com o tempo de inicialização do FLEDGE e as buscas de rede. Esperamos que a otimização de latência continue sendo um assunto de conversa entre os desenvolvedores do Chrome e os testadores do FLEDGE com base na experiência real de uso da API. |
| Limite de memória do tamanho do grupo de interesse | Pedido para aumentar o limite de tamanho de um único grupo de interesse de 50 kB. | Estamos considerando a solicitação e procurando feedback sobre qual valor de limite funciona. |
| Como combinar os dados veiculados do FLEDGE com o cookie próprio | O FLEDGE vai oferecer suporte à integração com os dados próprios de um anunciante? | O FLEDGE foi criado para oferecer suporte à publicidade usando os dados próprios que um anunciante já tem. No entanto, o FLEDGE não tem a intenção de permitir que um anunciante aprenda o comportamento de navegação de uma pessoa em qualquer site que não seja o próprio site do anunciante. Associar o comportamento de navegação fora do site a dados próprios é contrário aos objetivos do Sandbox de privacidade. Planejamos compartilhar guias de integração com mais detalhes sobre como o FLEDGE vai oferecer suporte à integração com dados próprios nas próximas semanas. |
| Valor de k-anonimato | Como o valor "K" para "k-anon" será decidido e será publicado? | O valor "K" ainda está sendo finalizado, e vamos compartilhar mais informações conforme nossos planos forem desenvolvidos. Queremos saber mais sobre como um valor de k desconhecido pode prejudicar a preparação para o FLEDGE e o escopo do treinamento do modelo de ML. Aceitamos outro feedback sobre esse assunto. |
| Suporte a vários SSPs | Como vários SSPs vão ser compatíveis com o FLEDGE? | O FLEDGE oferece suporte a leilões de vários vendedores, conforme observado nesta proposta. |
| Visibilidade da lógica de lances | Preocupação de que a lógica de lances do DSP será exposta no JavaScript | Com a lógica de lances de design atual, o JavaScript pode ser acessado por outras pessoas, mas aceitamos mais feedback sobre por que isso pode ser uma fonte de preocupação para as DSPs. |
| prebid.js | Qual é o cronograma de suporte ao prebid.js no FLEDGE? | Somente as versões 7.14 e mais recentes do Prebid.js são compatíveis com o módulo FLEDGE. Os editores interessados em testar precisam adicionar o módulo FLEDGE e fazer upgrade da instância do Prebid. |
| Funções definidas pelo usuário no FLEDGE | Como as funções definidas pelo usuário (UDFs) vão ser compatíveis com o FLEDGE? São funções que podem ser programadas pelos usuários finais para estender a funcionalidade da API. | Explicação disponível aqui. Esse recurso ainda está sendo desenvolvido. Por isso, aceitamos mais feedback sobre casos de uso. |
| Relaxar a restrição de mesma origem em recursos do grupo de interesse | Pedido para relaxar a restrição de mesma origem nos recursos do grupo de interesse para permitir determinados casos de uso de adtechs | Na implementação atual do FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl e trustedBiddingSignalsUrl precisam ter a mesma origem que o proprietário do grupo de interesse.A restrição existe para impedir certas explorações por invasores, conforme explicado aqui. |
| Propriedade do interestGroup | Solicitação para limitar se uma adtech pode usar joinInterestGroup para os mesmos grupos de interesse em vários sites | Nosso foco é como os públicos-alvo são usados, não como são criados. Estamos discutindo possíveis abordagens e agradecemos mais sugestões. |
| Key Value Server Key Expiration | Discussão sobre a remoção de chaves do servidor após a expiração dos grupos de interesse correspondentes | Estamos buscando maneiras de lidar com a expiração de chaves e queremos seu feedback. |
Como medir anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Tráfego de teste de origem | O tráfego atual do teste de origem não é suficiente para realizar testes de utilidade. | Os testes de origem atuais são destinados aos participantes do ecossistema para realizar testes funcionais e garantir que a API esteja funcionando conforme o esperado. Entendemos que será necessário um volume maior de tráfego para realizar testes de utilidade quando o desenvolvimento das várias APIs do Sandbox de privacidade estiver mais avançado. O cronograma atual de testes prevê que isso ocorrerá até a disponibilidade geral (ou seja, quando as tecnologias para os casos de uso forem lançadas e ficarem disponíveis para 100% do tráfego do Chrome) no terceiro trimestre de 2023 (confira nossa linha do tempo atualizada em privacysandbox.com). Aceitamos mais feedback sobre testes de casos de uso que exigem mais tráfego. |
| Sobreposição de funcionalidades de diferentes APIs de medição do Sandbox de privacidade | As preocupações com a sobreposição de várias abordagens de medição no Sandbox de privacidade vão aumentar a complexidade, por exemplo, a API Attribution Reporting e a API Private Aggregation. | Estamos trabalhando para melhorar a documentação e esclarecer os diferentes casos de uso das APIs. Agradecemos seu feedback sobre as áreas que precisam de explicação. Por exemplo, a API Attribution Reporting foi criada especificamente para oferecer suporte à medição de conversões, enquanto a API Private Aggregation e o Shared Storage são APIs de finalidade geral que oferecem suporte a uma gama mais ampla de casos de uso de medição em sites. |
| Tentar novamente a solicitação de relatório com falha | Explicação sobre quantas vezes uma solicitação de relatório é feita se ela falhar. | Publicamos orientações sobre isso. Em resumo, os relatórios só são enviados quando o navegador está em execução/on-line. Após a primeira falha no envio, o relatório é tentado novamente após 5 minutos. Após a segunda falha, o relatório é tentado novamente após 15 minutos. Depois disso, a denúncia não é enviada. |
| Atraso na geração de relatórios | Qual é o atraso esperado nos relatórios? | Queremos ouvir mais feedback do ecossistema sobre os atrasos nos relatórios que estão ocorrendo enquanto coletamos dados para avaliar melhor esses atrasos. |
| Pré-renderizar páginas | A atribuição de ARA vai funcionar em páginas de pré-renderização? | O registro de atribuição é adiado nas páginas de pré-renderização até a ativação (o clique ou a visualização real acontecer). Isso significa que vamos adiar o ping de solicitação "attributionsrc". |
| Como medir o Conversion Lift | Como medir o aumento de conversões com testes A/B no mesmo domínio | Os sites podem medir o aumento de conversões com testes A/B no mesmo domínio usando os relatórios de atribuição. Eles podem codificar os parâmetros A/B como chaves usando a API de agregação e receber relatórios de resumo dos valores de conversão por esses buckets de chaves. |
| (Também informadas no terceiro trimestre) Conversões em vários domínios | Como acompanhar conversões em vários domínios, como com dois ou mais destinos | Atualização do 4º trimestre: Publicamos uma proposta para remover a restrição de destino da página de destino, que permite o rastreamento de conversas entre domínios. Essa proposta foi implementada. |
| (Também informado no terceiro trimestre) Configuração de expiração no relatório de conversão |
Solicitação de suporte para o filtro / expiração do relatório por menos de 24 horas | Atualização do 4º trimestre: Compartilhei este pull request , que vai separar as janelas de expiração e de relatórios para reduzir o trade-off entre o atraso nos relatórios e o vencimento da conversão. Esse recurso foi lançado na M110. |
| Fraude e abuso | Solicitações de anunciantes e profissionais de marketing para poder segmentar e agregar dados com base nos sites de editores em que os anúncios são veiculados, o que também daria mais insights sobre possíveis práticas de publicidade fraudulenta | Esse feedback está sendo discutido aqui , e agradecemos outras informações. |
| (Também informado no terceiro trimestre) Atraso nos relatórios de eventos | O atraso de dois a 30 dias nos relatórios de eventos pode ser muito longo para determinados casos de uso. | Os relatórios no nível do evento têm janelas de relatório padrão de 2, 7 e 30 dias. Isso pode ser modificado usando o parâmetro "expiry". As adtechs podem configurar a validade, com um mínimo de um dia, para receber relatórios em menos de dois dias. Limitamos a granularidade das expirações a um dia como um mecanismo de proteção de privacidade, já que relatórios mais detalhados podem resultar em ataques de sincronização. Além disso, permitimos a configuração de parâmetros de "expiração" independentes para relatórios agregados e de eventos. Consulte aqui. Além disso, o Google Ads não vai receber janelas de relatórios especiais que outras adtechs não recebem pela API Attribution Reporting. |
| Mesma exigência de origem de relatórios | Solicitação para remover o requisito de que a origem do registro de origem seja igual à origem do registro da conversão | Sugerimos o uso de redirecionamentos HTTP para delegar o registro e resolver esse caso de uso. Agradecemos qualquer outro feedback sobre as novas orientações. |
| Acompanhamento de conversões | É necessário diferenciar se a conversão ocorreu antes/depois de determinadas horas definidas pelo anunciante | A API Attribution Reporting oferece suporte à definição de uma janela de expiração e prioridade para a atribuição de origem. Ao usar os dois, será tecnicamente possível atribuir uma conversão que ocorreu em uma janela de X dias separadamente de uma conversão que ocorreu após X. |
| Simulação de ruído | Solicitação para simular o volume diferente de conversões por bucket, para entender o impacto nos anunciantes com menos conversões | Estamos trabalhando para adicionar maneiras de simular isso em versões futuras do Noise Lab. Seu feedback é muito importante. |
| Relatórios em dispositivos móveis | O relatório ainda será enviado quando o Chrome estiver em execução em segundo plano no dispositivo móvel? | No momento, mesmo em dispositivos móveis, o relatório não é enviado quando o Chrome está em segundo plano. Isso provavelmente vai mudar quando a API for integrada ao Sandbox de privacidade do Android. Consulte aqui. O Sandbox de privacidade do Android não faz parte dos compromissos aceitos pela CMA. |
| Disponibilidade de dados | Preocupações de que o Google terá acesso adicional aos dados por meio das APIs do Sandbox de privacidade | Primeiro, o Google Ads não recebe acesso preferencial aos dados da API Attribution Reporting ou de outras APIs do Sandbox de privacidade. Esse problema também é abordado na seção "Feedback geral" em "Interoperabilidade", que inclui mais detalhes sobre os compromissos do Google. Em segundo lugar, sobre a diferença entre sites maiores e menores, o Google reconhece que as proteções de privacidade baseadas em ruído podem ter um impacto maior em fatias de dados menores. No entanto, há algumas mitigações possíveis: por exemplo, métodos como a agregação em períodos mais longos resolveriam esse problema. No entanto, ainda não está claro se as conclusões baseadas em fatias de dados muito pequenas (como uma ou duas compras) são significativas para os anunciantes. Durante o teste de origem, o Google incentivou os testadores a aproveitar a capacidade de experimentar uma ampla gama de parâmetros de privacidade e ruído para que eles pudessem fornecer feedback mais específico sobre esse problema. |
Limitar o rastreamento oculto
Redução do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adiar a redução do user agent até que o ecossistema da Web esteja mais pronto | Não há tempo suficiente para se adaptar às próximas mudanças na redução de user agents. | Tratamos esse feedback no relatório completo em "Preocupações dos interessados" na seção "Interação do Google com a CMA". |
| Adiar a redução do user agent até que o ecossistema da Web esteja mais pronto | Pedido para atrasar o lançamento da redução do user agent até que os user agents estruturados (SUA) sejam implantados | A equipe do Google Ads propôs a adição de user agent estruturado (consulte a especificação) ao OpenRTB em outubro de 2021, e ela foi incorporada à atualização da especificação 2.6 lançada em abril de 2022. Temos algumas evidências de que a SUA está implantada e disponível hoje, conforme demonstrado na postagem do blog da Scientia Mobile, que mostra como usar o UA-CH e a API WURFL para criar uma SUA. |
###
Dicas de cliente HTTP do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Testar o UA-CH com outras técnicas de rastreamento anti-cobertor | Orientações sobre como testar todas as APIs do Sandbox de privacidade e técnicas de fingerprinting propostas em conjunto de forma holística | Nosso plano de teste foi projetado para refletir os cronogramas assíncronos para desenvolver algumas das medidas anti-impressão digital, em oposição ao restante das propostas do Sandbox. Ele aborda a realidade de que algumas medidas anti-impressão digital (como o orçamento de privacidade, a proteção de IP e as mitigações de rastreamento de rejeições) só serão totalmente desenvolvidas e estarão prontas para lançamento na disponibilidade geral somente após a descontinuação dos cookies de terceiros. Embora essas medidas anti-impressão digital não sejam incluídas nos testes quantitativos, elas estão sujeitas a uma avaliação qualitativa com base nos fatos disponíveis no momento da suspensão. |
| (Também informado no 2º trimestre) Performance |
Preocupações sobre a latência de recebimento de dicas pelo Critical-CH (no primeiro carregamento da página) | Consulte a seção dedicada do UA-CH abaixo |
| Feedback insuficiente | O feedback do ecossistema sobre a mudança do UA-CH pode não ser suficiente, o que gera preocupações sobre a falta de conscientização do ecossistema. | Estamos compartilhando nossos planos de forma proativa para garantir um lançamento cuidadoso que minimize as interrupções. Os planos de redução de user agent e da API UA-CH foram apresentados ao Grupo da Comunidade de Antifraude do W3C em 18 de março de 2022 e ao Grupo de Trabalho de Pagamentos na Web e ao Grupo de Interesse de Segurança de Pagamentos na Web em 20 de janeiro de 2022. Nenhuma preocupação significativa foi levantada durante ou após as apresentações. O Google se envolveu proativamente com mais de 100 operadores de sites para receber feedback. Além disso, o Google também usou os canais do Blink-Dev para comunicar o lançamento da redução do user-agent publicamente com base no feedback das partes interessadas do ecossistema. |
| Tempo | Preocupações com o tempo de lançamento e a preparação do setor | Consulte a seção dedicada do UA-CH abaixo |
| Status da plataforma do Chrome | Solicitamos a atualização da página chromestatus para UA-CH. | A entrada chromestatus foi atualizada em 19 de dezembro para "Sinais mistos". |
Proteção de IP (anteriormente Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Ativar ou desativar | A privacidade do endereço IP é ativada ou desativada? | Nosso objetivo é oferecer proteção de IP a todos os usuários. Com esse objetivo em mente, estamos avaliando as opções de escolha do usuário para a Proteção de IP. |
| Caso de uso de endereço IP para dados próprios | É possível usar endereços IP para unir as jornadas dos usuários em domínios próprios após a Proteção de IP? | Como publicado anteriormente, a Proteção de IP vai se concentrar inicialmente no rastreamento no contexto de terceiros, o que significa que os domínios próprios não serão afetados. |
| Casos de uso de adtech | Como as empresas podem configurar medidas antifraude com a Proteção de IP? | Reconhecemos a importância do endereço IP como um indicador de esforços antifraude na Web atual. Como parte dos nossos compromissos com a CMA (parágrafo 20), afirmamos que não vamos implementar a Proteção de IP sem fazer esforços razoáveis para apoiar a capacidade dos sites de realizar esforços antispam e antifraude. Uma das nossas principais prioridades é entender como a Proteção de IP afeta os casos de uso e os recursos de detecção antifraude para que possamos investir mais em tecnologias de preservação de privacidade que ajudam as empresas a preservar a segurança da Web. Encorajamos o feedback e as contribuições para novas propostas com o objetivo de atender às necessidades das empresas de segurança e antifraude, mesmo que os indicadores mudem com o tempo. |
| Fraude e abuso | A proteção de IP inclui proteção contra negação de serviço (DoS)? | Temos o compromisso de melhorar a privacidade e manter a segurança da Web. A proteção contra ataques de negação de serviço é um caso de uso importante para evitar abusos. Esperamos minimizar o impacto das proteções contra DoS com o design da proteção de IP e com novas soluções antiabuso. Como a Proteção de IP é inicialmente focada em serviços incorporados de terceiros, algumas partes interessadas indicaram que ela deve ter um impacto limitado na proteção contra DoS para sites próprios. No entanto, continuamos pedindo feedback público para avaliar o risco de casos de uso de DoS, principalmente para serviços incorporados de terceiros. Em paralelo, estamos explorando mecanismos de feedback de abuso e bloqueio de clientes que permitiriam que um site ou serviço bloqueasse um usuário de spam sem identificá-lo. |
| Filtragem de conteúdo | Filtragem de conteúdo com proteção de IP | Empresas diferentes têm necessidades diferentes em relação à filtragem de conteúdo e à personalização da experiência do usuário. Muitos desses casos de uso não dependem de endereços IP e, portanto, não são afetados pela Proteção de IP. Por exemplo, um editor que quer personalizar o conteúdo e aumentar o engajamento pode usar cookies próprios ou cookies particionados de terceiros (CHIPs, na sigla em inglês) para entender os interesses de um usuário e as interações anteriores com o editor. Ou um parceiro de adtech focado em veicular o anúncio certo para o usuário certo pode incorporar o FLEDGE e a Topics, por exemplo, para gerar resultados de anúncios semelhantes aos que são gerados hoje com cookies de terceiros ou outras tecnologias de rastreamento entre sites. Também estamos desenvolvendo novos recursos de preservação de privacidade na Proteção de IP, como a localização geográfica aproximada, para oferecer suporte à filtragem de conteúdo em que os mecanismos atuais podem ser insuficientes. Agradecemos mais feedback sobre casos de uso de filtragem de conteúdo que podem ser afetados pela Proteção de IP. |
| (Também informado no terceiro trimestre) Casos de uso de geolocalização |
A proteção de IP pode impedir que casos de uso legítimos de geolocalização funcionem no futuro, como a personalização de conteúdo com base em geolocalização. | Atualização do 4º trimestre: Estamos trabalhando com as partes interessadas para garantir que o Chrome continue a oferecer suporte a casos de uso legítimos de endereços IP. Estamos buscando feedback do ecossistema sobre a granularidade da geolocalização de IP aqui. |
proposta de orçamento de privacidade
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Documentação mais clara | Mais exemplos para que as partes interessadas possam prever como as coisas podem ser limitadas após a implementação do Orçamento de privacidade | A proposta de orçamento de privacidade ainda está em discussão e não foi implementada por nenhum navegador. A data mais próxima de disponibilidade escalonada representa a data mais próxima em que o Orçamento de privacidade pode ser aplicado. Isso não vai acontecer antes da remoção dos cookies de terceiros em 2024. No momento, não temos mais documentação para compartilhar. Vamos compartilhar mais detalhes sobre a proposta quando ela estiver mais finalizada. Enquanto isso, convidamos as partes interessadas a compartilhar qualquer feedback que ajude no desenvolvimento da proposta. |
Reforçar os limites de privacidade entre sites
Conjuntos próprios
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no terceiro trimestre) Limite de domínio | Pedido para expandir o número de domínios associados | Atualização do 4º trimestre: Lançamos o FPS para testes locais, incluindo um processo de envio de conjunto simulado no GitHub e uma flag para testar rSA e rSAFor localmente. Também realizamos duas reuniões abertas para desenvolvedores sobre FPS para continuar a responder a perguntas sobre casos de uso para o subconjunto associado. Recomendamos que os desenvolvedores testem a funcionalidade de FPS para fornecer feedback sobre como o limite de domínio do subconjunto associado afetaria a usabilidade de FPS nos casos de uso. Nas ligações do WICG, esclarecemos que o Chrome está comprometido em oferecer uma solução útil que também considera os interesses de privacidade dos usuários. Nesse sentido, gostaríamos de receber feedback da comunidade sobre casos de uso específicos que podem ser afetados pelo limite de domínio. Assim, a equipe pode considerar maneiras de resolver esses casos e continuar protegendo a privacidade dos usuários. |
| Solicitação de mais detalhes sobre as medidas de redução de abuso | O que acontece se um domínio for adicionado a um conjunto sem consentimento? | Publicamos as diretrizes de envio de conjuntos próprios neste link em 2 de dezembro de 2022. Conforme explicado nas diretrizes de envio, qualquer gerenciamento de mudança de conjunto vai seguir e respeitar um processo de validação no GitHub, incluindo a validação da propriedade, o que deve reduzir esse risco. |
| Mitigação de abuso | Preocupação de que as formações de conjuntos próprios possam ser exploradas | Estamos buscando maneiras de ampliar as verificações técnicas para tipos de subconjuntos e queremos receber mais feedback da comunidade aqui. |
| Casos de uso de anúncios | Perguntas sobre se os conjuntos próprios precisam ser usados para oferecer suporte à segmentação de anúncios | Não estamos tentando oferecer suporte a casos de uso de segmentação de anúncios para conjuntos próprios. Recomendamos usar as APIs do Google Ads disponíveis para esses casos. |
| Política (também informada no 3º trimestre) | Preocupação de que o FPS não é consistente com os compromissos do CMA em relação à "Legislação aplicável de proteção de dados", com base no fato de que o GDPR não impõe um limite ao número de sites em um conjunto, enquanto o FPS prevê um limite de 3 | Nossa resposta não mudou em relação à pergunta 3: "O Google continua se comprometendo com o CMA a projetar e implementar as propostas do Sandbox de privacidade de uma maneira que não distorça a concorrência com a autoreferência do próprio negócio do Google e a considerar o impacto na concorrência na publicidade digital, editores e anunciantes, bem como o impacto nos resultados de privacidade e conformidade com os princípios de proteção de dados, conforme estabelecido na legislação aplicável de proteção de dados. A preocupação expressa não revela nenhuma incompatibilidade com o GDPR. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho esteja em conformidade com esses compromissos". |
| Proposta alternativa | Conjuntos validados do GDPR | Além do feedback fornecido pelo ecossistema sobre a proposta de adotar "conjuntos validados do GDPR", o Chrome tem preocupações sobre as seguintes limitações dessa proposta alternativa:
Desde que essa alternativa foi apresentada, o Chrome atualizou a proposta de conjuntos próprios e publicou diretrizes de envio para criar novos conjuntos. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Restrições de frames cercados durante a OT | Quais são as restrições atuais em relação a Fenced Frames para o período de teste de origem? | Estamos trabalhando na documentação sobre as restrições e o status de implementação e planejamos compartilhar isso no primeiro trimestre de 2023. |
| Vários anúncios em um único frame limitado | Solicitação para mostrar vários anunciantes em um frame restrito em um leilão | No momento, esse pedido não está sendo desenvolvido ativamente, mas aceitamos mais feedback se os participantes do ecossistema considerarem o recurso importante. |
| Pacotes da Web | Quais são os requisitos e o suporte planejados para pacotes da Web com frames restritos? | No momento, não temos uma atualização sobre se esse será o requisito no futuro. Todas as mudanças seriam anunciadas com antecedência e não seriam aplicadas antes da descontinuação dos cookies de terceiros. Consulte este texto para saber o status atual. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Armazenamento compartilhado para AdTech | Incerteza sobre o uso de armazenamento compartilhado para casos de uso de adtechs | A API Shared Storage e a API Private Aggregation podem ser usadas para diferentes tipos de medição que precisam de medição de armazenamento entre sites. Confira alguns exemplos aqui. Prevemos que os provedores de soluções de DSP e medição serão os principais integradores para casos de uso de anúncios. |
CHIPs
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 3º trimestre) Requisito de partição | Adicionamos um requisito de comportamento explícito para o atributo "Partitioned" em cookies próprios. | Atualização do 4º trimestre: Depois de discussões no GitHub e nas chamadas do PrivacyCG, o comportamento que alinhamos é que os cookies particionados definidos em cookies primários vão usar uma chave de partição de (A,A), em que "A" é o site de nível superior. Vamos documentar esse comportamento na explicação e especificação. |
| Gerenciamento de cookies | Existem ferramentas para gerenciar/controlar cookies próprios ou de terceiros? | O Chrome DevTools e o NetLog podem ser usados para testar sites com o bloqueio de cookies de terceiros ativado. Ambas as ferramentas informam quando os cookies são bloqueados devido à configuração do usuário. Agradecemos o feedback sobre os tipos de sites de auditoria que você gostaria de ver. |
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| O IdP exige conhecimento do RP para permitir uma sessão | Problema quando um usuário tenta fazer login no IdP do Feide de dois RPs diferentes | Estamos discutindo possíveis soluções para esse problema. |
| Interoperabilidade | Preocupações sobre o impacto do FedCM na relação entre os usuários e os sites em que eles fazem login usando o FedCM e a "interoperabilidade" entre sites | O objetivo do FedCM é continuar oferecendo suporte a serviços de identidade federada que dependem de cookies de terceiros, uma vez que eles serão removidos do Chrome. Esperamos que o FedCM seja apenas uma opção disponível para esses serviços. Os provedores de identidade (IdPs) e as partes confiáveis (RPs) podem usar outras tecnologias que atendam melhor às necessidades deles. Parece que as preocupações com a relação entre usuário e RP e a "interoperabilidade" se devem a um mal-entendido da proposta do FedCM. O FedCM permite que os IdPs decidam quais informações compartilhar com um RP e em que formato, depois que o usuário escolhe fazer login no site desse RP. O FedCM não exige que os IdPs "criem um identificador pseudônimo exclusivo para cada [RP] com que o usuário faz a autenticação". Em vez disso, o FedCM está aberto para que cada IdP escolha se quer compartilhar o identificador real do usuário, uma versão por site desse identificador ou alguma outra versão dessas informações. A especificação FedCM identifica a correlação entre sites como um risco de privacidade associado à API e discute identificadores direcionados (por site) como uma possível mitigação. No entanto, a decisão de usar identificadores direcionados é deixada para os IdPs, não imposta pelo navegador. A FedCM também já oferece a escolha do usuário em relação à identidade. Por exemplo, se um usuário tiver várias identidades com o mesmo IdP (por exemplo, um perfil de trabalho e um perfil pessoal), o FedCM vai permitir que o usuário selecione qual identidade quer usar para fazer login no site do RP. Além disso, cada RP decide por si mesmo quais provedores de identidade vai oferecer suporte no site. Um aspecto dessa decisão é considerar o mecanismo em que um IdP se baseia, seja o FedCM ou uma tecnologia diferente. Novamente, o navegador não determina essas escolhas para RPs ou IdPs. |
Combater spam e fraudes
API Private State Tokens
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Como lidar com bots | O que acontece se o emissor descobrir que os tokens de estado particular foram emitidos para bots? | Para evitar que os tokens emitidos para bots permaneçam no ecossistema por muito tempo, os emissores precisam alternar as chaves usadas para assinar tokens regularmente. Assim, os tokens antigos emitidos com uma lógica de emissão potencialmente corrompida expiram e os sites resgatam tokens mais recentes com a lógica de emissão atualizada. |
| Envios de formulários no mesmo site | É possível usar tokens de estado particular para envios de formulários no mesmo site que envolvem navegação em toda a página (ou seja, Content-Type: application/x-www-form-urlencoded) em vez de uma solicitação das APIs fetch/XMLHttpRequest? | No momento, isso não é possível na primeira versão dos tokens de estado particular. Agradecemos o feedback do ecossistema se houver uma grande demanda por esse caso de uso. |
| Verificação do lado do servidor | Perguntas sobre se os tokens de estado particular podem ser verificados no servidor | Os tokens são resgatados com o emissor, que cria um registro de resgate que pode conter o próprio token ou algum valor assinado derivado dele. Os servidores podem usar esse registro de resgate para verificar a autenticidade do token. Esperamos que diferentes ecossistemas de emissores apresentem padrões diferentes para interpretar os registros de resgate. |