Relatório trimestral do quarto trimestre de 2022 resumindo o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.
Como parte do compromisso com a CMA, o Google concordou em fornecer relatórios trimestrais sobre o processo de engajamento das partes interessadas para as propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo do feedback do Sandbox de privacidade são gerados agregando o feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral de feedback, incluindo, mas não se limitando a: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe o feedback recebido do ecossistema e está explorando ativamente maneiras de integrar os aprendizados às decisões de design.
Os temas de feedback são classificados por prevalência por API. Isso é feito agregando a quantidade de feedback que a equipe do Chrome recebeu sobre um determinado tema e organizando em ordem decrescente de quantidade. Os temas de feedback mais comuns foram identificados com a revisão dos tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), o feedback direto, o GitHub e as perguntas mais frequentes que surgiram pelas equipes internas do Google e formulários públicos.
Mais especificamente, as atas de reuniões de órgãos padrão da Web foram analisadas e, para feedback direto, foram considerados os registros do Google de reuniões individuais com as partes interessadas, os e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público. Em seguida, o Google coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas que surgiam em relação a cada API.
As explicações das respostas do Chrome ao feedback foram desenvolvidas a partir de perguntas frequentes publicadas, respostas reais feitas a problemas levantados pelas partes interessadas e determinação de uma posição específica para os fins deste exercício de geração de relatórios públicos. Refletindo o foco atual de desenvolvimento e testes, as perguntas e o feedback foram recebidos principalmente em relação às APIs Topics, Fledge e Attribution Reporting.
Talvez os feedbacks recebidos após o fim do período do relatório atual ainda não tenham uma resposta do Chrome considerada.
Glossário de siglas
- ÍCONES
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos primários
- IAB
- Interactive Advertising Bureau
- IdP
- Provedor de identidade
- IETF
- Força Tarefa de Internet Engineering
- PI
- Endereço Protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste de origem
- PatCG
- Grupo da comunidade de tecnologia de publicidade privada
- RP
- Parte confiável
- SSP
- Plataforma de fornecimento
- TEE
- Ambiente de execução confiável
- UA
- String do user agent
- UA-CH
- Dicas de cliente HTTP do user agent
- W3C
- World Wide Web Consortium
- WIPB
- Deficiência de IP intencional
Feedback geral, sem API/tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 3o trimestre) Utilidade para diferentes tipos de partes interessadas |
Preocupações de que as tecnologias do Sandbox de privacidade favorecem desenvolvedores maiores e de que sites de nicho (menores) contribuem mais do que sites genéricos (maiores) | Nossa resposta não mudou em relação ao 3o trimestre: "O Google se comprometeu com a CMA a criar e implementar as propostas do Sandbox de privacidade que não distorçam a concorrência ao dar preferência à própria empresa do Google e considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes, seja qual for o tamanho deles. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos. À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é o desempenho das novas tecnologias para diferentes tipos de partes interessadas. O feedback é fundamental nesse sentido, especialmente feedback específico e útil que pode 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 observação sobre o design do experimento para dar mais informações aos participantes do mercado e uma oportunidade de comentar sobre as abordagens propostas. |
| (Também informado no 3o trimestre) Solicitações de documentação |
Pedidos de mais recursos detalhando como gerenciar testes, análises e implementações | Atualização do quarto trimestre: Agradecemos o fato de os desenvolvedores considerarem nosso material útil e continuamos comprometidos a oferecer mais material para que eles possam entender como as novas tecnologias podem funcionar para eles. No trimestre passado, adicionamos a seção "Notícias e atualizações" ao site privacysandbox.com e publicamos uma análise detalhada sobre 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 para desenvolvedores em que compartilhamos práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produtos e engenharia para discussões e perguntas ao vivo. |
| Core Web Vitals | Como a latência da API do Sandbox de privacidade afeta as Core Web Vitals? | Reduzir a latência é o objetivo principal do design das APIs do Sandbox de privacidade. Nossa expectativa atual é que a latência da API tenha um impacto mínimo nas Core Web Vitals, já que a maioria das APIs é chamada após a renderização inicial. Continuamos monitorando e fazendo melhorias para reduzir ainda mais a latência de cada uma das APIs, além de incentivar 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 relacionadas à interoperabilidade com outras possíveis soluções | O objetivo do Sandbox de privacidade é proteger os usuários contra o rastreamento entre sites e, ao mesmo tempo, atender às necessidades do ecossistema da Web. Para fazer isso, deixamos de usar tecnologias legadas de navegador que permitem esse tipo de rastreamento entre sites, como cookies de terceiros, e disponibilizamos novas tecnologias criadas especificamente para oferecer suporte 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 colocam restrições técnicas à capacidade de um site de compartilhar ou processar dados depois de coletados do navegador. Portanto, as tecnologias não impedem que as empresas firmem contratos de "gerenciamento de dados" ou qualquer outra relação contratual semelhante. Da mesma forma, eles não restringem a capacidade dos usuários de consentir com o compartilhamento de dados por outros meios. Para fins de esclarecimento, o Google se comprometeu a aplicar as tecnologias do Sandbox de privacidade da mesma forma a todos os sites, incluindo os produtos e serviços do Google. Depois que o Chrome não for mais compatível com cookies de terceiros, os compromissos também deixam claro que o Google não usará outros dados pessoais, como o histórico de navegação sincronizado do Chrome, para rastrear usuários para segmentação ou medição de publicidade digital. |
Mostre conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Impacto na classificação da Pesquisa Google | Investigar se o suporte à API Topics de um site vai ser usado como um possível indicador 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 solicitou à organização da Pesquisa que use a classificação de páginas como um incentivo para que os sites adotem a API Topics. O Google confirmou à CMA que a Pesquisa Google não vai usar a decisão de um site de desativar a API Topics como 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 Tópico de uma página da web, a fim de 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 no nível da página (como todos ou alguns componentes do URL e/ou conteúdo da página) na classificação da API Topics. Quaisquer melhorias de utilidade devem ser ponderadas em relação aos riscos de privacidade e de abuso. Por exemplo, com relação a metadados específicos, 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 para ganhos financeiros; - Sites que modificam dinamicamente metadados no nível da página como um método de rastreamento entre sites |
| (Também informado no 3o trimestre) Impacto nos indicadores próprios |
O indicador de temas pode ser muito valioso e, como resultado, desvaloriza outros indicadores próprios com base em interesses. | Nossa resposta não mudou em relação ao 3o trimestre: "Acreditamos que a publicidade com base em interesses é um caso de uso importante para a Web, e a API Topics foi criada para oferecer suporte a esse caso. Conforme descrito [no relatório do 3o trimestre], outras partes interessadas do ecossistema expressaram preocupações de que a API Topics não é útil o suficiente para agregar 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." |
| Atualizar taxonomia | Como a lista de taxonomia será atualizada? | Queremos receber feedback sobre a taxonomia que seria 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 ativamente várias abordagens para atualizar a taxonomia. Por exemplo, o Chrome pode usar uma noção de valor comercial para cada tema a fim de determinar qual categoria incluir em iterações futuras. |
| Desempenho do classificador regional de temas | O classificador de tópicos tem baixo desempenho em domínios regionais | A melhoria no classificador é um esforço contínuo. Com base no feedback que recebemos, uma possibilidade é expandir a lista de substituição de temas. De acordo com nossa análise, isso vai aumentar a cobertura global e a precisão. Para explicar, a classificação da API Topics tem dois componentes relevantes: (1) uma lista de substituição que contém os 10 mil sites principais e os temas deles e (2) um modelo de ML no dispositivo que classifica nomes de host em temas. Ao expandir a lista de substituição (1), podemos melhorar o desempenho da classificação nas regiões em que o classificador pode ter um desempenho insatisfatório. |
| Período de uma semana | O período de uma semana é muito longo para os usuários que desejam tomar decisões de curto prazo. | Estamos analisando qual seria a duração adequada do período e agradecemos mais feedback sobre qual seria uma época melhor para o ecossistema. |
| Recuperação de cabeçalhos HTTP | Preocupação de que não há informações suficientes sobre a recuperação do cabeçalho HTTP de temas | Estamos trabalhando nos cabeçalhos e no fetch(). Também temos informações disponíveis aqui. Também adicionamos informações de skipObservation à explicação. |
| A API Topics só tem como objetivo ajudar anunciantes, não usuários | A API Topics/Sandbox de privacidade parece ser uma abordagem focada no setor. O benefício para os usuários não é tão claro quanto o benefício para o setor. | Acreditamos que o benefício para os usuários é que a API Topics é compatível com anúncios com base em interesses que mantêm a Web livre e aberta. Além disso, acreditamos que melhora 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 piores que são menos particulares, não são transparentes e não são realistas, redefiníveis ou controladas pelos usuários. Muitas empresas estão testando as APIs Topics e Sandbox, e temos o compromisso de oferecer ferramentas para promover a privacidade e oferecer suporte à Web. O grupo de arquitetura técnica do W3C publicou recentemente a visualização inicial sobre a API Topics, que vamos responder publicamente. Como o Google recebeu perguntas do ecossistema sobre o que essa avaliação pode implicar para o desenvolvimento e o lançamento da API Topics, queremos reafirmar nosso plano de disponibilizá-la no Chrome Stable este ano. Embora o Google agradeça a contribuição do Grupo de arquitetura técnica do W3C, ele considera de suma importância continuar os esforços de desenvolvimento e teste da API Topics em consulta com a CMA e o ecossistema. |
| Vazamento de dados | Preocupação com o possível vazamento da API Topics para outros sites sem permissão. | O design da API Topics torna bastante improvável que os dados de um único editor (e até mesmo de um grupo menor de editores) possam vazar de alguma forma. Os sites dos editores também têm controle total sobre a API Topics e podem proibir o acesso a essa API com uma política de permissões. |
| Falta de anunciantes para testes | Os editores estão preocupados por não conseguirem demonstrar o valor da API Topics para os anunciantes no momento. | 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 sobre o valor da API Topics para anunciantes. O teste e a publicação dos resultados serão supervisionados pela CMA, que analisará os dados, a análise e a metodologia. Incentivamos o ecossistema a compartilhar feedback com o Google e a CMA. |
| Topics e FLEDGE | Peça mais informações sobre como usar as Topics na lógica de lances do FLEDGE. | É possível usar a API Topics na lógica de lances do FLEDGE. Um guia de integração também está em andamento e incluirá detalhes adicionais sobre a implementação. |
| Classificação personalizada para o autor da chamada de temas | Permitir que as classificações sejam personalizadas pelo autor da ligação | O desafio com a classificação ou os valores de temas personalizados para cada adtech é que isso pode ser um mecanismo para influenciar os temas retornados, ou seja, um vetor de impressão digital. |
| Lista de prioridade do autor da chamada de temas | Permitir que os autores das 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 com mais detalhes e aceitamos sugestões adicionais. |
FLEDGE
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Google Ad Manager | Preocupação de que o Google Ad Manager é o decisivo 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 dos vendedores de componentes e de nível superior. 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 um lance. |
| Não há participantes suficientes testando o FLEDGE | Pedir para incentivar mais empresas a testar o FLEDGE, por exemplo, melhorando a funcionalidade da API e desencorajando alternativas que invasivas à privacidade, como a impressão digital | O Sandbox de privacidade está avançando em etapas, em parceria com a orientação da CMA e do ICO. Os testes funcionais do FLEDGE demonstraram a estabilidade e a capacidade necessárias. 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 o FLEDGE e outras APIs podem oferecer suporte a casos de uso críticos no 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 abranger o rastreamento (consulte UA-CH, Proteção de IP e Mitigações de rastreamento de rejeições) e vão continuar evoluindo com o tempo. O objetivo do Google não é tornar o FLEDGE a única solução de segmentação viável, mas continua comprometido em trabalhar em parceria com o setor e reguladores para implementar 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 de aprendizado de máquina para treinar algoritmos de lances de leilão vão ser compatíveis com o FLEDGE e os Relatórios de atribuição | Reconhecemos a necessidade de 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, Maximizar a Relevância do anúncio, discute como o setor de publicidade pode aproveitar esses indicadores para o aprendizado de máquina, e planejamos continuar publicando essa orientação daqui para frente. |
| Como consultar o servidor de chave-valor (K/V) do FLEDGE | Por que o servidor K/V pode ser consultado publicamente? | O servidor K/V tem como objetivo fornecer indicadores em tempo real aos leilões do FLEDGE. Dessa forma, o servidor K/V precisa estar acessível de onde esses leilões do FLEDGE são realizados, que é em dispositivos de usuários, exigindo que ele esteja disponível publicamente. Um valor armazenado no servidor K/V só pode ser recuperado por uma parte que já tem a chave dela. Portanto, se uma adtech só fornecer as chaves a navegadores que estão no grupo de interesse e não usar chaves que possam ser adivinhadas aleatoriamente, somente os navegadores que precisam do valor para executar o leilão poderão recuperá-lo. |
| Como fazer a segmentação por data/hora? | Suporte a objetos de data na função de lógica de lances. | Há várias maneiras de fazer isso. Os compradores podem pedir que o vendedor informe a data e a hora atuais, e deve ser fácil para os vendedores fornecerem essas informações a 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 informar a data e a hora como parte da resposta contextual deles 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 via FLEDGE ou soluções alternativas. | Os usuários podem desativar as APIs de anúncios no Chrome. No caso de anúncios específicos, a adtech relevante é a melhor opção para oferecer controles sobre quais criativos são exibidos ou como eles são selecionados. |
| Cronogramas mais claros | Peça mais informações sobre a disponibilidade de proteções de privacidade no FLEDGE, como a exigência de Fenced Frames. | Planejamos publicar cronogramas mais detalhados no primeiro trimestre. |
| Confusão com relatórios | Peça mais esclarecimentos sobre como os relatórios do FLEDGE vão funcionar com outras APIs, como Fenced Frames e a API Private Aggregate. | Planejamos publicar uma explicação sobre a interação entre a API Private Aggregate, o FLEDGE e Fenced Frames nas próximas semanas. |
| Lances em tempo real e FLEDGE | Orientações sobre como o FLEDGE se integra aos lances padrão em tempo real. | Os dois principais fatores que complicam a capacidade de uma adtech de fazer lances em tempo real são o acesso a dados no nível do evento e a integração mais fácil com ARA. Planejamos enviar atualizações e explicações sobre ambos no primeiro trimestre. |
| Performance dos leilões do FLEDGE | Relatório dos testadores que os leilões do FLEDGE têm alta latência | Agradecemos as denúncias dos testadores que compartilharam os resultados e casos de uso e compartilhamos algumas sugestões sobre como melhorar o desempenho do FLEDGE. Paralelamente, adicionamos ferramentas ao navegador. Com elas, os desenvolvedores podem diagnosticar melhor o que está deixando os leilões lentos. Além disso, temos abordado 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 bidders, uma maneira de reutilizar os workers do FLEDGE para evitar o pagamento de custos de inicialização, e 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 uma conversa contínua entre os desenvolvedores do Chrome e os testadores do FLEDGE com base na experiência real deles com a API. |
| Limite de memória de tamanho do grupo de interesse | Solicitação para aumentar o limite do tamanho de um único grupo de interesse de 50 KB. | Estamos analisando o pedido e aguardamos feedback sobre qual valor limite funciona. |
| Combinar os dados veiculados pelo FLEDGE com o cookie primário | 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 de um anunciante. No entanto, o objetivo do FLEDGE não é ajudar um anunciante a descobrir o comportamento de navegação de um usuário em nenhum site que não seja o próprio anunciante. Anexar o comportamento de navegação fora do site aos dados próprios é contrário aos objetivos do Sandbox de privacidade. Nas próximas semanas, vamos compartilhar guias de integração com mais detalhes sobre como o FLEDGE vai oferecer suporte à integração com dados próprios. |
| Valor de K-anonimato | Como o valor de "K" para "k-anon" será decidido e a publicação dele será feita? | O valor "K" ainda está sendo finalizado e compartilharemos mais informações à medida que nossos planos forem desenvolvidos. Temos interesse em saber mais sobre como um valor de k desconhecido pode atrapalhar a preparação para o FLEDGE e o escopo do treinamento do modelo de ML. Agradecemos seu feedback sobre esse assunto. |
| Compatibilidade com várias SSPs | Como várias SSPs vão ter suporte no FLEDGE? | O FLEDGE oferece suporte a leilões de vários vendedores, conforme observado nesta proposta. |
| Visibilidade da lógica de lances | Preocupação com a exposição da lógica de lances de DSP em JavaScript | Com a lógica de lances atual, o JavaScript pode ser acessado por outras pessoas, mas queremos receber mais feedback sobre por que isso pode ser uma fonte de preocupação para DSPs. |
| prebid.js | Qual é o cronograma de compatibilidade com o prebid.js no FLEDGE? | Apenas as versões 7.14 e mais recentes do Prebid.js oferecem suporte ao módulo do FLEDGE. Os editores interessados em testes precisam adicionar o módulo do 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 (UDF) serão compatíveis com o FLEDGE? São funções que podem ser programadas pelos usuários finais para ampliar a funcionalidade da API. | Acesse a explicação aqui. Essas análises ainda estão sendo desenvolvidas, por isso convidamos outros feedbacks sobre os casos de uso. |
| Restrição da mesma origem em recursos do grupo de interesse | Solicitação para relaxar a restrição de mesma origem nos recursos do grupo de interesse para permitir determinados casos de uso de adtech. | 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 determinadas explorações por invasores, conforme explicado aqui. |
| Propriedade da interestGroup | Solicitação para limitar se uma adtech pode usar o join InterestGroup para os mesmos grupos de interesse em sites | Nosso foco está em como os públicos-alvo são usados, não em como eles são criados. Estamos discutindo possíveis abordagens aqui e aceitamos outras opiniões. |
| Validade da chave do servidor de chave-valor | Discussão sobre a remoção das chaves do servidor quando os grupos de interesse correspondentes expirarem | Estamos estudando maneiras de lidar com a expiração da chave e queremos receber seu feedback neste link. |
Medir os anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Tráfego do teste de origem | O tráfego atual do teste de origem não é suficiente para realizar testes de utilitário. | Os testes de origem atuais foram criados para que os jogadores do ecossistema conduzam testes funcionais para garantir que a API esteja funcionando conforme o esperado. Entendemos que uma grande quantidade de tráfego vai ser necessária para realizar testes de utilidade quando o desenvolvimento das várias APIs do Sandbox de privacidade estiver mais maduro. O cronograma de testes atual prevê que isso ocorrerá na disponibilidade geral, ou seja, quando as tecnologias dos casos de uso serão lançadas para 100% do tráfego do Chrome no terceiro trimestre de 2023 (consulte nosso cronograma atualizado em privacysandbox.com). Gostaríamos de receber qualquer feedback adicional sobre testes de casos de uso que exijam tráfego adicional. |
| Sobreposição de funcionalidades de diferentes APIs de medição do Sandbox de privacidade | As preocupações sobre a sobreposição de várias abordagens de medição com o Sandbox de privacidade aumentarão a complexidade, por exemplo, a API Attribution Reporting e a API Private agregação. | Estamos trabalhando em uma documentação melhor para esclarecer os diferentes casos de uso das APIs e receberemos mais feedback sobre quais áreas não têm explicação. Por exemplo, a API Attribution Reporting oferece suporte específico à medição de conversões, enquanto a API Private agregação e o Armazenamento compartilhado são APIs de uso geral destinadas a oferecer suporte a uma variedade maior de casos de uso de medição entre sites. |
| Tentar novamente a solicitação de relatório com falha | Esclarecimento de quantas vezes uma solicitação de relatório é tentada se falhar. | Temos orientações publicadas sobre isso. Resumindo, os relatórios são enviados somente quando o navegador está em execução/on-line. Após a primeira falha no envio, uma nova tentativa é feita após cinco minutos. Após a segunda falha, uma nova tentativa será realizada após 15 minutos. Depois disso, o relatório não é enviado. |
| Atraso na geração de relatórios | Qual é o atraso esperado na geração de relatórios? | Queremos receber mais feedback do ecossistema sobre os atrasos nos relatórios, à medida que coletamos dados para avaliar melhor esses atrasos em paralelo. |
| Pré-renderizar páginas | A atribuição ARA funcionará em páginas pré-renderizadas? | O registro de atribuição é adiado em páginas pré-renderizadas até a ativação (o clique ou a visualização reais ocorre). Isso significa que vamos adiar o ping da solicitação `attributionsrc`. |
| Medir o Conversion Lift | Como medir o Conversion Lift com testes AB no mesmo domínio | Os sites podem medir o Conversion Lift com testes A/B no mesmo domínio usando Relatórios de atribuição. Eles podem codificar os parâmetros A/B como chaves usando a API agregada e receber relatórios resumidos sobre os valores de conversão nesses intervalos de chaves. |
| (Também informadas no 3o trimestre) Conversões de vários domínios | Como acompanhar as conversões em vários domínios, como aqueles com dois ou mais destinos | Atualização do quarto trimestre: Publicamos uma proposta para remover a restrição de destino da página de destino que permite o acompanhamento de conversas entre domínios. Esta proposta foi implementada. |
| (Também informado no 3o trimestre) Configuração de vencimento no relatório de conversão |
Solicitação de suporte ao filtro de relatório / expiração por menos de 24 horas | Atualização do 4o trimestre: Compartilhamos essa solicitação de envio que vai separar as janelas de expiração e geração de relatórios para reduzir o atraso na geração de relatórios e a expiração da conversão. Esse recurso foi lançado na versão M110. |
| Fraude e abuso | Solicitações de anunciantes e profissionais de marketing para dividir e agregar dados com base nos sites de editores em que os anúncios são veiculados, o que também forneceria mais informações sobre possíveis práticas fraudulentas de anúncios. | Esse feedback está sendo discutido aqui , e aceitamos outras opiniões. |
| (Também informado no 3o trimestre) Atraso no relatório no nível do evento | O atraso de 2 a 30 dias nos relatórios de eventos pode ser muito longo para certos casos de uso. | Os relatórios no nível do evento têm janelas padrão de 2, 7 e 30 dias. Isso pode ser modificado usando o parâmetro "expiry". As adtechs podem configurar a data de validade para, no mínimo, um dia e receber possíveis relatórios em menos de dois dias. Para proteger a privacidade, limitamos a granularidade das datas de validade a um dia, já que relatórios mais detalhados podem causar ataques de tempo. Além disso, permitimos a configuração de parâmetros de "validade" independentes para relatórios agregados e no nível do evento. Acesse este link. Além disso, o Google Ads não recebe janelas de relatórios especiais que outras adtechs não recebem pela API Attribution Reporting. |
| Mesmo requisito de origem de relatórios | Solicitação de remoção do requisito de origem do registro da fonte ser igual à origem do registro da conversão | Propomos o uso de redirecionamentos HTTP para delegar o registro e resolver esse caso de uso. Gostaríamos de receber qualquer feedback adicional 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 à configuração de uma janela de expiração e prioridade para a atribuição de fonte. Usando ambas, tecnicamente será possível atribuir uma conversão que ocorreu dentro de X dias separadamente de uma conversão ocorrida depois de X. |
| Simulação de ruído | Peça para simular os diferentes volumes de conversões por grupo e entender o impacto nos anunciantes com menos conversões | Queremos adicionar maneiras de simular isso em versões futuras do Noise Lab. Gostaríamos de receber seu feedback. |
| Relatórios em dispositivos móveis | O relatório ainda será enviado quando o Chrome estiver sendo executado 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. É provável que isso mude quando a API for integrada ao Sandbox de privacidade do Android. Acesse este link. O Sandbox de privacidade do Android não faz parte dos compromissos aceitos pelo CMA. |
| Disponibilidade de dados | Preocupações com o fato de 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. Segundo, na 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 frações de dados menores. No entanto, há algumas mitigações possíveis. Por exemplo, métodos como a agregação durante períodos mais longos resolveriam esse problema. Sendo assim, não está claro se as conclusões baseadas em frações de dados muito pequenas (como uma ou duas compras) são significativas para os anunciantes. Durante o teste de origem, o Google incentivou os testadores a testar uma ampla variedade de parâmetros de privacidade e ruído para fornecer feedback mais específico sobre esse problema. |
Limitar o rastreamento verso
Redução do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Atrasar 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 do user agent. | Analisamos esse feedback no relatório completo, em "Preocupações das partes interessadas", na seção "Interação do Google com a CMA". |
| Atrasar a redução do user agent até que o ecossistema da Web esteja mais pronto | Peça para atrasar o lançamento da redução de user agent até que os user agents estruturados (SUA, na sigla em inglês) sejam implantados | A equipe do Google Ads propôs a adição do user agent estruturado (consulte a especificação) ao OpenRTB em outubro de 2021, e ela foi incorporada na atualização da especificação 2.6 lançada em abril de 2022. Temos algumas evidências de que o SUA foi implantado e está disponível hoje, conforme demonstrado na postagem do blog da Scientia Mobile (link em inglês) que demonstra como usar a UA-CH e a API WURFL para criar um SUA. |
###
Dicas de cliente HTTP do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Teste o UA-CH com outras técnicas de rastreamento anti-oculta | Orientações sobre como testar todas as APIs do Sandbox de privacidade e técnicas de impressão digital propostas em uma abordagem holística | Nosso plano de testes foi projetado para refletir os cronogramas assíncronos para o desenvolvimento de algumas medidas antiimpressão digital em oposição ao restante das propostas de sandbox. Ela aborda a realidade de que algumas medidas antiimpressão digital (por exemplo, Orçamento de privacidade, Proteção de IP e Mitigações de rastreio por redirecionamento) só estarão totalmente desenvolvidas e prontas para lançamento em disponibilidade geral após a descontinuação dos cookies de terceiros. Embora essas medidas antiimpressão digital não sejam incluídas nos testes quantitativos, elas vão passar por uma avaliação qualitativa com base nos fatos disponíveis no momento da paralisação. |
| (Também informado no 2o trimestre) Performance |
Preocupações com a latência de receber dicas via CHC (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 da UA-CH pode não ser suficiente, levando a preocupações sobre a falta de reconhecimento do ecossistema. | Estamos compartilhando nossos planos proativamente para garantir um lançamento cuidadoso que minimize as interrupções. Os planos de redução do user agent e a API UA-CH foram apresentados ao grupo comunitário 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 interagiu proativamente com mais de 100 operadores de sites para coletar feedback. Além disso, o Google também usou os canais Blink-Dev para comunicar publicamente o lançamento da redução do user agent com base no feedback das partes interessadas do ecossistema. |
| Cronograma | Preocupações relacionadas ao momento do lançamento e à preparação do setor | Consulte a seção dedicada do UA-CH abaixo |
| Status da plataforma do Chrome | Foi solicitada a atualização da página chromestatus do UA-CH | A entrada chromestatus foi atualizada em 19 de dezembro para "Indicadores mistos". |
Proteção de IP (antigo Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Ativar ou desativar o recurso | A privacidade do endereço IP é ativada ou desativada? | Nosso objetivo é oferecer a 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 proteção de IP. |
| Caso de uso de endereço IP para dados próprios | É possível usar endereços IP para agrupar as jornadas do usuário em domínios próprios após a proteção de IP? | Conforme publicado anteriormente, a proteção de IP se concentrará inicialmente no acompanhamento 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 estabelecer medidas antifraude com a Proteção de IP? | Reconhecemos a importância do endereço IP como um indicador para as iniciativas contra fraudes na Web atual. Como parte dos nossos compromissos com a CMA (parágrafo 20), informamos que não vamos implementar a Proteção de IP sem fazer esforços razoáveis para apoiar a capacidade dos sites de realizar iniciativas antispam e antifraude. Uma das nossas principais prioridades é entender como a Proteção de IP afeta os casos de uso antifraude e os recursos de detecção, para que possamos investir mais em tecnologias de preservação da privacidade que ajudam as empresas a preservar a segurança na Web. Incentivamos o feedback e aprovamos novas propostas que visam atender às necessidades das empresas de segurança e antifraude, mesmo que os indicadores mudem ao longo do 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 Web segura, e a proteção contra ataques de negação de serviço é um caso de uso antiabuso importante a ser desenvolvido. Queremos minimizar o impacto nas proteções contra DoS pelo design da Proteção de IP e por novas soluções antiabuso. Como a Proteção de IP é focada inicialmente em serviços incorporados de terceiros, algumas partes interessadas indicaram que ela deve ter impacto limitado na proteção contra DoS para sites próprios. No entanto, continuamos pedindo feedback público para avaliar o risco aos casos de uso de DoS, especialmente para serviços incorporados de terceiros. Paralelamente, estamos testando mecanismos de abuso de feedback e de bloqueio de clientes que permitiriam a um site ou serviço bloquear um usuário com spam sem identificá-lo. |
| Filtragem de conteúdo | Filtragem de conteúdo com a Proteção de IP | Diferentes empresas têm diferentes necessidades 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 gerar mais engajamento pode usar cookies primários ou particionados de terceiros (CHIPs, na sigla em inglês) para entender os interesses do usuário e as interações anteriores com o editor. Ou um parceiro de adtech com foco em veicular o anúncio ideal para o usuário ideal pode incorporar a API Topics e o FLEDGE, por exemplo, para gerar resultados de publicidade parecidos com os de cookies de terceiros ou outras tecnologias de rastreamento entre sites. Também estamos testando a criação de novos recursos que preservam a privacidade na Proteção de IP, como a geolocalização mais ampla, para oferecer suporte à filtragem de conteúdo quando os mecanismos atuais forem insuficientes. Gostaríamos de receber mais feedback sobre os casos de uso de filtragem de conteúdo que podem ser afetados pela Proteção de IP. |
| (Também relatado no 3o 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 na geolocalização. | Atualização do quarto trimestre: Estamos trabalhando com as partes interessadas para garantir que o Chrome continue oferecendo suporte a casos de uso legítimos de endereços IP. Queremos receber feedback do ecossistema sobre a granularidade da geolocalização de IP aqui. |
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 poderão ser limitadas depois que o Orçamento de privacidade for implementado | A proposta de orçamento de privacidade ainda está em discussão e não foi implementada em nenhum navegador. A data mais próxima de disponibilidade em escala 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 documentação adicional para compartilhar. Vamos compartilhar mais detalhes sobre a proposta quando ela estiver mais finalizada. Enquanto isso, convidamos as partes interessadas a compartilhar feedback que possam ajudar no desenvolvimento da proposta. |
Fortaleça os limites de privacidade entre sites
Conjuntos primários
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limite de domínio (também informado no 3o trimestre) | Solicitação para expandir o número de domínios associados | Atualização do quarto trimestre: Lançamos o QPS para testes locais, incluindo uma simulação de envio de conjuntos no GitHub e uma sinalização para testar o rSA e o rSAFor localmente. Também realizamos duas reuniões abertas para desenvolvedores sobre QPS para continuar a responder perguntas sobre casos de uso para o subconjunto associado. Incentivamos os desenvolvedores a testar a funcionalidade de QPS para enviar feedback sobre como o limite de domínio do subconjunto associado afetaria a usabilidade desse recurso nos casos de uso. Esclarecemos nas ligações do WICG que o Chrome está comprometido em oferecer uma solução utilizável que também considere os interesses de privacidade dos usuários. Por isso, agradeça o feedback da comunidade sobre casos de uso específicos que podem ser afetados pelo limite de domínio. Assim, a equipe vai poder considerar como resolver esses casos de uso sem deixar de proteger a privacidade do usuário. |
| Peça mais detalhes sobre as medidas de mitigação de abusos. | O que acontece quando um domínio é adicionado a um conjunto sem consentimento? | Publicamos as diretrizes de envio para conjuntos primários neste link em 2 de dezembro de 2022. Conforme explicado nas diretrizes de envio, qualquer gestão de mudança definida seguirá e respeitará um processo de validação no GitHub, incluindo a validação de propriedade, o que deve reduzir esse risco. |
| Mitigação de abusos | Preocupação com a possibilidade de exploração de formações de conjunto primário | Estamos buscando maneiras de ampliar as verificações técnicas para tipos de subconjuntos e buscando informações adicionais da comunidade aqui. |
| Casos de uso de anúncios | Perguntas sobre se os conjuntos primários precisam ser usados para oferecer suporte à segmentação de anúncios | Não queremos oferecer suporte aos casos de uso de segmentação de anúncios para conjuntos primários. Por isso, recomendamos o uso das APIs Ads disponíveis para esses casos. |
| (Também relatado no 3o trimestre) Política | Preocupação de que o QPS não é consistente com os Compromissos da CMA em relação à "Legislação de Proteção de Dados Aplicável", já que o GDPR não impõe um limite ao número de sites em um conjunto, mas prevê um limite de três. | Nossa resposta não mudou em relação ao 3o trimestre: "O Google continua se comprometendo com a CMA a criar e implementar as propostas do Sandbox de privacidade sem distorcer a concorrência ao dar preferência aos negócios do Google. Além disso, consideramos o impacto na concorrência na publicidade digital, editores e anunciantes, bem como o impacto nos resultados de privacidade e na conformidade com os princípios de proteção de dados estabelecidos na Legislação de Proteção de Dados Aplicável. A preocupação expressa não divulga nenhuma incompatibilidade com o GDPR. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos." |
| Proposta alternativa | Conjuntos validados pelo GDPR | Além do feedback do ecossistema sobre a proposta de adoção dos "Conjuntos validados pelo GDPR", o Chrome tem dúvidas sobre as seguintes limitações dessa proposta alternativa:
Como essa alternativa foi levantada, o Chrome atualizou a proposta de conjuntos primários e publicou diretrizes de envio para a criação de novos conjuntos. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Restrições de frames Fenced durante o OT | Quais são as restrições atuais em relação ao Fenced Frames para o período do teste de origem? | Estamos trabalhando na documentação sobre as restrições e o status da implementação e planejamos compartilhar essa informação no primeiro trimestre de 2023. |
| Vários anúncios em um único frame Fenced Frame | Solicitação para exibir vários anunciantes em um frame Fenced Frame em um leilão | No momento, esse pedido não está sendo desenvolvido ativamente, mas aceitamos feedback adicional caso os elementos do ecossistema considerem o recurso importante. |
| Pacotes da Web | Quais são os requisitos e o suporte planejados para pacotes da Web com Fenced Frames? | No momento, não temos informações sobre se esse será o requisito no futuro. As mudanças são anunciadas com antecedência e não são aplicadas antes da descontinuação dos cookies de terceiros. Consulte o status atual nesta explicação. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Armazenamento compartilhado para adtechs | Incerteza sobre o uso do armazenamento compartilhado para casos de uso de adtech | A API Shared Storage e a API Private Aggregate podem ser usadas para diferentes fins de medição que precisam de medição de armazenamento entre sites. Veja alguns exemplos aqui. Os provedores de soluções de métricas e de DSP serão o principal integrador dos casos de uso de anúncios. |
ÍCONES
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 3o trimestre) Requisito particionado | Foi adicionado um requisito de comportamento explícito para o atributo "Particionado" em cookies primários. | Atualização do quarto trimestre: Após conversas sobre chamadas do GitHub e do PrivacyCG, o comportamento que alinhamos é que os cookies particionados definidos nos cookies primários usarão uma chave de partição de (A,A), em que "A" é o site de nível superior. Documentamos esse comportamento na explicação e especificação. |
| Gerenciamento de cookies | Existem ferramentas para gerenciar/administrar cookies primários ou de terceiros? | O Chrome DevTools e o NetLog podem ser usados para testar sites com o bloqueio de cookies de terceiros ativado. As duas ferramentas informam quando os cookies são bloqueados devido à configuração do usuário. Gostaríamos de receber seu feedback sobre outros sites de auditoria. |
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| O IdP exige conhecimento de RP para permitir uma sessão | Problema quando um usuário tenta fazer login no IdP do Feide a partir de duas RPs diferentes. | Estamos discutindo possíveis soluções para esse problema aqui. |
| Interoperabilidade | Preocupações com o impacto da FedCM no relacionamento entre os usuários e os sites em que eles fazem login usando a FedCM e a "interoperabilidade" entre os sites | O objetivo da FedCM é continuar oferecendo suporte aos serviços de identidade federada que atualmente dependem de cookies de terceiros quando esses cookies forem removidos do Chrome. Esperamos que o FedCM seja apenas uma das opções disponíveis para esses serviços. Os provedores de identidade (IdPs) e as partes confiáveis (RPs, na sigla em inglês) são livres para usar outras tecnologias que melhor atendam às suas necessidades. Parece que as preocupações relacionadas à relação entre usuário e RP e à "interoperabilidade" se devem a um mal-entendido da proposta da FedCM. A FedCM deixa para os IdPs decidir quais informações compartilhar com um RP e de que forma, assim que o usuário faz 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 se autentica". Em vez disso, o FedCM está aberto para que cada IdP escolha se quer compartilhar o identificador real do usuário, uma versão desse identificador por site ou alguma outra versão dessas informações. A especificação do FedCM identifica a correlação entre sites como um risco de privacidade associado à API e discute os 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 opções de 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), a FedCM permitirá que o usuário selecione qual será usada para fazer login no site da RP. Além disso, cada RP decide por conta própria quais IdPs vão oferecer suporte no próprio site. Um aspecto dessa decisão é considerar o mecanismo do qual um IdP depende, seja FedCM ou outra tecnologia. Novamente, o navegador não determina essas opções para RPs ou IdPs. |
Combater spam e fraudes
API Private State Token
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Lidar com bots | O que acontece se o emissor descobrir que 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 que usam para assinar tokens regularmente. Assim, os tokens antigos emitidos em uma lógica de emissão potencialmente corrompida expirem e os sites resgatem os tokens mais novos com a lógica de emissão atualizada. |
| Envio de formulários no mesmo site | Os tokens de estado particular podem ser usados para envios de formulários do mesmo site que envolvem navegação de página inteira (por exemplo, Content-Type: application/x-www-form-urlencoded) em vez de uma solicitação das APIs fetch/XMLHttpRequest? | No momento, isso não é suportado na primeira versão dos tokens de estado particular. Se houver uma forte demanda para esse caso de uso, receberemos feedback do ecossistema. |
| Verificação do lado do servidor | Perguntas sobre se os tokens de estado particular podem ser verificados do lado do servidor | Os tokens são resgatados no emissor e, em seguida, o emissor 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, e esperamos que diferentes ecossistemas de emissores criem padrões distintos para interpretar os registros de resgate. |