Relatório trimestral do segundo 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
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Cronogramas mais claros | Programações de lançamentos mais claras e detalhadas para as tecnologias do Sandbox de privacidade. | Definimos nossos planos atuais para o cronograma de implantação em privacysandbox.com e atualizamos-os mensalmente. Elas consideram o tempo de desenvolvimento dos desenvolvedores do Chrome e da Web, além do feedback que recebemos de todo o ecossistema em relação ao tempo necessário para testar e adotar as novas tecnologias. Cada tecnologia passa por várias etapas, do teste ao lançamento (lançamento), e o tempo de cada etapa é baseado no que aprendemos e descobrimos na etapa anterior. Embora não tenhamos versões confirmadas no momento, como já temos, atualizaremos nosso cronograma público em privacysandbox.com. |
| 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). | Entendemos que alguns desenvolvedores se preocupam com o impacto das tecnologias do Sandbox de privacidade. O Google se comprometeu com a CMA a não criar nem implementar as propostas do Sandbox de privacidade que distorçam a concorrência ao dar preferência aos próprios negócios do Google e considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes, assim como nos resultados de privacidade e na experiência do usuário. Continuamos trabalhando com a CMA para garantir que nosso trabalho cumpra esses compromissos.
À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é a performance das novas tecnologias para diferentes tipos de partes interessadas. Feedback é fundamental nesse sentido, especialmente feedback específico e útil que pode nos ajudar a melhorar ainda mais os designs técnicos. |
| Cronogramas de descontinuação dos cookies de terceiros | Solicitações para evitar mais atrasos na descontinuação de cookies de terceiros | Algumas partes interessadas querem que o Chrome continue com a descontinuação dos cookies de terceiros sem atrasos. Outras pessoas acreditam que é necessário mais tempo para testar e adotar as tecnologias do Sandbox de privacidade. Temos o compromisso de agir com responsabilidade, considerando a complexidade das tecnologias e a importância de acertar as coisas no ecossistema. O feedback do setor e dos reguladores foi fundamental nesse processo. |
| Cronogramas de descontinuação dos cookies de terceiros | Solicitações para atrasar a descontinuação de cookies de terceiros e oferecer mais tempo para testar as APIs. | Algumas partes interessadas querem que o Chrome continue com a descontinuação dos cookies de terceiros sem atrasos. Outras pessoas acreditam que é necessário mais tempo para testar e adotar as tecnologias do Sandbox de privacidade. Temos o compromisso de agir com responsabilidade, considerando a complexidade das tecnologias e a importância de acertar as coisas no ecossistema. O feedback do setor e dos reguladores foi fundamental nesse processo. |
| Solicitações de documentação | Pedidos de mais recursos detalhando como gerenciar testes, análises e implementações. | Agradecemos aos desenvolvedores que nosso material atual foi útil. Por isso, temos o compromisso de fornecer mais materiais, incluindo o horário de atendimento e a documentação técnica dos desenvolvedores nas próximas semanas e meses, para que os desenvolvedores possam continuar a entender como as novas tecnologias podem funcionar para eles.
Também realizamos sessões públicas em horário comercial para desenvolvedores externos em que compartilhamos práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produto e engenharia para possibilitar discussões e perguntas ao vivo. |
| Experiência no setor | A equipe do Chrome, que trabalha com órgãos de normas, não tem o conhecimento necessário no ecossistema de anúncios para equilibrar adequadamente privacidade e utilidade. | Reconhecemos que temos uma grande responsabilidade e dependemos de feedback específico para fazer isso corretamente. Também consideramos que privacidade e eficácia são critérios de design críticos e necessários. Na equipe que trabalha no Sandbox de privacidade para a Web, a soma total de anos trabalhados no ecossistema de anúncios é centenas. |
Mostre conteúdo e anúncios relevantes
Tópicos
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Utilidade para diferentes tipos de partes interessadas | Foram levantadas preocupações sobre o valor criado e a distribuição desse valor para sites, dependendo do nível de tráfego ou da especialidade do conteúdo. | A utilidade da API será explorada por meio de testes. O Chrome espera que a taxonomia e outros parâmetros evoluam com base nos resultados dos testes. A evolução da taxonomia ou dos parâmetros não pode exigir mudanças incompatíveis com versões anteriores. Além disso, o Chrome espera que o feedback continue influenciando a evolução da API Topics após a descontinuação dos cookies de terceiros. |
| Taxonomia | As partes interessadas do setor querem ter uma voz para influenciar a taxonomia. | O Chrome continua aberto para inserir informações sobre a taxonomia. O Chrome tem muito interesse em receber feedback sobre o modelo de governança para modificar a taxonomia e discutir como outros órgãos do setor podem desempenhar um papel mais ativo no desenvolvimento e na manutenção da taxonomia em longo prazo. |
| Não há histórico de navegação suficiente | Proposta que mostra os temas que o autor da chamada acessou nas últimas semanas, caso o usuário não tenha histórico de navegação suficiente para criar cinco temas na semana mais recente. | Para nosso design atual, eles são escolhidos aleatoriamente. Investigaremos a correlação com tópicos anteriores e consideraremos se há a possibilidade de incorporar isso. No entanto, as correlações podem ter considerações de privacidade adversas que precisam ser consideradas. |
| Como chamar a API Topics em nome de um editor | Um provedor de serviços terceirizado pode compartilhar temas com um editor? | Sim, é assim que esperamos que a API Topics seja usada. |
| Possíveis vetores de ataque | Identificar tópicos com ruído | Com base no feedback de várias pessoas do ecossistema, o Chrome escolheu filtrar os temas e introduzir ruído. Essas decisões foram tomadas com foco na privacidade, para limitar o acesso às informações àquelas que de outra forma não teriam acesso a essas informações e introduzir uma negação plausível para os usuários, respectivamente. Reconhecemos que essas decisões têm desvantagens, como o vetor de ataque descrito aqui. No entanto, nossa avaliação é que os benefícios de privacidade superam os riscos potenciais. Discussões públicas sobre essa decisão são bem-vindas. |
| Qualificação para o teste de origem | Como detectar se um usuário está qualificado para um teste de origem? | Um recurso de teste de origem pode não estar disponível para um usuário devido às configurações do navegador ou outros fatores, mesmo que ele acesse uma página da Web que forneça um token de teste válido e o navegador esteja incluído no grupo com o teste ativado.
Por esse motivo, a detecção de recursos precisa ser sempre usada para conferir se um teste de origem está disponível antes de tentar usá-lo. |
| Impactos no desempenho | Preocupações com sobrecarga e latência relacionadas à API Topics | Estamos solicitando feedback sobre abordagens para evitar iframes de origem X caros e lentos e para a proposta de separar a API Topics de modo que a busca por temas não mude o estado de navegação. |
| Funcionalidade da API Split Topics | Mais controle sobre os três aspectos diferentes da API | Entendemos o caso de uso e apresentamos uma possível maneira de resolver isso no GitHub. No momento, estamos aguardando mais feedback do ecossistema sobre a criação da funcionalidade. Veja as discussões em andamento aqui. |
| Linha do tempo e documentação do classificador | Os desenvolvedores pediram mais informações sobre o classificador. | Disponibilizamos mais informações sobre o classificador publicamente neste link.
Além disso, acesse este link. Acesse este link. |
| Controles de usuário e segurança | Alguns tópicos podem ser proxies para grupos sensíveis, e os usuários precisam de mais controles para evitar resultados negativos. | Os tópicos representam um avanço significativo para o controle e a transparência do usuário. Os usuários poderão desativar tópicos, revisar os tópicos que foram atribuídos a eles, remover tópicos e entender quais empresas estão interagindo com os tópicos em determinada página. Além disso, os usuários também podem excluir o histórico de navegação para afetar os Assuntos. Continuamos abertos às discussões sobre controles de usuário mais avançados, como os sugeridos pelos desenvolvedores. No entanto, precisamos ter certeza de que, para as preocupações levantadas neste bug, ele realmente remove os riscos. Por exemplo, a remoção apenas do tema "estudo de idioma estrangeiro", mas não dos sites que geraram o tema do histórico de navegação, não protege totalmente o usuário. |
| Uso de temas em sites com prebid.js | A API Topics pode ser usada em sites com prebid.js? | A resposta curta é "Sim". Confira mais informações neste link. |
| Uso da API Topics em um widget de recomendação | Podemos usar a API Topics no widget recomendado (por exemplo, Outbrain) | Não limitamos o caso de uso de Topics recuperados após a chamada da API (isso depende da política de dados de cada desenvolvedor). |
| Privacidade / Política | Perguntas sobre o objetivo de filtrar respostas por autor da ligação caso alguns terceiros compartilhem os temas com qualquer pessoa que ligue. | Com base no feedback de várias pessoas no ecossistema, o Chrome escolheu esse design para limitar o acesso às informações às pessoas que, de outra forma, não teriam acesso a elas. É claro que editores e terceiros que recebem a API Topics podem decidir por conta própria quais informações vão compartilhar com as partes no site. Se eles fizerem esse tipo de compartilhamento, o Chrome os recomenda fortemente a serem transparentes com os usuários sobre tal compartilhamento e oferecer a eles controles. |
| Sinais de ruído | Apresentar um tópico aleatório 5% do tempo pode criar muito ruído / sinal falso. | O ruído é um método importante para proteger a privacidade do usuário. Os níveis de ruído em comparação com a utilidade dos temas serão explorados em testes. |
FLEDGE
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Coordenação de testes | Testes de desempenho e impacto na receita | O desempenho do FLEDGE e a melhor forma de oferecer suporte aos testes do ecossistema durante os testes de origem e de disponibilidade geral estão sendo discutidos de maneira ativa nas reuniões públicas do WICG. |
| Servidor confiável para FLEDGE | Quando o servidor confiável estará disponível para testes? | Agradecemos esse feedback e estamos trabalhando ativamente em um plano mais detalhado para compartilhar com o uso de servidores confiáveis no FLEDGE. |
| Padronização de protocolos | Haverá um protocolo comum para transmitir dados entre SSPs e DSPs, como rótulos comuns para grupos de interesse? | O feedback de DSPs, SSPs e do ecossistema de anúncios em geral sobre uma possível padronização da especificação é bem-vindo. Para fins dos testes iniciais, recomendamos trabalhar diretamente com seus parceiros de teste, já que eles estão testando abordagens diferentes. Também incentivamos e planejamos continuar trabalhando com as organizações de comércio de anúncios a se opinar para criar a padronização, caso isso seja útil para suas empresas membros. |
| Limite de frequência | Controles de frequência por usuário em uma campanha e um grupo de anúncios. | O FLEDGE também vai oferecer suporte ao limite de frequência para leilões no dispositivo e campanhas contextuais / de marca. Limites de armazenamento compartilhado e específicos de site também podem ser usados para controles adicionais de limite de frequência. |
| Impacto do FLEDGE no desempenho | Bidders com uso intenso de computação no leilão do FLEDGE | O Chrome está em discussões ativas com desenvolvedores sobre o possível impacto no desempenho do site. No Chrome, você tem a oportunidade de saber mais durante os testes. |
| Como testar o FLEDGE com outros recursos | Como os relatórios de eventos da API Attribution Reporting e do FLEDGE vão ser combinados? | Isso foi discutido em uma chamada recente do WICG/conversion-measurement-api, com um link para os minutos detalhados aqui.
Resumo da reunião: o design atual dos relatórios de anúncios do Fenced Frames permite associar um ID gerado no Fenced Frame a informações contextuais. Portanto, os relatórios de eventos gerados dentro do Fenced Frame poderão ser mesclados às mesmas informações contextuais no servidor (usando duas mesclagens do lado do servidor em vez de uma). |
| Contagem de impressões | Qual metodologia de contagem de impressões deve ou poderia ser usada entre compradores e vendedores | A API FLEDGE já permite o alinhamento da metodologia entre o vendedor e o comprador durante o leilão. Recebemos sugestões de implementações alternativas sem feedback sobre o motivo pelo qual nosso design atual não funciona para o ecossistema. |
| Exibição de vários anúncios | Indica se é possível exibir vários anúncios em um leilão em um determinado frame fenced. | No momento, isso é possível por meio de anúncios de componentes (não confunda com leilões de componentes). Para isso, todos os anúncios precisam estar no mesmo grupo de interesse. |
| Especificação "Públicos-alvo definidos pelo vendedor (SDA)" e FLEDGE | O FLEDGE pode se tornar um mecanismo para impedir que os compradores criem perfis do SDA em solicitações de anúncios? | O FLEDGE foi criado para evitar o vazamento de informações que não são relevantes quando o editor já sabe em que SDAs os visitantes estão e a segmentação é o mesmo site. Se for importante oferecer suporte a compras em SDAs com todas as proteções integradas ao FLEDGE, uma solução pode ser que um vendedor transmita os rótulos de SDA para o leilão no dispositivo e uma adtech de compra para criar o próprio grupo de interesse com uma lógica de lances que diga "Quero comprar o público-alvo X". |
| Suporte para outras moedas além do USD | Suporte para testar o FLEDGE com outras moedas além do USD | Agradecemos essa frase de destaque e adicionamos suporte a outras moedas no nosso acúmulo de solicitações de recursos. Esperamos que isso seja disponibilizado em breve. |
| Suporte à segmentação negativa de grupos de interesse | Uma API com suporte à segmentação negativa de IG: exibir anúncios somente se o usuário não pertencer a um IG. | Discussão em andamento, incluindo algumas opções propostas para dar suporte, no problema do GitHub (em inglês). |
| Várias SSPs no FLEDGE | Risco de favorecer o Google ao implementar leilões multinível no FLEDGE | Adicionamos suporte a várias SSPs no FLEDGE para proporcionar um ambiente justo e equitativo. O Google se comprometeu a não projetar, desenvolver ou implementar as propostas do Sandbox de privacidade de forma a distorcer a concorrência ao dar preferência aos produtos e serviços de publicidade do Google. O Google leva isso a sério e é muito aberto para discutir qualquer preocupação das partes interessadas sobre aspectos específicos da tecnologia. Para mais informações, o Chrome documentou publicamente o mecanismo de leilão de componentes aqui. |
Medir os anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Atribuição multitoque | Editores que solicitam suporte para atribuição multitoque | Os métodos atuais de atribuição multitoque exigem um vínculo determinista das impressões (e, portanto, identidade) de um usuário em diferentes sites. Por isso, essa funcionalidade na forma atual não está alinhada aos objetivos do Sandbox de privacidade, que tem como objetivo oferecer suporte aos principais casos de uso de anúncios sem rastreamento entre sites. Em alguns casos, a aproximação da atribuição de crédito (por exemplo, usando prioridades ponderadas e aleatórias) é possível sem rastrear usuários individuais. |
| Geração de ruído | Perguntas sobre os níveis de ruído nos relatórios | Nosso experimento inicial permite que os desenvolvedores definam o próprio valor do épsilon para que possam entender como os relatórios mudam com base no nível de ruído. A partir de agora, os desenvolvedores podem escolher um valor de épsilon de até epsilon=64. Fizemos isso especificamente para facilitar o teste das APIs pelos desenvolvedores e fornecer feedback sobre os valores de épsilon adequados.
Também fizemos uma solicitação pública para esse feedback. |
| Coordenação de testes | A ferramenta de teste local pode ser usada para o OT? | Sim, a ferramenta de teste local pode ser usada durante o OT. A ferramenta de teste local pode ser usada com relatórios de depuração, desde que cookies de terceiros estejam disponíveis. |
| Ergonomia da consulta | Ativar a consulta agregada de chaves | Concordamos que isso parece melhorar a ergonomia da API com pouco ou nenhum custo de privacidade aparente. Faremos uma proposta e veremos se há um amplo consenso de que vale a pena apoiá-la. |
| Dados menos precisos para sites pequenos | Sites ou campanhas menores podem receber dados menos precisos. | O Chrome reconhece que as proteções de privacidade baseadas em ruído têm maior impacto em frações de dados menores. No entanto, é possível que métodos como a agregação durante períodos mais longos resolvam esse problema. Também 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 Chrome incentiva os testadores a aproveitar 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
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Proteção contra bots | Impacto da UA-R na proteção de bots | Agradecemos esse feedback e estamos coletando informações sobre abordagens de proteção de bots para usar em nossos designs futuros. |
| Dependências de implantação | Como lidar com as dependências de implantação do user agent estruturado (SUA, na sigla em inglês) | Lançamos a "Fase 4", conhecida como redução da versão secundária para 100% dos usuários do Chrome nas versões 101 e superiores. Consulte a atualização aqui. |
Dicas de cliente do user agent
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Como enumerar todas as dicas compatíveis | Interesse em ter uma maneira programática de conhecer todas as dicas compatíveis com um navegador. | Agradecemos esse feedback e estamos avaliando a solicitação de recurso. Queremos entender se esse é um caso de uso comum. |
| Flexibilidade do cabeçalho do UA-CH e do user agent | O UA-CH é muito prescritivo em comparação com a flexibilidade que o cabeçalho do user agent oferece, conforme definido por rfc7231. | Para o Chrome, a natureza prescritiva dos cabeçalhos UA-CH é uma melhoria importante em relação à flexibilidade da string do UA, tanto do ponto de vista da interoperabilidade entre navegadores quanto da proteção de privacidade do usuário, evitando adições arbitrárias de identificadores de alta entropia.
O problema continua em aberto caso outras pessoas também compartilhem essa preocupação e queiram fornecer feedback. |
| UA-CH: preocupações contra fraudes / antiabuso | Certos recursos que podem ser perdidos com o UA-CH: rastreador de redirecionamento de cliques e cliques fraudulentos. | Nossa equipe está investigando esses possíveis problemas com as partes interessadas em combate a fraudes e medição. |
| Desempenho | Há preocupações sobre a latência do recebimento de dicas via Critical-CH (no primeiro carregamento de página). | O Chrome está investigando maneiras de melhorar o desempenho. |
Gnatcatcher (em desenvolvimento)
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Preocupações com a latência | Adicionar saltos extras pode afetar a latência | Estamos considerando usar um proxy de dois saltos e explorando maneiras de encontrar o equilíbrio certo entre latência e privacidade do usuário. Estamos abertos a feedback e queremos ter mais discussões nos fóruns do W3C. |
| Proteção contra fraudes e bots | Impactos na proteção contra fraudes e bots, inclusive em países menos desenvolvidos | A segurança é um requisito fundamental, à medida que procuramos formas de melhorar a privacidade do usuário de formas significativas, como proxy de endereços IP. Uma parceria de dois saltos com empresas respeitáveis oferece privacidade de usuário verificável. Também estamos desenvolvendo ideias para novos indicadores que ajudem a transmitir a confiança dos usuários. |
| Conformidade com as leis locais de privacidade | Os relatórios de dados geográficos em nível de país dificultam a conformidade com regimes locais mais granulares | Postamos publicamente os princípios propostos, o que inclui abordagens possíveis para permitir que os sites obedeçam aos requisitos locais. |
Fortaleça os limites de privacidade entre sites
Conjuntos primários
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Utilidade para diferentes tipos de partes interessadas | Impacto do QPS para editores pequenos e grandes | O principal objetivo do Sandbox de privacidade é melhorar a privacidade do usuário substituindo as práticas atuais por soluções que não dependem de mecanismos de rastreamento entre sites. Queremos que essas soluções sejam as mais úteis possíveis para diferentes tipos e tamanhos de partes interessadas. Aceitamos contribuições específicas e acionáveis sobre como essas soluções podem ser melhoradas e esperamos que elas continuem evoluindo com as discussões e os testes da comunidade. |
| Mais privacidade | Muitos sites no mesmo conjunto podem resultar em resultados semelhantes aos cookies de terceiros | Esse feedback é muito importante para nós. Estamos avaliando quais são os limites certos e, ao mesmo tempo, tentamos oferecer tratamento ou indicadores aos usuários e desenvolvedores para que eles saibam quando atingir esse limite. Não temos uma proposta específica ainda, mas esperamos que seja em breve. |
| Suporte ao ecossistema de QPS | Coleta de suporte e preocupações para continuar desenvolvendo QPS fora do CG de privacidade | Embora tivéssemos preferido que a proposta de conjuntos primários permanecesse no PrivacyCG, esperamos continuar a levar a proposta a elas nas WICG. Também fomos incentivados pelas várias declarações de suporte que promovemos as discussões contínuas sobre os conjuntos primários e os casos de uso que serão abordados. O Google continua comprometido em encontrar soluções que ajudem a Web a continuar crescendo e prosperando de uma maneira que proteja e respeite a privacidade do usuário. |
| Interoperabilidade com navegadores | Implementação por outros navegadores | Reconhecemos a importância da interoperabilidade com o navegador para desenvolvedores e vamos continuar colaborando com outros navegadores para buscar a padronização do QPS. |
| Requisito comum da Política de Privacidade | É inviável manter uma Política de Privacidade comum em todos os produtos e jurisdições que precisam fazer parte do mesmo conjunto. | O Chrome ainda está definindo os requisitos da nossa política e vai levar esse feedback em mente. |
API Fenced Frames
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Solicitação de documentação | Diferenças com iframes em sandbox | Agradecemos seu feedback e sua sugestão. Há uma discussão atual no GitHub sobre isso, em que esperamos conseguir esclarecimento final sobre a solicitação para poder avaliá-la completamente. A discussão pública está disponível aqui. |
| Recursos entre APIs | Compatibilidade padrão com a API Attribution Reporting em frames Fenced | Estamos solicitando feedback sobre uma proposta de permitir a API Attribution Reporting no "modo de anúncios opacos" de frames isolados por padrão. Incentivamos os desenvolvedores que considerarem isso útil a participar da discussão. |
API Shared Storage
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Limites de dados | Haverá uma restrição quanto à quantidade de dados que pode ser armazenada por partição? | Sim, haverá limites. Consulte o problema no GitHub (em inglês) para saber mais detalhes. Vamos precisar de cotas de armazenamento. Nossa proposta atual é ter um limite de 4 KB para o tamanho por entrada. As chaves e os valores serão limitados a 1.024 caracteres char16_t cada. Já um limite de entrada por origem será de 10.000 entradas, com um mecanismo que impede o commit de entradas adicionais quando a capacidade de uma origem estiver cheia. Queremos receber feedback sobre os limites específicos propostos aqui. |
| Transparência do usuário | Transparência do usuário sobre fontes de dados e o uso de dados | Agradecemos esse feedback e acreditamos que é uma abordagem promissora a ser explorada. Em particular, estamos avaliando se seria possível fazer isso de uma forma que ofereça transparência suficiente aos usuários. |
ÍCONES
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Impedimentos de adoção | Os CHIPS devem ser vinculados ao nome do host? (o requisito de não domínio) | Estamos removendo esse requisito do OT com base no feedback dos participantes de que ele gerou mais complexidade e serve como um impedimento à adoção dos CHIPS.
Vamos discutir esse requisito no Grupo da comunidade de privacidade aqui como parte da desenvolvimento dos padrões. |
| Casos de uso dos CHIPS em anúncios | Os CHIPS podem ser usados para casos de uso de anúncios em um único site? | O acompanhamento de usuários em um site é um caso de uso permitido. Atualizamos nosso artigo para desenvolvedores para destacar esse caso de uso. |
| Incorporações autenticadas | O estado de logon é preservado com os CHIPS? | O estado de login não é preservado, mas não é o caso de uso pretendido para os CHIPS. Conhecemos o caso de uso de incorporações autenticadas e estamos trabalhando para encontrar soluções. |
| Coordenação de testes | Existe alguma outra ação do usuário necessária para testar o particionamento? | Se o token do OT for válido e presente nos cabeçalhos das páginas visitadas, o recurso deverá estar disponível para os usuários, sem exigir nenhuma outra ação do usuário |
| Compatibilidade com navegadores | Interesse em entender como outros navegadores processaram atributos de cookies particionados | O Chrome continua trabalhando em grupos de padrões públicos, como o W3C, para identificar designs e implementações que funcionam em vários navegadores. |
FedCM
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Possíveis vetores de ataque | Possíveis vetores de ataque por decoração de links e ataques de tempo | Estamos coletando opiniões do público e investigando possíveis maneiras de resolver esse problema. |
| UX para permitir vários IdPs | Só é possível apresentar um IdP por vez | Acreditamos no suporte a vários IDPs e estamos trabalhando ativamente em abordagens para |
| Expressividade | A preocupação é que, como o navegador renderiza parte do fluxo de identidade federada, é difícil capturar todas as nuances que os IdPs gostariam de apresentar aos usuários. | O Chrome está buscando opções de personalização da marca (por exemplo, logotipos, cores) e personalização de strings (por exemplo, "acesse este artigo" em vez de "fazer login com").
O Chrome reconhece as compensações e vai continuar trabalhando com o ecossistema para abordar o máximo de aspectos possível e torná-lo o mais expressivo possível. |
| Aplicabilidade e interoperabilidade | Preocupação com o fato de outros navegadores não adotarem nem implementarem a FedCM. | O Chrome também tem trabalhado com outros fornecedores de navegadores para encontrar soluções comuns para a federação no Grupo da Comunidade FedID. |
| Sugestão para remover requisitos de dados pessoais no fluxo de inscrição | (1) uma UX que indique ao usuário qual IdP está sendo escolhido, sem sinalizar que o e-mail, a imagem e o nome serão compartilhados com mais foco em privacidade.
(2) A inscrição em casos de uso é esparsa na experiência do usuário e na seleção de declarações do IdP |
Estamos de acordo e estamos buscando formas de implementar o feedback de uma maneira mais amigável, com mais privacidade e com mais usuários. |
| Interação do usuário com o IdP | Necessidade de interação direta entre o usuário e o IdP se um limite de risco for excedido | Estamos investigando esse feedback. |
Particionamento de estado da rede
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Desempenho | O particionamento de estado da rede pode aumentar as conexões que consomem muitos recursos com as CDNs | Ainda estamos investigando as características de desempenho do Particionamento de estado da rede, incluindo a medição de diferentes esquemas de chave possíveis. Ainda não tomamos uma decisão entre as concessões de desempenho, segurança e privacidade e precisamos coletar mais dados. |
Combater spam e fraudes
API Trust Tokens
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Feedback regulamentar | Preocupações sobre o investimento de tempo e recursos em tokens de confiança sem um sinal claro dos reguladores sobre a viabilidade a longo prazo | Nosso objetivo é criar uma tecnologia que funcione para o ecossistema, tornando o feedback do setor e de reguladores fundamental para o processo. Vamos continuar consultando órgãos reguladores do mundo todo à medida que desenvolvermos o Sandbox de privacidade e disponibilizarmos as propostas para desenvolvedores, incluindo tokens de confiança. Como acontece com todas as novas tecnologias, as empresas precisam tomar decisões com base na própria avaliação dos requisitos regulatórios. |
| Tempo de lançamento | Quando os tokens de confiança serão lançados no GA? | Apresentamos nossas estimativas atuais de entrega no cronograma público em privacysandbox.com. Assim que decidirmos sobre a data de entrega para a disponibilidade geral, vamos publicá-la publicamente pelos processos de lançamento do Chrome e atualizar o cronograma no site. |
| Tokens de confiança versus outros | Qual é o papel dos tokens de confiança considerando os outros que estão em padronização, como os de acesso privado | Estamos envolvidos em discussões sobre padronização e nosso objetivo é nos alinhar a outros esforços o máximo possível, ao mesmo tempo que viabilizamos os diferentes casos de uso que cada tecnologia permite. Por exemplo, tokens de confiança e de acesso privado dependem do protocolo de cartão de privacidade. |
| Limites de dados | Máximo de 2 emissores para resgate de tokens por página, o que pode limitar o risco | Estamos procurando opções de longo prazo em que possamos permitir que as empresas resgatem tokens com segurança sem arriscar mais entropia do usuário, talvez particionando o acesso aos resgates de tokens. |
| Restrições de acesso | Somente origens aprovadas (e verificadas/não falsificadas) podem verificar a presença de um token e fazer o resgate | Estamos analisando abordagens para definir quem pode ver e resgatar tokens. |
| Suporte do dispositivo | As dependências de tempo de execução JavaScript limitam o uso em determinados dispositivos. O suporte a TT pode ser estendido para funcionar em outros tipos de dispositivos? | Isso é algo que poderíamos considerar para o desenvolvimento futuro e um tópico que gostaríamos de receber mais feedback dos desenvolvedores nos fóruns do W3C. Também temos um problema aberto para discutir um resgate de token acionado por cabeçalho HTTP. |
| Casos de uso | Não está claro quais são os casos de uso certos para tokens de confiança. Falta de clareza sobre os usos pretendidos. | Nosso objetivo é facilitar a inovação na área de combate à fraude e entender que cada empresa pode empregar técnicas reservadas com tokens de confiança. Por isso, não somos prescritivos em relação ao uso pretendido. No entanto, provavelmente vamos expandir nossa documentação para incluir mais exemplos como pontos de partida para parceiros que estão pensando em fazer experimentos ou adoção. |
| Cobertura de tokens de confiança | A remoção dessa política de recurso "resgate de token de confiança" deve aumentar significativamente a cobertura de tokens de confiança. | Considere isso enquanto coletamos feedback do OT e tomamos decisões sobre as próximas etapas. |
| Confiança do emissor | Por que devemos confiar em sites que emitiram tokens de confiança? | Não há diretrizes sobre como se tornar um emissor. Qualquer pessoa pode fazer isso. Espera-se que os editores trabalhem apenas com emissores confiáveis. Além disso, outros agentes legítimos no ecossistema de anúncios acabam por descontar ou interromper a compra do tráfego associado a emissores suspeitos ou desconhecidos. |
| Serviços incorporados de terceiros | Os serviços incorporados de terceiros podem resgatar e/ou solicitar tokens de confiança? | Sim, um serviço incorporado de terceiros pode emitir e resgatar tokens de confiança. |
| Ecossistema de emissores | É possível conseguir mais utilidade se os indicadores de confiança puderem ser compartilhados com outras empresas | Os tokens de confiança foram projetados para serem um primitivo de baixo nível e podem ser usados por emissores/resgatadores cooperativos para compartilhar sinais de confiança/reputação. |
| Sobrecarga de manutenção | A implementação criptográfica subjacente às operações do Trust Token está em BoringSSL, que o Google é o único responsável pela manutenção. Como a manutenção da biblioteca será gerenciada? | Os tokens de confiança dependem de operações criptográficas padronizadas (consulte o protocolo de cartão de privacidade) que também podem ser implementadas em outras bibliotecas. Recomendamos que os desenvolvedores solicitem/desenvolvam/mantenham o suporte para essas operações nas bibliotecas que escolherem. |
| Sobrecarga de manutenção | Não está claro por quanto tempo as versões do protocolo serão compatíveis | Estamos procurando desenvolver e documentar mais detalhes sobre os prazos de suporte esperados para versões de protocolo. |
| Limites do emissor | Se você estiver mais abaixo na cadeia, talvez não encontre sua oportunidade de executar tokens de confiança | Conforme mais organizações começam a usar tokens de confiança, podemos observar cada vez mais esses tipos de dinâmica de tempo e investigar possíveis soluções. Conforme descrito anteriormente, estamos procurando opções de longo prazo em que possamos permitir que as empresas resgatem tokens com segurança sem correr o risco de mais entropia do usuário, o que minimizaria a importância da localização na página ou da ordem de carregamento. |
Novas soluções antifraude em desenvolvimento
| Tema do feedback
(classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Indicadores de atestado de integridade do dispositivo | Geralmente, suporte forte para buscar sinais de integridade do dispositivo atestados por plataformas e disponibilizados para a Web | Vamos continuar coletando feedback e desenvolvendo a proposta com o design e a iteração públicos. |
| Indicadores de atestado de integridade do dispositivo | Perguntas sobre quanta entropia do usuário poderia ser transmitida por novos sinais e se determinados casos de uso (como um usuário fazendo login no banco) poderiam justificar sinais de entropia mais altas. | Pretendemos fornecer indicadores de alto valor com o mínimo possível de entropia do usuário para preservar a privacidade do usuário. |
| Indicadores de atestado de integridade do dispositivo | Esse sinal limitaria o acesso de dispositivos mais antigos ou plataformas de código aberto/modificadas? | Todos os novos sinais devem considerar o acesso universal como um princípio fundamental no desenvolvimento, e essas são questões importantes a serem abordadas antecipadamente à medida que continuamos a incubação. |
| Indicadores de atestado de integridade do dispositivo | Havia uma preocupação sobre se os novos indicadores faziam com que as empresas de segurança e antifraude dependessem demais do navegador e das plataformas
|
Todos os novos indicadores precisam ser vistos como dados complementares, e não como indicadores de "confiança" do navegador. Esperamos que as empresas de segurança continuem confiando nos próprios dados, modelos e mecanismos de decisão reservados com a confirmação de dispositivos como uma entrada adicional. Esperamos que qualquer novo indicador melhore os esforços de detecção em todo o ecossistema e dificulte a execução de fraudes. |
| Sinal de idade dos cookies | O conceito é interessante, mas provavelmente exige mais investigação dos casos de uso aplicáveis. | Dependendo dos níveis de interesse, o Chrome pode criar mais ideação sobre esse conceito e transformá-lo em uma explicação para o futuro feedback do ecossistema. |
| Servidores confiáveis contra fraudes | O conceito é interessante, mas provavelmente exige mais investigação dos casos de uso aplicáveis. | Dependendo dos níveis de interesse, o Chrome pode criar mais ideação sobre esse conceito e transformá-lo em uma explicação para o futuro feedback do ecossistema. |