Relatório trimestral do 2º trimestre de 2022 que resume o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.
Como parte dos compromissos com a CMA, o Google concordou em apresentar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas nas propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo de feedback do Sandbox de privacidade são gerados pela agregação do feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral do feedback, incluindo, entre outros: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com as partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe com prazer o feedback recebido do ecossistema e está procurando ativamente maneiras de integrar as lições a decisões de design.
Os temas de feedback são classificados pela prevalência em cada API. Isso é feito com uma agregação da quantidade de feedback que a equipe do Chrome recebeu sobre um tema específico e organizado em ordem decrescente de quantidade. Os temas comuns de feedback foram identificados analisando os tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que aparecem nas equipes internas e nos formulários públicos do Google.
Mais especificamente, as atas das reuniões dos órgãos de padrões da Web foram analisadas e, para feedback direto, os registros do Google de reuniões individuais com as partes interessadas, e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público foram considerados. O Google então coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas emergentes em relação a cada API.
As explicações das respostas do Chrome ao feedback foram desenvolvidas com base nas perguntas frequentes publicadas, nas respostas reais feitas a problemas levantados por partes interessadas e na determinação de uma posição especificamente para os fins deste exercício de relatórios públicos. Refletindo o foco atual de desenvolvimento e teste, foram recebidas perguntas e feedback específicos em relação às APIs Topics, FLEDGE e Attribution Reporting.
O feedback recebido após o fim do período de geração de relatórios atual pode ainda não ter uma resposta considerada do Chrome.
Glossário de acrônimos
- CHIPS
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos próprios
- IAB
- Interactive Advertising Bureau
- IDP
- Provedor de identidade
- IETF
- Internet Engineering Task Force
- IP
- Endereço de Protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste da Origin
- PatCG
- Grupo da comunidade de tecnologias de publicidade privada
- RP
- Entidade confiável
- SSP
- Plataforma de fornecimento
- TEE
- Ambiente de execução confiável
- UA
- String do user agent
- UA-CH
- Dicas de cliente HTTP do user agent
- W3C
- World Wide Web Consortium
- WIPB
- IP Blindness proposital
Feedback geral, sem API/tecnologia específica
| Tema do feedback
(Classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Cronogramas mais claros | Cronogramas de lançamento mais claros e detalhados para as tecnologias do Sandbox de privacidade. | Definimos nossos planos atuais para o cronograma de implantação em privacysandbox.com e o atualizamos mensalmente. Elas consideram o tempo de desenvolvimento para desenvolvedores do Chrome e da Web, além do feedback que recebemos do ecossistema mais amplo sobre o tempo necessário para testar e adotar as novas tecnologias. Cada tecnologia passa por várias etapas, do teste ao lançamento, e o tempo de cada etapa é informado pelo que aprendemos e descobrimos na etapa anterior. Não temos datas de lançamento definidas no momento, mas, quando tivermos, vamos atualizar nossa linha do tempo pública em privacysandbox.com. |
| Utilidade para diferentes tipos de partes interessadas | Preocupações de que as tecnologias do Sandbox de privacidade favoreçam desenvolvedores maiores e que sites de nicho (menores) contribuam mais do que sites genéricos (maiores). | Entendemos que alguns desenvolvedores têm dúvidas sobre o impacto das tecnologias do Sandbox de privacidade. O Google se comprometeu com o CMA a não projetar nem implementar as propostas do Sandbox de privacidade de forma a distorcer a concorrência com auto-referenciamento do próprio negócio do Google e a considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes, bem como os impactos na privacidade e na experiência do usuário. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho esteja em conformidade com esses compromissos.
À medida que os testes do Sandbox de privacidade avançam, uma das principais perguntas que vamos avaliar é como as novas tecnologias funcionam para diferentes tipos de partes interessadas. O feedback é fundamental nesse sentido, especialmente feedback específico e útil que possa nos ajudar a melhorar ainda mais os designs técnicos. |
| Cronograma de descontinuação de cookies de terceiros | Solicitações para evitar mais atrasos na descontinuação dos cookies de terceiros | Algumas partes interessadas querem que o Chrome prossiga com a descontinuação dos cookies de terceiros sem atraso, e outras acreditam que é necessário mais tempo para testar e adotar as tecnologias do Sandbox de privacidade. Temos o compromisso de agir de forma responsável, considerando a complexidade das tecnologias e a importância de fazer as coisas certas para o ecossistema. O feedback do setor e dos órgãos reguladores foi fundamental para esse processo. |
| Cronograma de descontinuação de cookies de terceiros | Pedidos para atrasar a descontinuação de cookies de terceiros e dar mais tempo para testar as APIs. | Algumas partes interessadas querem que o Chrome prossiga com a descontinuação dos cookies de terceiros sem atraso, e outras acreditam que é necessário mais tempo para testar e adotar as tecnologias do Sandbox de privacidade. Temos o compromisso de agir de forma responsável, considerando a complexidade das tecnologias e a importância de fazer as coisas certas para o ecossistema. O feedback do setor e dos órgãos reguladores foi fundamental para esse processo. |
| Solicitações de documentação | Solicitações de mais recursos detalhando como gerenciar testes, análises e implementação. | Agradecemos aos desenvolvedores que acharam nosso material atual útil. Estamos comprometidos em fornecer mais material, incluindo horários de atendimento e documentação técnica, nas próximas semanas e meses para que os desenvolvedores continuem entendendo como as novas tecnologias podem funcionar para eles.
Também realizamos sessões públicas de atendimento a desenvolvedores externos para compartilhar práticas recomendadas e demonstrações, além de sessões de perguntas e respostas com líderes de produto e engenharia para permitir discussões e perguntas ao vivo. |
| Experiência no setor | A equipe do Chrome que interage com os órgãos de padronização não tem experiência no ecossistema de anúncios necessário para equilibrar adequadamente privacidade e utilidade. | Sabemos que temos uma grande responsabilidade e dependemos de feedback específico para fazer isso da maneira certa. Também consideramos a privacidade e a eficácia como critérios de design essenciais e necessários. A equipe que trabalha no Sandbox de privacidade para a Web tem centenas de anos de experiência no ecossistema de anúncios. |
Mostrar 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 | Houve preocupações sobre o valor criado e a distribuição desse valor para sites, dependendo do nível de tráfego ou da especialização 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 pode não 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 voz para influenciar a taxonomia. | O Chrome continua aberto para contribuiçõ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 ter um papel mais ativo no desenvolvimento e na manutenção da taxonomia a longo prazo. |
| Histórico de navegação insuficiente | Proposta para mostrar os temas que o autor da chamada visualizou nas semanas anteriores se o usuário não tiver histórico de navegação suficiente para criar cinco temas para a semana mais recente | No nosso design atual, elas são escolhidas aleatoriamente. Vamos investigar a correlação com tópicos anteriores e considerar se há a possibilidade de incorporá-la. No entanto, as correlações podem ter considerações de privacidade adversas que precisam ser consideradas. |
| Como chamar tópicos em nome de um editor | Um provedor de serviços terceirizado pode compartilhar os Tópicos com um editor? | Sim, essa é uma forma de usar o Topics. |
| Vetores de ataque em potencial | Como identificar os tópicos barulhentos | Com base no feedback de muitas pessoas no ecossistema, o Chrome escolheu filtrar tópicos e introduzir ruído. Essas decisões foram tomadas com foco na privacidade, para limitar o acesso a informações a pessoas que, de outra forma, não teriam acesso a essas informações e para introduzir a negação plausível para os usuários, respectivamente. Sabemos que essas decisões têm desvantagens, como o vetor de ataque descrito aqui. No entanto, nossa avaliação é de que os benefícios de privacidade superam os possíveis riscos. Agradecemos a discussão pública sobre essa decisão. |
| Qualificação para o teste de origem | Existe uma maneira de detectar se um usuário está qualificado para um teste do Origin? | Um recurso de teste de origem pode não estar disponível para um usuário devido a configurações do navegador ou outros fatores, mesmo que ele esteja acessando uma página da Web que fornece um token de teste válido e o navegador esteja incluído no grupo em que o teste está ativado.
Por isso, a detecção de recursos precisa ser usada sempre para verificar se um recurso de teste de origem está disponível antes de tentar usá-lo. |
| Impactos na performance | Problemas de sobrecarga e latência com os tópicos | Estamos solicitando feedback sobre abordagens para evitar iframes de origem x caros e lentos e para a proposta de desfazer a API Topics para que a obtenção de temas não mude o estado de navegação. |
| Funcionalidade da API Split Topics | Oferecer mais controle sobre os três aspectos diferentes da API | Entendemos o caso de uso e propusemos uma possível solução no GitHub. No momento, estamos aguardando mais feedback do ecossistema sobre a criação da funcionalidade. Confira a discussão em andamento aqui. |
| Cronograma e documentação do classificador | Os desenvolvedores solicitaram mais informações sobre o classificador. | Confira mais informações sobre o classificador neste link.
e neste link. E neste link. |
| Controles do usuário e segurança | Alguns temas podem ser substitutos de grupos sensíveis, e os usuários precisam de mais controles para evitar resultados negativos. | Os tópicos representam um avanço significativo no controle e na transparência do usuário. Os usuários poderão desativar os tópicos, revisar os tópicos atribuídos a eles, remover tópicos e entender quais empresas estão interagindo com os tópicos em uma determinada página. Além disso, os usuários também podem excluir o histórico de navegação para afetar os temas. Continuamos a discutir sobre controles de usuário mais avançados, como os sugeridos pelos desenvolvedores. No entanto, precisamos garantir que, para as preocupações levantadas neste bug, ele realmente remova os riscos. Por exemplo, remover apenas o tema "estudo de língua estrangeira", mas não os sites que geraram o tema do histórico de navegação, não protege totalmente o usuário. |
| Uso de tópicos em sites com prebid.js | A API Topics pode ser usada em sites com o prebid.js? | A resposta curta é sim. Mais informações foram publicadas aqui. |
| Uso da API Topics em um widget de recomendação | Posso usar a API Topics no widget de recomendações (por exemplo, Outbrain)? | Não limitamos o caso de uso dos temas recuperados após a chamada da API (isso vai depender da política de dados de cada desenvolvedor). |
| Privacidade / Política | Perguntas sobre o objetivo de filtrar respostas por autor da chamada se alguns terceiros vão compartilhar os tópicos com qualquer pessoa que ligar. | Com base no feedback de muitos usuários do ecossistema, o Chrome escolheu esse design para limitar o acesso a informações para quem não teria acesso a elas. É claro que os editores e terceiros que recebem os tópicos podem decidir por conta própria quais informações vão compartilhar com as partes no site. Se fizerem esse tipo de compartilhamento, o Chrome recomenda que eles sejam transparentes com os usuários e ofereçam controles. |
| Sinais com ruído | Enviar 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, e os níveis de ruído em relação à utilidade dos tópicos serão explorados nos testes. |
FLEDGE
| Tema do feedback
(Classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Como testar a coordenação | Testes para verificar o impacto na performance e na receita | A performance do FLEDGE e a melhor forma de oferecer suporte aos testes do ecossistema durante os testes de origem e a disponibilidade geral estão sendo ativamente discutidos nas reuniões públicas do WICG. |
| Servidor confiável para FLEDGE | Quando o servidor confiável vai estar disponível para testes? | Agradecemos o feedback e estamos trabalhando em um plano mais detalhado para compartilhar o uso de servidores confiáveis no FLEDGE. |
| Padronização de protocolo | Haverá um protocolo comum para transmitir dados entre SSPs e DSPs, como rótulos comuns para grupos de interesse? | Aceitamos feedback de DSPs, SSPs e do ecossistema de anúncios mais amplo sobre a possível padronização da especificação. Para fins de teste inicial, recomendamos trabalhar diretamente com seus parceiros de teste, já que eles estão no processo de experimentar abordagens diferentes. Também incentivamos e planejamos continuar trabalhando com organizações de publicidade para criar uma padronização, caso seja útil para as empresas associadas. |
| 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 branding. O armazenamento compartilhado e os limites específicos do site também podem ser usados para controles adicionais de limite de frequência. |
| Impacto do FLEDGE no desempenho | Licitantes com uso intensivo de computação no leilão do FLEDGE | O Chrome está em discussões ativas com os desenvolvedores sobre o possível impacto na performance do site. O Chrome adora ter a oportunidade de aprender mais durante os testes. |
| Como testar o FLEDGE com outros recursos | Como os relatórios de eventos da API Attribution Reporting e da FLEDGE vão se encaixar? | Isso foi discutido em uma chamada recente da API de medição de conversão/WICG, com um link para as atas detalhadas aqui.
O resumo da reunião é que o design atual para Relatórios de anúncios de cercas virtuais permite associar um ID gerado dentro da cerca virtual a informações contextuais. Portanto, os relatórios de nível de evento gerados dentro do frame limitado podem ser agrupados às mesmas informações contextuais no servidor (usando duas mesclagens no servidor em vez de uma). |
| Contagem de impressões | Qual metodologia de contagem de impressões deve ou pode ser usada entre compradores e vendedores | A API FLEDGE já oferece suporte ao alinhamento na metodologia entre o vendedor e o comprador durante o leilão. Recebemos sugestões sobre implementações alternativas sem feedback sobre por que nosso design atual não funciona para o ecossistema. |
| Como mostrar vários anúncios | Se é possível mostrar vários anúncios em um leilão em um determinado frame fechado | No momento, isso é possível com anúncios de componentes (não confundir com leilões de componentes). Para isso, todos os anúncios precisam estar no mesmo grupo de interesses. |
| Especificação de "Públicos-alvo definidos pelo vendedor (SDA)" e FLEDGE | O FLEDGE pode se tornar um mecanismo para impedir que os compradores criem perfis de SDA em solicitações de anúncios? | O FLEDGE foi criado para evitar o vazamento de informações irrelevantes quando o editor já sabe em quais SDAs os visitantes estão e a segmentação é no mesmo site. Se for importante oferecer suporte à compra em SDAs com todas as proteções integradas ao FLEDGE, uma solução pode ser o vendedor transmitir os rótulos de SDA para o leilão no dispositivo, e uma adtech do lado do comprador criar o próprio grupo de interesse com a lógica de lances "Quero comprar o público-alvo X". |
| Suporte para outras moedas além do dólar americano | Suporte para testar o FLEDGE com moedas diferentes do USD | Agradecemos a observação e adicionamos suporte a outras moedas no nosso backlog de solicitações de recursos. Esperamos que isso seja disponibilizado em breve. |
| Suporte à segmentação negativa por grupos de interesse | Uma API para oferecer suporte à segmentação negativa do Instagram: veicular anúncios somente se o usuário não pertencer a um grupo. | Discussão em andamento, incluindo algumas opções propostas para suporte, na questão do GitHub. |
| Várias SSPs no FLEDGE | Risco de favorecer o Google ao implementar leilões de vários níveis no FLEDGE | O suporte a várias SSPs no FLEDGE foi adicionado para oferecer um ambiente justo e equitativo. De acordo com os Compromissos, o Google prometeu não projetar, desenvolver ou implementar as propostas do Sandbox de privacidade de modo a distorcer a concorrência com a autoreferência de produtos e serviços de publicidade. O Google leva isso a sério e está aberto para discutir qualquer preocupação que as partes interessadas possam ter sobre aspectos específicos da tecnologia. O Chrome documentou publicamente o mecanismo de leilão de componentes neste link. |
Como medir 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 a vinculação determinística das impressões de um usuário (e, portanto, da identidade) em diferentes sites. Como resultado, essa funcionalidade na forma atual não está alinhada às metas 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 de epsilon para conferir como os relatórios mudam com base no nível de ruído. No momento, os desenvolvedores podem escolher um valor de epsilon até epsilon=64. Fizemos isso especificamente para facilitar o teste das APIs pelos desenvolvedores e receber feedback sobre os valores de epsilon adequados.
Também fizemos um pedido público para esse feedback. |
| Como testar a coordenação | A ferramenta de teste local pode ser usada para a OT? | Sim, a ferramenta de teste local pode ser usada durante a duração do OT. A ferramenta de teste local pode ser usada com relatórios de depuração, desde que os cookies de terceiros estejam disponíveis. |
| Ergonomia da consulta | Ativar o agregado de consulta de chaves | Concordamos que isso parece melhorar a ergonomia da API com pouco ou nenhum custo aparente de privacidade. Vamos fazer uma proposta e verificar se há um consenso amplo de que vale a pena apoiar. |
| 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 fatias de dados menores. No entanto, é possível que métodos como a agregação em períodos mais longos resolvam esse problema. Além disso, não está claro se as conclusões baseadas em fatias de dados muito pequenas (como uma ou duas compras) são significativas para os anunciantes. Durante o teste de origem, o Chrome incentiva os testadores a aproveitar a capacidade de experimentar uma ampla gama de parâmetros de privacidade e ruído para que possam fornecer feedback mais específico sobre esse problema. |
Limitar o rastreamento oculto
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 do UA-R na proteção contra bots | Agradecemos o feedback e estamos coletando informações sobre as abordagens de proteção contra bots para informar nossos designs futuros. |
| Dependências de implantação | Como lidar com dependências de implantação do user agent estruturado (SUA) | Lançamos a "Fase 4", ou seja, a redução da versão secundária para 100% dos usuários do Chrome nas versões 101 e mais recentes. Confira a atualização aqui. |
Dicas de cliente HTTP 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 saber todas as dicas compatíveis com um navegador. | Agradecemos o feedback e estamos avaliando a solicitação. Queremos entender se esse é um caso de uso comum. |
| Flexibilidade do UA-CH em comparação com o cabeçalho User-Agent | O UA-CH é excessivamente prescritivo em comparação com a flexibilidade oferecida pelo cabeçalho User-Agent, conforme definido por rfc7231. | O Chrome considera a natureza prescritiva dos cabeçalhos UA-CH uma melhoria importante em relação à flexibilidade da string UA, tanto do ponto de vista da interoperabilidade entre navegadores quanto da proteção da privacidade do usuário (evitando adições arbitrárias de identificadores de alta entropia).
O problema permanece aberto para que outras pessoas também possam compartilhar essa preocupação e enviar feedback. |
| UA-CH: preocupações com antifraude / antiabuso | Alguns recursos que podem ser perdidos no UA-CH: rastreador de redirecionamento de cliques e cliques fraudulentos. | A equipe está investigando esses possíveis problemas com as partes interessadas em medidas antifraude. |
| Desempenho | Há preocupações sobre a latência de receber dicas pelo 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 |
| Problemas de latência | Adicionar saltos extras pode afetar a latência | Estamos considerando um proxy de dois saltos e buscando maneiras de encontrar o equilíbrio certo entre a privacidade do usuário e a latência. Estamos abertos a feedback e adoraríamos discutir mais 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, porque buscamos maneiras de melhorar a privacidade do usuário de forma significativa, como o uso de proxy de endereços IP. Um proxy de dois saltos em parceria com empresas confiáveis oferece privacidade verificável do usuário. Também estamos desenvolvendo ideias para novos indicadores que ajudem a transmitir confiança aos usuários. |
| Conformidade com as leis de privacidade locais | Os relatórios de dados geográficos no nível do país dificultam a conformidade com regimes locais mais granulares | Publicamos nossos princípios propostos, que incluem possíveis abordagens para que os sites continuem em conformidade com os requisitos locais. |
Reforçar os limites de privacidade entre sites
Conjuntos próprios
| 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 objetivo principal 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 úteis para diferentes tipos e tamanhos de partes interessadas. Agradecemos comentários específicos e úteis sobre como essas soluções podem ser aprimoradas. Esperamos que elas continuem evoluindo com as discussões e testes da comunidade. |
| Melhorar a privacidade | Muitos sites no mesmo conjunto podem resultar em resultados semelhantes aos cookies de terceiros. | Agradecemos o feedback e estamos avaliando se ou quais seriam os limites certos, além de tentar oferecer aos usuários e desenvolvedores tratamento ou indicadores para que eles entendam quando esse limite for atingido. Ainda não temos uma proposta específica para compartilhar, mas esperamos que isso aconteça em breve. |
| Suporte ao ecossistema de QPS | Coleta de suporte e preocupações para continuar desenvolvendo FPS fora do Privacy CG | Embora preferíssemos que a proposta de conjuntos próprios permanecesse no PrivacyCG, esperamos continuar a buscar a proposta no WICG. Também ficamos animados com as várias declarações de apoio à discussão contínua sobre os conjuntos próprios e os casos de uso que eles pretendem abordar. O Google continua comprometido em encontrar soluções que permitam que a Web continue crescendo e prosperando, protegendo e respeitando a privacidade do usuário. |
| Interoperabilidade de navegadores | Implementação por outros navegadores | Reconhecemos a importância da interoperabilidade de navegadores para os desenvolvedores e vamos continuar colaborando com outros navegadores para buscar a padronização de QPS. |
| Requisito comum da política de privacidade | Não é viá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 considerar esse feedback. |
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 no modo sandbox | Agradecemos o feedback e a sugestão. Há uma discussão atual sobre isso no GitHub, onde esperamos esclarecer a solicitação para poder avaliá-la completamente. A discussão pública está disponível neste link. |
| Recursos entre APIs | Suporte padrão para relatórios de atribuição em frames restritos | Estamos solicitando feedback sobre uma proposta para permitir que a API Attribution Reporting funcione no "modo de anúncios opacos" de frames restritos por padrão. Recomendamos que os desenvolvedores que acharem isso útil participem 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 na quantidade de dados que podem ser armazenados por partição? | Sim, haverá limites. Consulte o problema do GitHub para mais detalhes. Vamos precisar de cotas de armazenamento. Nossa proposta atual é ter um limite de tamanho por entrada de 4 KB, e as chaves e os valores serão limitados a 1.024 caracteres char16_t cada, além de um limite de 10.000 entradas por origem com um mecanismo que impede que outras entradas sejam confirmadas quando a capacidade de uma origem estiver cheia. Estamos buscando feedback sobre os limites específicos propostos aqui. |
| Transparência do usuário | Transparência do usuário para fontes de dados versus uso de dados | Agradecemos o feedback e achamos que essa é uma abordagem promissora que vale a pena explorar. Em particular, estamos avaliando se seria possível fazer isso de uma forma que ofereça transparência suficiente aos usuários. |
CHIPS
| Tema do feedback
(Classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Impedimentos à adoção | O CHIPS precisa estar vinculado a um nome de host? (o requisito de nenhum domínio) | Estamos removendo esse requisito do OT com base no feedback dos participantes, que disseram que ele aumenta a complexidade e impede a adoção do CHIPS.
Vamos discutir esse requisito no grupo da comunidade de privacidade como parte da incubação de padrões aqui. |
| Casos de uso de anúncios para CHIPS | O CHIPS pode ser usado para casos de uso de anúncios em um único site? | O rastreamento 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 login é preservado com o CHIPS? | O estado de assinatura não é preservado no momento, mas não é o caso de uso pretendido para o CHIPS. Estamos cientes do caso de uso de incorporações autenticadas e estamos trabalhando para encontrar soluções. |
| Como testar a coordenação | Há outras ações necessárias para testar o particionamento? | Desde que o token OT seja válido e esteja presente nos cabeçalhos das páginas visitadas, o recurso estará disponível para os usuários sem que eles precisem realizar outras ações. |
| Compatibilidade com navegadores | Interesse em entender como outros navegadores trataram os 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 podem funcionar em vários navegadores. |
FedCM
| Tema do feedback
(Classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Vetores de ataque em potencial | Vetores de ataque em potencial por meio de ataques de decoração de links e de tempo | Estamos coletando feedback do público e investigando possíveis maneiras de resolver esse problema. |
| UX para permitir vários IdPs | Apenas um IDP pode ser apresentado por vez | Acreditamos no suporte a vários IDPs e estamos trabalhando ativamente em abordagens para oferecer |
| Expressividade | Preocupação de 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á avaliando a inclusão de personalizações de marca (por exemplo, logotipos, cores) e de strings (por exemplo, "acessar este artigo" em vez de "fazer login com").
O Chrome reconhece a compensação e vai continuar trabalhando com o ecossistema para cobrir o máximo possível e torná-lo o mais expressivo possível. |
| Aplicação e interoperabilidade | Preocupação de que outros navegadores não vão adotar ou implementar o FedCM. | O Chrome também está trabalhando com outros fornecedores de navegadores para encontrar soluções comuns de federação no FedID Community Group. |
| Sugestão para remover os requisitos de dados pessoais no fluxo de inscrição | (1) Uma UX que indique ao usuário qual IdP ele está escolhendo, sem indicar que o e-mail, a foto e o nome serão compartilhados, seria mais amigável à privacidade.
(2) O recurso "Use-cases-sign-up" é escasso na experiência do usuário e na seleção de declarações do IdP. |
Concordamos e estamos analisando como implementar o feedback de uma forma mais amigável para os usuários e a privacidade. |
| 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 | Particionar o estado da rede pode aumentar as conexões com uso intensivo de recursos para CDNs. | Ainda estamos investigando as características de desempenho do particionamento de estado da rede, incluindo a medição de diferentes esquemas de chaveamento possíveis. Ainda não tomamos uma decisão entre as compensaçõ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 de longo prazo | Nosso objetivo é criar uma tecnologia que funcione para o ecossistema, tornando o feedback da indústria e dos reguladores essencial para o processo. Vamos continuar consultando reguladores do mundo todo enquanto desenvolvemos o Sandbox de privacidade e disponibilizamos as propostas aos desenvolvedores, incluindo os Trust Tokens. Como acontece com todas as novas tecnologias, as empresas precisam tomar decisões com base na própria avaliação dos requisitos regulatórios. |
| Data de lançamento | Quando os Trust Tokens serão lançados para a versão GA? | As estimativas atuais de entrega estão disponíveis na nossa linha do tempo pública em privacysandbox.com. Assim que tomarmos uma decisão final sobre a data de entrega para a versão GA, vamos publicar publicamente nos processos de lançamento do Chrome e atualizar a linha do tempo no site. |
| Tokens de confiança x outros | Qual é o papel dos Trust Tokens, considerando que os outros tokens estão sendo padronizados, como os Tokens de acesso particulares? | Estamos envolvidos em discussões de padronização, e nosso objetivo é nos alinharmos com outros esforços o máximo possível, além de permitir os diferentes casos de uso que cada tecnologia oferece. Por exemplo, os Trust Tokens e os tokens de acesso particulares dependem do protocolo Privacy Pass. |
| Limites de dados | O limite máximo de 2 emissores para resgate de tokens por página pode ser limitado | 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 dividindo o acesso aos resgates de tokens. |
| Restrições de acesso | Somente as origens aprovadas (e verificadas/não falsificadas) podem verificar a presença de um token e fazer o resgate. | Estamos estudando abordagens para quem pode ver e resgatar tokens. |
| Suporte do dispositivo | As dependências do ambiente de execução do JavaScript limitam o uso em determinados dispositivos. O suporte ao 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 sobre o qual gostaríamos de receber mais feedback dos desenvolvedores nos fóruns do W3C. Também temos um problema aberto para discutirmos uma ativação de token acionada por cabeçalho HTTP que convidamos para feedback. |
| Casos de uso | Não está claro quais são os casos de uso corretos para os Trust Tokens. Falta de clareza sobre os usos pretendidos. | Nosso objetivo é facilitar a inovação no espaço de combate à fraude e entender que cada empresa pode empregar técnicas exclusivas com tokens de confiança. Por isso, não estabelecemos regras quanto ao uso pretendido. No entanto, provavelmente vamos expandir nossa documentação para incluir mais exemplos como ponto de partida para parceiros que estão considerando a experimentação 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 do token de confiança. | Isso é considerado ao coletarmos feedback do OT e tomarmos decisões sobre as próximas etapas. |
| Confiança do emissor | Por que devemos confiar em sites que emitem tokens de confiança? | Não há diretrizes para se tornar um emissor. Qualquer pessoa pode fazer isso. Espera-se que os editores trabalhem apenas com emissores confiáveis. Além disso, outros atores legítimos no ecossistema de anúncios acabariam descontando (ou parando de comprar) o tráfego associado a emissores suspeitos ou desconhecidos. |
| Serviços incorporados de terceiros | Os serviços integrados de terceiros podem resgatar e/ou solicitar tokens de confiança? | Sim, um serviço integrado de terceiros pode emitir e resgatar tokens de confiança. |
| Ecossistema de emissores | É possível alcançar uma utilidade maior se os indicadores de confiança puderem ser compartilhados com outras empresas | Os Trust Tokens foram projetados para serem primitivos de baixo nível e podem ser usados por emissores/resgatadores que cooperam para compartilhar indicadores de confiança/reputação. |
| Despesas gerais com manutenção | A implementação criptográfica subjacente às operações de token de confiança está no BoringSSL, que é mantido exclusivamente pelo Google. Como a manutenção da biblioteca será gerenciada? | Os Trust Tokens dependem de operações criptográficas padronizadas (consulte Protocolo de passe de privacidade) que também podem ser implementadas em outras bibliotecas. Recomendamos que os desenvolvedores solicitem/desenvolvam/mantenham o suporte a essas operações nas bibliotecas de escolha deles. |
| Despesas gerais com manutenção | Não está claro por quanto tempo as versões do protocolo terão suporte | Estamos desenvolvendo e documentando mais detalhes sobre os prazos de suporte esperados para as versões do protocolo. |
| Limites do emissor | Se você estiver mais abaixo na cadeia, talvez não tenha a oportunidade de executar tokens de confiança. | À medida que mais organizações começarem a usar tokens de confiança, poderemos observar cada vez mais esses tipos de dinâmica de tempo em jogo e estamos investigando possíveis soluções. Como descrito anteriormente, 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, o que minimizaria a importância da posição na página ou da ordem de carregamento. |
Novas soluções de combate à fraude em incubação
| Tema do feedback
(Classificado por prevalência) |
Resumo de perguntas e dúvidas | Resposta do Chrome |
| Indicadores de atestado de integridade do dispositivo | Geralmente, há um forte suporte para a busca de indicadores de integridade do dispositivo atestados por plataformas e disponibilizados na Web | Vamos continuar coletando feedback e buscando a proposta por meio de design e iteração pública. |
| Indicadores de atestado de integridade do dispositivo | Perguntas sobre a quantidade de entropia do usuário que pode ser transmitida por novos indicadores e se determinados casos de uso (como um usuário fazendo login no banco) podem justificar indicadores de entropia mais altos. | Preferimos fornecer indicadores de alto valor com o mínimo de entropia possível para preservar a privacidade do usuário. |
| Indicadores de atestado de integridade do dispositivo | Esse indicador limitaria o acesso a dispositivos mais antigos ou plataformas modificadas/de código aberto? | Todos os novos indicadores precisam considerar o acesso universal como um princípio fundamental no desenvolvimento. Essas são perguntas importantes que precisam ser abordadas de antemão à medida que continuamos a incubação. |
| Indicadores de atestado de integridade do dispositivo | Havia alguma preocupação de que os novos indicadores fizessem com que as empresas de segurança e antifraude dependessem demais do navegador e das plataformas.
|
Qualquer novo indicador precisa ser considerado como dados complementares, e não uma indicação de "confiança" do navegador. Esperamos que as empresas de segurança continuem a depender dos próprios dados, modelos e mecanismos de decisão com atestado de dispositivo como entrada extra. Esperamos que qualquer novo indicador melhore os esforços de detecção em todo o ecossistema e dificulte a execução de fraudes. |
| Indicador de idade do cookie | Conceito interessante, mas provavelmente requer mais investigação sobre os casos de uso aplicáveis. | Dependendo do nível de interesse, o Chrome pode desenvolver mais ideias sobre esse conceito e transformá-lo em uma explicação para futuros feedbacks do ecossistema. |
| Servidores confiáveis para prevenção de fraudes | Conceito interessante, mas provavelmente requer mais investigação sobre os casos de uso aplicáveis. | Dependendo do nível de interesse, o Chrome pode desenvolver mais ideias sobre esse conceito e transformá-lo em uma explicação para futuros feedbacks do ecossistema. |