Relatório trimestral do 1o trimestre de 2023 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 do 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 |
|---|---|---|
| Testes | Relevância do teste para informar a avaliação da CMA se as APIs do Sandbox de privacidade não forem concluídas no momento em que o teste começar | O desenvolvimento das APIs do Sandbox de privacidade está avançando no ritmo.
Eles já estão disponíveis no teste de origem para testes e vão estar
com disponibilidade geral para 100% do tráfego neste verão. Além disso, esclarecemos os cronogramas para determinados recursos, como relatórios no nível do evento do FLEDGE e renderização do FLEDGE com iframes, que não vão ser afetados antes de 2026. Incentivamos o ecossistema a testar as APIs e enviar feedback à CMA com base no que os testadores esperam quando os cookies de terceiros forem descontinuados. Isso pode contribuir para a avaliação do impacto provável da descontinuação dos cookies de terceiros. |
| Controles de usuário | Orientação clara para o ecossistema sobre as implicações dos controles do usuário das APIs do Sandbox de privacidade | Não podemos fornecer aconselhamento jurídico sobre o que os controles de usuário que o ecossistema pode usar. Ao mesmo tempo, o Chrome está testando a exibição de controles atualizados do Sandbox de privacidade ("Privacidade avançada de anúncios") para uma porcentagem muito pequena de usuários, como parte do nosso esforço contínuo para melhorar as tecnologias do Sandbox de privacidade. As atualizações incluem linguagem e layouts mais claros e úteis. Depois que o Chrome avaliar esses refinamentos e decidir se vai expandi-los para uma população maior, ele poderá compartilhar mais informações com o ecossistema. |
| Vazamento de dados | Risco de vazamento de dados próprios para o Google e outras partes no caso de o navegador ser comprometido | Nossa explicação do
FLEDGE deixa evidente que os dados de uma adtech só são compartilhados
com essa mesma adtech (com os Worklets ou os servidores
confiáveis) ou quando explicitamente compartilhados por essa adtech (como um comprador
mostra ao vendedor o URL do anúncio que quer mostrar). A única exceção é que a verificação de k-anonimato precisa ser feita por um servidor centralizado global, que é uma área para a qual continuamos dedicando recursos significativos. Consulte o artigo Explicação
sobre K-anonimato para ter uma visão detalhada de como pensamos sobre
privacidade. Além disso, podemos dar mais detalhes sobre as proteções de adtech usadas no design do servidor de k-anonimato. |
| Fórum adicional para discussão | Solicitação de um fórum adicional ao W3C para participantes do ecossistema não técnico compartilharem feedback | O formulário de feedback
do Sandbox de privacidade é adequado para comentários gerais e
específicos, técnicos e não técnicos. O grupo de negócios Como melhorar a publicidade na Web é um fórum de discussão por chamadas semanais e um repositório do GitHub (em inglês). A página Feedback do Sandbox de privacidade em developer.chrome.com explica outros mecanismos para fornecer feedback e participar de discussões. O Chrome também continua realizando eventos, como horários de atendimento público, para facilitar perguntas e compartilhamento de conteúdo. Além disso, o Chrome já organizou ou participou de mais de dezenas de eventos do setor no último trimestre. |
| Esclarecimento sobre o cronograma | Esclarecimento sobre a data exata da disponibilidade geral no terceiro trimestre de 2023 | De acordo com o cronograma publicado em PrivacySandbox.com (link em inglês), a disponibilidade geral está prevista para começar o lançamento com o lançamento da versão 115 do Chrome. |
| reCAPTCHA | Impacto das APIs do sandbox para o caso de uso de detecção de spam da reCATPCHA | Recebemos feedback do reCAPTCHA periodicamente para garantir que as propostas do Sandbox de privacidade não afetem significativamente a segurança ou fraudes na Web. Eles estão desenvolvendo o próprio plano de preparação e ajuste para a descontinuação dos cookies de terceiros. Portanto, essa pergunta é mais bem respondida por eles. |
| Extensões do Chrome | As tecnologias do Sandbox de privacidade, como as medidas de rastreamento anticoversão (ACT, na sigla em inglês), se aplicam às extensões do Chrome? | Não anunciamos se as ACT podem ser aplicadas às extensões do Chrome. No entanto, se uma tecnologia coletar informações sobre um usuário disfarçado, isso não se alinha com nossos princípios de privacidade. |
Mostre conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Revisão do design da TAG | A TAG lançou a Early Design Review of Topics. | Continuamos comprometidos com a API Topics e compartilhamos uma atualização sobre esse compromisso na página de atualizações mais recentes e neste problema (links em inglês). Respondemos à análise do TAG em detalhes e compartilhamos nossa visão geral aqui. A API Topics vai continuar fazendo parte do conjunto de APIs que o ecossistema de anúncios vai testar em 2023. Esperamos que o feedback dos testes e a experiência dos implementadores sejam contribuições valiosas em iniciativas futuras para implementar padrões em vários navegadores. Esperamos continuar interagindo com o ecossistema para facilitar uma possível transição em que a API Topics pudesse ser um padrão acordado com compatibilidade entre navegadores. |
| Abordagem da API Topics | Suporte para a abordagem aberta do Chrome para desenvolver a API Topics | Agradecemos a opinião e esperamos continuar trabalhando com o grupo do setor para desenvolver uma API Topics que agregue valor ao ecossistema em geral. |
| (Também informado no 3o trimestre de 2022) A taxonomia dos temas não é granular o suficiente |
A taxonomia de tópicos amplos não inclui tópicos mais granulares, incluindo específicos da região. | Atualização do 1o trimestre: As melhorias na taxonomia são um esforço contínuo. No segundo trimestre, vamos anunciar uma atualização para a API Topics. Para criar essa nova taxonomia, trabalhamos em estreita colaboração com empresas de todo o ecossistema. Queremos receber feedback sobre qual taxonomia seria mais útil para o ecossistema. Ao avaliar se é necessário expandir o número de temas ou incluir outros mais detalhados, você precisa considerar: 1) possíveis implicações de privacidade (mais temas podem gerar risco de técnicas de impressão digital) e 2) a capacidade de recuperar temas observados anteriormente. Por exemplo, com mais temas, pode haver menos chances de uma adtech ter visto o tema escolhido no passado. |
| (Também informado no 4o trimestre de 2022) 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. | Acreditamos que a publicidade com base em interesses é um caso de uso importante para a Web, e a API Topics foi projetada para oferecer suporte a esse caso. Entendemos que alguns grandes editores têm receio de que a API Topics afete negativamente as estratégias de dados próprios. Esperamos os testes do ecossistema, que vão fornecer insights sobre o impacto da API Topics sobre os editores. |
| Casos de uso de temas não relacionados a anúncios | Uso da API Topics para outros fins que não a exibição de publicidade com base em interesses | A API Topics foi projetada para abordar o caso de uso de publicidade com base em interesses, que acreditamos ser um caso de uso crítico para a Web livre e aberta. No momento, estamos buscando feedback sobre outros casos de uso e estamos avaliando. |
| Status de ativação padrão | Impacto da legislação regional no padrão de consentimento da API Topics | Não é nossa posição para comentar opiniões jurídicas. |
| (Também informado no 3o trimestre de 2022) Sites classificados incorretamente |
Segmentação de anúncios quando os tópicos de um determinado site estão classificados incorretamente | Atualização do 1o trimestre: No segundo trimestre, vamos anunciar um classificador atualizado para a API Topics e estamos ansiosos para interagir com o ecossistema dessa API. Em resposta ao feedback atual, os sites são classificados com uma combinação de uma lista de substituição selecionada por humanos, que contém os sites mais acessados e um modelo de ML no dispositivo. O Chrome continua avaliando opções de sites para contribuir para a classificação da API Topics. Quaisquer melhorias de utilidade devem ser ponderadas em relação aos riscos de privacidade e de abuso. Por exemplo, alguns dos riscos incluem: sites que usam autoidentificação como método para codificar significados diferentes (e possivelmente sensíveis) em temas, sites que deturpam temas para ter ganho financeiro ou sites que atacam a utilidade deles para outras pessoas (por exemplo, enviando spam aos tópicos do usuário com ruído sem sentido). O público pode inspecionar esses componentes, com ferramentas disponíveis no chrome://topics-internals ou neste Colab. Durante os testes, esperamos que a classificação melhore com o tempo, e recebemos feedback de exemplos de sites que podem ser classificados incorretamente. |
| Classificador de temas | Solicitação para retornar mais informações mostrando os motivos em que a mensagem "No Topics" é retornada ao autor da chamada para fins de depuração | Entendemos que as ferramentas de depuração são úteis para os desenvolvedores, porque trabalham para integrar a API Topics aos sistemas. No entanto, ao expor mais informações, como o motivo por que nenhum tema foi retornado, podemos compartilhar acidentalmente informações que permitem às partes descobrir mais detalhes (por exemplo, se um usuário está no modo de navegação anônima, desativou a API etc.) além do esperado, prejudicando a privacidade do usuário. Não planejamos fornecer outras ferramentas de depuração no momento, mas estamos abertos a feedback sobre quais ferramentas seriam valiosas. |
| Recuperação de informações particulares (PIR, na sigla em inglês) | Solicitação da API Topics para adotar a recuperação de informações particulares | Já investigamos com o uso de PIR e compartilhamos as vantagens e desvantagens aqui. |
| Fluxo de lances | Os temas vão ser representados de forma diferente dos públicos-alvo definidos pelo vendedor no fluxo de lances? | A API Topics é uma proposta do Sandbox de privacidade desenvolvida pelo Chrome, que é diferente da proposta Públicos-alvo definidos pelo vendedor do IAB Tech Lab. Esperamos que os dois sejam representados de forma distinta no bidstream. Saiba como a API Topics vai ser representada nas solicitações de lance do OpenRTB. |
API Protected Audience (antiga FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Disponibilidade de recursos do FLEDGE | Esclarecimento sobre os cronogramas de teste e implementação de recursos do FLEDGE, como a aplicação de Fenced Frame, K-Anonimato, entre outros. | Compartilhamos uma postagem do blog (link em inglês) sobre vários recursos do FLEDGE com escopo e quando vão ser compatíveis. Agradecemos mais feedback sobre o anúncio à medida que continuamos desenvolvendo o FLEDGE. |
| Restrições de renderização do produto | Solicitação para flexibilizar os anúncios compostos por várias restrições de elementos para frames isolados do FLEDGE. | Como anunciamos em fevereiro, o uso do Fenced Frames vai continuar opcional até pelo menos 2026, e o comportamento dos iframes terá suporte de urn-iframes. Gostaríamos de receber mais discussões sobre esse tópico. |
| Problemas de escalonabilidade | Desempenho do FLEDGE à medida que o uso aumenta | Estamos acompanhando de perto o feedback e entendendo mais contexto para que possamos propor soluções úteis. A primeira etapa foi separar o feedback em duas categorias, o que fizemos:
|
| (Também informado no 3o trimestre de 2022) Visibilidade da lógica de lances |
Preocupação com a exposição da lógica de lances de DSP em JavaScript | Atualização no 1o trimestre: Compartilhamos uma proposta que limita a capacidade de adversários de solicitar dados do servidor de forma exploratória (navegação forçada), e convidamos as partes interessadas do ecossistema a compartilhar feedback ou suporte à proposta. |
| Dificuldades de teste | Capacidade de DSPs menores testarem corretamente o FLEDGE e reduzir o risco de que os anunciantes só tenham interesse em testar com DSPs maiores | Temos o compromisso de trabalhar com DSPs menores e incentivamos os testes expandidos entre DSPs e anunciantes de todos os tamanhos à medida que o FLEDGE muda para disponibilidade geral. Queremos saber como podemos ajudar melhor a testar o FLEDGE com outras pessoas no ecossistema e receber ideias e esforços do setor para motivar os anunciantes a testar com DSPs menores. |
| Remarketing dinâmico | O remarketing dinâmico ainda vai ser possível com o FLEDGE após a descontinuação dos cookies de terceiros? | Estamos pensando em responder a essa pergunta e convidamos os participantes do ecossistema a compartilhar mais insights sobre como eles pretendem usar o remarketing dinâmico. |
| Fraude/abuso | Como o ecossistema pode reduzir os riscos e impedir que usuários de má-fé ou compradores se posicionem como um público-alvo desejável? | Esperamos interagir mais com agentes do ecossistema sobre fraudes e abusos e receber mais feedback nessa área. |
| Preferências do usuário | Processo para salvar as preferências do usuário e usá-las na seleção de anúncios | Para anúncios específicos, a adtech relevante é a melhor posicionada para oferecer controles sobre quais criativos são exibidos ou como eles são selecionados. |
| Proposta de teste quantitativo | Para que o teste quantitativo seja justo, ele precisa ser realizado no tráfego sem cookies de terceiros ou com SSPs que usam apenas o FLEDGE? Como a mistura de indicadores de cookies de terceiros pode ser evitada? | Agradecemos esse feedback e estamos trabalhando com a CMA para criar experimentos que forneçam uma imagem confiável do impacto da descontinuação dos cookies de terceiros e da introdução das propostas do Sandbox de privacidade no ecossistema. Recomendamos que mais feedback sobre a proposta de teste quantitativo da CMA seja compartilhado diretamente com ela. |
| Documentação mais clara | Solicitar documentação mais clara sobre a configuração do leilão | Nas próximas semanas, vamos compartilhar uma postagem do blog com mais informações gerais sobre os relatórios de leilão do FLEDGE. |
| Carregamento em paralelo | O serviço de lances e leilões (B&A) é compatível com o carregamento em paralelo? | Uma adtech que usa servidores de lances / leilões pode iniciar vários servidores que podem veicular resultados em paralelo. |
| Mitigação de abusos | O servidor de k-anonimato do FLEDGE que usa tokens de estado particular é suficiente para garantir a privacidade do usuário? | A motivação do k-anonimato é menos focada na microsegmentação e mais em ter alguma restrição durante a fase provisória em que o FLEDGE permite relatórios no nível do evento. Compartilhamos mais ideias e enviamos seu feedback. |
| Conflito entre módulo ES | Solicitação para descartar generateBid como uma função global, já que ele entra em conflito com
o módulo ES |
Estamos discutindo essa solicitação e agradecemos seu feedback. |
| Leilão de componentes | Pedir para os editores terem mais controle sobre os designs de leilões | Plano de lances e leilão para suporte ao leilão de componentes, assim como o Chrome no dispositivo. |
| Linhas do tempo de B&A | Clareza sobre o cronograma para adtechs interessadas em testar servidores de B&A | Acabamos de atualizar o explicativo de B&A e atualizamos a seção "Linha do tempo" para incluir definições claras de cronogramas para diferentes fases do teste de B&A, após o alinhamento com a CMA. |
| Esquema de controle de tempo limite | Melhoria no esquema de controle de tempo limite atualmente disponível para o FLEDGE | Essa proposta é interessante. Vamos adicionar isso à fila de propostas para estudo e relatar nossos desenvolvimentos. |
| Fluxos de lances de criativos | Capacidade de revisar e filtrar um lance vencedor com base no criativo | Essa proposta é interessante. Vamos adicionar isso à fila de propostas para estudo e relatar nossos desenvolvimentos. |
reportWin |
Proposta de inclusão de informações sobre o lance de maior pontuação de um proprietário do grupo de interesse diferente do vencedor na função reportWin |
Essa proposta é interessante. Considere adicionar outros indicadores nos relatórios agregados e receberá mais feedback aqui. |
| Tipos de evento | Padronização de tipos de evento nas APIs de medição quando integrada ao FLEDGE | Essa proposta é interessante. Vamos adicionar isso à fila de propostas para estudo e relatar nossos desenvolvimentos. Isso vai exigir coordenação com nossos esforços mais amplos nesse campo, já que afetaria outras APIs do Sandbox de privacidade além do FLEDGE. Queremos receber mais feedback aqui. |
| Soluções de longo prazo para relatórios de eventos | Interesse em manter determinados dados, como highestScoringOtherBid, disponíveis mesmo após a descontinuação dos cookies de terceiros |
Como anunciamos na postagem do blog de fevereiro, os relatórios de vitórias de leilões no nível do evento terão suporte até "pelo menos 2026". Não temos mais detalhes para compartilhar agora, mas gostaríamos de receber mais feedback sobre a importância de manter determinados dados disponíveis após a descontinuação dos cookies de terceiros. |
| Limite de grupos de interesse | Qual é o limite para o número de grupos de interesse a que uma origem pode adicionar um único navegador? | O Chrome permite até 1.000 grupos de interesse por proprietário, e até 1.000 proprietários de grupos de interesse. Elas servem para proteger, não para serem atingidas em condições normais. |
| Indicadores no nível do evento | Suporte a uma proposta para ter indicadores de evento para generateBid
e reportWin, que podem ser usados no treinamento de machine learning |
Compartilhamos nossa decisão sobre indicadores projetados pelo navegador e definidos pelas tecnologias de anúncios e agradecemos seu feedback. |
| Script de lances | Inclua o ID do usuário no URL do script de lance. | Isso não vai ser possível porque o FLEDGE tem o requisito extra de que a tupla do proprietário do grupo de interesse, o URL do script de lances e o criativo renderizado precisam ser k-anônimos para que um anúncio seja mostrado. |
| Aplicação do k-anonimato | O k-anonimato é aplicado ao par (componentAd, size)? | Sim. Consulte turtledove/issues/312. |
| Requisitos para serviços de lances e leilões | Como os serviços de B&A ajudam os participantes na integração com o FLEDGE no dispositivo e outros com os serviços de B&A? | Ainda estamos finalizando o design e recebemos seu feedback adicional. |
| Atribuição pós-visualização | A atribuição pós-visualização vai ter suporte? | No momento, não temos nenhum tipo de definição padrão de visibilidade e contamos com o próprio criativo para marcar um evento de visualização. Consulte turtledove/issues/452. |
| Segmentação semelhante | O Sandbox de privacidade pode oferecer suporte a "segmentação parecida?" | Estamos discutindo o caso de uso aqui e são bem-vindos a outras entradas. |
| API Real-time Monitoring | Proposta de uma abordagem de monitoramento do FLEDGE em tempo real | Estamos discutindo a proposta e aceitamos outras informações aqui. |
| Relatórios do FLEDGE | reportWin e reportResult precisam ser criados em ordem aleatória para evitar
relatórios excessivos ou insuficientes. |
reportResult() precisa ser executado primeiro pelo vendedor antes de
reportWin() pelo comprador para que os indicadores de vendedor de reportResult()
possam ser incluídos em reportWin(). Consulte a
explicação para mais informações. |
| Servidores de chave-valor personalizada (K/V) | Os servidores K/V personalizados terão suporte no futuro? | Estamos discutindo a questão aqui e aceitamos qualquer entrada adicional. |
| Leilão de nível superior | É preciso ser o servidor de anúncios para executar a mecânica de leilão de nível superior? | A API FLEDGE não especifica qual parte precisa chamá-la. Não há requisitos nesse sentido no design do FLEDGE. Qualquer pessoa pode realizar o leilão do FLEDGE, incluindo leilões com vários vendedores. Como mencionado no relatório do 4o trimestre de 2022, o FLEDGE permite que cada editor escolha a estrutura do leilão, incluindo a escolha dos vendedores de nível superior e de componentes. |
| Escopo da API | O FLEDGE pretende trabalhar com dados próprios? | Vamos publicar conteúdo no segundo trimestre de 2023 para esclarecer que os dados próprios podem ser usados com o FLEDGE para: 1) usar como lógica para determinar a associação ao grupo de interesse e 2) alimentar como indicadores de lances do usuário para uso posterior na geração de lógica de lances. |
| Grupos de interesse em vários domínios | Possibilidade de criar grupos de interesse em vários domínios | Qualquer informação disponível no momento da adição de um navegador a um grupo de interesse pode ser usada para informar esse público-alvo. Quando os cookies de terceiros forem desativados, a disponibilidade de dados entre sites para ajudar na criação do grupo de interesse será limitada. |
| Lógica de lances do lado do cliente | Portabilidade da lógica de lances do lado do servidor para o cliente | Temos interesse em saber mais sobre quais áreas são desafiadoras ou quais não estão no processo de portabilidade. Envie seu feedback ou insights. |
| Valores do servidor K/V | Os valores do servidor K/V precisam ser do tipo string? | O valor precisa ser uma string, mas é possível armazenar objetos em JSON ou buffer de protocolo e serializá-los em string. |
| Lista de bloqueio de anunciantes | Quais indicadores seriam apropriados para fornecer um comprador a uma lista de bloqueio de anunciantes? | O local apropriado está em auctionSignals ou em perBuyerSignals. |
| Unidade de lance | Suporte a unidades de lances diferentes, como CPI e CPM | Gostaríamos de saber mais sobre por que isso é necessário devido ao design atual e gostaria de receber mais feedback. |
| Lógica de leilão | O navegador ou o servidor de anúncios decide o vencedor de um leilão? | Todas as escolhas do vencedor são executadas no sandbox, e todas as decisões são tomadas pelo código do vendedor. O navegador simplesmente fornece um ambiente particular e fechado dentro do qual o código do comprador e do vendedor é executado. |
| Permissões-Política | A política de permissões do FLEDGE atual vai continuar sendo aplicada após o término do teste de origem? | Para o teste de origem, as listas de permissões padrão atuais dos dois recursos são temporárias e serão alteradas. Queremos saber quanto tempo as adtechs precisarão se preparar para a mudança antes de começarmos a aplicá-la. |
| Restrição de tamanho do indicador | As solicitações de indicadores de lances confiáveis são agrupadas em vários
grupos de interesse com o mesmo trustedBiddingSignalsUrl. O limite de tamanho
de 2 MB é uma restrição. |
A restrição existe para autores de chamada no dispositivo a fim de evitar sobrecarregar recursos no dispositivo. Os autores da chamada de um servidor de B&A terão uma restrição mais relaxada. |
| Indicadores de relatórios | Adicione mais um indicador, erros de script, para permitir a recuperação do número de erros do lado do cliente por proprietário do grupo de interesse e por computeBid ou reportWin / reportResult. |
Estamos considerando possíveis preocupações com a privacidade dessa proposta e recomendamos que os participantes do ecossistema possam compartilhar mais insights sobre por que isso é necessário. |
| Tamanho da janela K-Anon | Aumente o tamanho da janela de K-Anonimato do limite atual de 7 dias. | Estamos considerando essa questão e estamos aguardando (e agradecemos) outras entradas do ecossistema. |
| Performance do dispositivo | Como o FLEDGE lida com o desempenho do dispositivo se o usuário está em um grande número de grupos de interesse? | O FLEDGE oferece várias opções de limite, priorização e tempo limite entre SSPs e DSPs que dão às adtechs um controle refinado em situações em que o desempenho do dispositivo pode ser um motivo para limitar a participação no leilão quando ele está em um grande número de grupos de interesse. |
| Teste dos serviços de B&A | Solicitar que os participantes do ecossistema usem o próprio servidor durante a fase de teste para que mais registros estejam disponíveis para depuração. | Com o B&A, os usuários podem iniciar e escalonar os servidores usando provedores de nuvem aprovados. Para manter a privacidade do usuário, exigimos que a execução seja feita em um ambiente de execução confiável (TEE). Em breve, vamos lançar uma explicação sobre a depuração do B&A TEE e estamos desenvolvendo recursos para isso. Estamos procurando mais feedback sobre o assunto. |
| Requisitos regulatórios | O FLEDGE vai trabalhar com provedores de nuvem em diferentes países para conseguir conformidade com os requisitos regulamentares locais? | Estamos sempre abertos a sugestões para outros provedores de nuvem, mas atualmente planejamos oferecer compatibilidade com o GCP e a AWS quando a descontinuação dos cookies de terceiros for aplicada. Consulte esta explicação para mais informações. |
Medir os anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Análise de dados de impacto de ruído | Orientação sobre como realizar uma análise de dados sobre o impacto do ruído | Compartilhamos mais
documentação sobre decisões de ruído e design que podem ser
usadas para mudar o impacto deles nos dados de adtech. Também há um guia mais detalhado disponível. |
| Relatórios nulos | Clareza sobre a implementação de relatórios nulos | No momento, estamos trabalhando em uma proposta de implementação de relatórios nulos e vamos compartilhar mais detalhes em breve. Com a implementação de relatórios nulos, é possível reduzir os atrasos nos relatórios sem comprometer a privacidade. |
| Nível de ruído | Ajustar o nível de ruído com base na duração da janela de atribuição | Essa proposta é bem-vinda e queremos que ela seja adicionada à especificação. Gostaríamos de receber mais feedback. |
| Tamanho dos dados do gatilho | Por que o tamanho dos dados do acionador é limitado a 3 bits? | O tamanho é limitado a 3 bits e 8 valores distintos para garantir que a quantidade de informações entre sites/contexto sobre um usuário seja limitada. Pedimos que os participantes do ecossistema enviem feedback se a parametrização atual dos relatórios de eventos faz sentido. |
| Acionadores de relatórios a nível de evento | Permitir a priorização em uma chave de eliminação de duplicação | Estamos explorando soluções para esse problema e aceitamos outras informações. |
| Compatibilidade com depuração | Esclarecimento sobre a depuração após a descontinuação dos cookies de terceiros | Gostaríamos de dar suporte à depuração após a descontinuação de cookies de terceiros e estamos pensando em opções. Precisamos de mais feedback e ideias. |
| Alternativas de conversão de clique | Pedir mais orientações sobre alternativas para conversões de clique | Incentivamos o ecossistema a usar a API Attribution Reporting como um sistema de medição particular durável para casos de uso aplicáveis de medição de conversões. Outras alternativas existem, e os provedores de adtech precisam decidir a solução adequada com base nas necessidades de privacidade e utilidade desejadas. |
| Casos de uso de faturamento | Esclarecimento sobre como a API Attribution Reporting vai oferecer suporte a casos de uso de faturamento com base em conversões | Estamos trabalhando em postagens públicas para esclarecer o escopo de faturamento
da API Attribution Reporting. Inicialmente, a API Attribution Reporting
não tinha um escopo definido para oferecer suporte direto ao faturamento de CPA. Ela
oferece suporte ao faturamento de CPC e CPM, que é a estrutura de faturamento que a
maioria das adtechs usa. Isso é algo que poderemos oferecer no futuro se houver outro feedback do ecossistema. |
| Suporte a casos de uso | Documentação do caso de uso da API Measurement | Estamos trabalhando para esclarecer a documentação de todas as plataformas de geração de relatórios do Sandbox de privacidade. |
| Qualidade do clique | Solicitar a adição de indicador para distinguir cliques intencionais e não intencionais em um anúncio | Vamos discutir a solicitação e receber informações adicionais. |
| Solução de métricas | Suporte para soluções de métricas em várias DSPs | A API Attribution Reporting pode ser usada por provedores de métricas para
eliminar a diferença entre várias DSPs. Além disso, propomos
que as DSPs ofereçam suporte a uma lista de URLs no attributionsrc,
o que vai facilitar o suporte das DSPs às solicitações da API Attribution Reporting
do provedor de métricas. Agradecemos qualquer feedback
adicional sobre a proposta acima. |
| Relatórios no nível do evento | Solicite a disponibilidade do número de dias antes do envio do relatório diretamente. | Essa solicitação já pode ser calculada por adtechs usando as informações disponíveis no momento. Não recebemos nenhum feedback do ecossistema sobre essa solicitação, mas estamos abertos a feedback sobre ela. |
source_registration_time |
Adicione source_registration_time aos Relatórios de atribuição no nível do evento. |
Estamos analisando esse pedido e queremos receber mais feedback sobre se ele é útil para os agentes do ecossistema. |
| Modo de navegação anônima | As soluções de métricas estarão disponíveis quando o usuário estiver no modo de navegação anônima? | Não, as soluções de métricas não ficam disponíveis no modo de navegação anônima. Os cookies de terceiros ficam desativados por padrão no modo de navegação anônima. |
| Data clean rooms | As APIs de medição serão compatíveis com data clean rooms? | Uma data clean room típica é um ambiente em que dados de identificadores individuais de diferentes fontes são carregados em um banco de dados para executar análises com base na combinação desses dados. Os dois frameworks de medição das APIs do Sandbox de privacidade são relatórios de eventos e relatórios de resumo. Os relatórios de eventos contêm um ID de evento fornecido pela adtech que pode ser usado em uma data clean room, mas as informações de conversão associadas são limitadas e confusas. Os relatórios agregáveis criptografados não podem ser usados diretamente em uma sala limpa, mas os resultados resumidos fornecidos pelo serviço de agregação podem ser usados como entrada para análises realizadas ou como informações suplementares. |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informados no 4o trimestre de 2022) Atrasos nos relatórios |
Qual é o atraso esperado na geração de relatórios? | Atualização do 1o trimestre de 2023: Após o feedback dos parceiros, compartilhamos propostas para diminuir o atraso e reduzir o impacto do atraso. As duas propostas têm suporte de adtechs durante chamadas do WICG. |
| Nenhuma regra de duplicatas | Como processar um "relatório agregável atrasado" se relatórios agregáveis, que têm o mesmo ID compartilhado, já foram processados? | Compartilhamos uma proposta sobre como adicionar atraso extra às informações compartilhadas de relatórios agregáveis e definir o ID compartilhado do serviço de agregação para resolver parcialmente o impacto da perda de atraso na API agregada. Qualquer feedback sobre a proposta é bem-vindo. |
| Processamento de dados | Pedir para ativar o suporte a várias transmissões de dados, respeitando a privacidade diferencial, usando o Orçamento de privacidade | Estamos discutindo a possibilidade de usar uma maneira mais flexível de consumo do Orçamento de privacidade para possibilitar esse caso de uso. Queremos receber mais feedback. |
| (Também relatado no 2o trimestre de 2022) Ergonomia de consulta | Ativar consulta de agregação de chaves. | Atualização do 1o trimestre de 2023: A solicitação de recurso ainda está sendo considerada, mas não temos nenhuma proposta para compartilhar no momento. |
| Limitações do teste de origem | Esclarecimento do escopo do serviço de agregação, como a regra "sem duplicatas", que não é aplicada atualmente no teste de origem. | Estamos procurando atualizar nossa documentação para esclarecer o que vai estar disponível no teste de origem e no GA. |
API Private agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Orçamento de contribuição da agregação particular | O orçamento de contribuição L1 é muito restritivo. | Cada chamada para a API Private Aggregate é chamada de contribuição. Para
proteger a privacidade do usuário, o número de contribuições que podem ser
coletadas de um indivíduo é limitado. Quando você soma todos os valores agregáveis em todas as chaves de agregação, a soma precisa ser menor que o orçamento de contribuição. No modelo atual, definimos um limite para as contribuições de uma origem de relatórios específica nas últimas 24 horas, como uma janela contínua. Esse é o orçamento de contribuição L1 mencionado no feedback. Sugerimos que os desenvolvedores dimensionem os valores com que contribuem com base no volume esperado (ou seja, não apenas usando um valor de 1). Portanto, pode fazer sentido usar um valor menor para os eventos mais comuns para evitar o esgotamento do orçamento. No momento, estamos buscando feedback sobre o orçamento de contribuição da API Private agregação sobre o limite numérico e o escopo. Estamos pensando em mover o escopo de por origem para por site e mover o limite existente para uma janela de 10 minutos com um limite diário maior. |
Limitar o rastreamento verso
Redução do user agent/dicas de cliente do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adoção de UA-R | Dos 10.000 principais sites do Reino Unido, apenas 1% dos que usam publicidade programática envia dicas de clientes HTTP. As DSPs que não migraram podem ter um impacto nos recursos antifraude. | Depois de executar uma análise no mesmo conjunto de dados, descobrimos que, se você contabilizar o uso do UA-CH pela tag HTML <meta> e pelas APIs JavaScript, o número de sites que usam o UA-CH será significativamente maior do que o valor de 1% fornecido no feedback. Com base nisso e em outros fatos, incluindo feedback do ecossistema, nos sentimos confiantes para avançar com o lançamento gradual da Fase 6 da redução do UA, de acordo com o cronograma publicado, sem deixar de manter a CMA informada. Observamos que os sites tiveram quase dois anos de lead para se preparar para a transição, e um teste de descontinuação ainda está disponível para sites que acreditam que eles não estão prontos. |
| Dicas sobre outros formatos | Solicite que o UA-CH ofereça outros formatos, como TV e RV | Aceitamos esta proposta e estamos trabalhando para incorporá-la ao design. Gostaríamos de receber mais feedback. |
| Testes automatizados | Solicitação para resolver o bug do UA-CH no headless Chrome antes do envio da Fase 6 do RAU | O bug em questão foi corrigido. |
| Suporte do UA-CH no iOS | Um site que depende de informações granulares do UA para casos de uso de anúncios observa que o Chrome no iOS não é compatível. | Para navegadores iOS que não são do Safari (incluindo o Chrome no iOS), o projeto WebKit precisará adicionar suporte para UA-CH antes de eles serem ativados, já que controlam a pilha de rede. |
Proteção de IP (antigo Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Casos de uso de geolocalização (também relatados no 4o trimestre) | 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 localização. | Nossa resposta não muda em relação ao 4o trimestre de 2022: "Estamos trabalhando com as partes interessadas para garantir que o Chrome continue oferecendo suporte a casos de uso legítimos de endereços IP. Estamos procurando feedback do ecossistema sobre a granularidade da geolocalização de IP. |
| Conformidade com as normas | Se uma região tiver menos de 1 milhão de população, o limite atual de 1 milhão para proteção de IP vai impedir que os sites usem endereços IP para conformidade regulatória. | 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 feedback do ecossistema sobre a conformidade regulatória da proteção de IP. |
| Mitigação de abusos | As partes podem burlar a Proteção de IP compartilhando endereços IP sem máscara com outras pessoas. | Temos consciência do risco de que a proposta atual de proteção de IP
não impeça tecnicamente que as partes compartilhem endereços IP
sem máscara com outras. Estamos trabalhando em mitigações que evitarão
esse risco de abuso. Conforme iteramos a proposta, incentivamos mais feedback e discussão. Especificamente, gostaríamos de saber sobre casos de uso em que as partes acreditam que precisam compartilhar endereços IP sem máscara com outras partes. |
| Bloqueio de rede | As partes podem burlar o bloqueio de rede usando proxies de proteção de IP. | A entidade que executa o bloqueio precisa desativar a proteção de IP nesse cenário. Respondemos ao problema e agradecemos seu feedback. |
| Listas de bloqueio de endereços IP afetadas pela proposta de proteção de IP | Muitas empresas de adtech usam uma lista de bloqueio básica de endereços IP, como a lista de IPs de data centers do TAG, para impedir lances em inventários de anúncios com alta probabilidade de fraude (ou pelo menos não gerar receita). Caso uma adtech também seja um rastreador e esteja sujeita à proposta de Proteção de IP, essa empresa pode perder a capacidade de realizar uma verificação básica em anúncios antes de comprar inventário de publicidade. | Recomendamos mais feedback e discussões sobre a proposta de proteção de IP sobre possíveis problemas e soluções. Uma opção é aplicar essas listas semelhantes à Proteção de IP, para que não façamos proxy de clientes originados de endereços IP sinalizados anteriormente. |
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 4o trimestre) | Solicitação para expandir o número de domínios associados | Nossa resposta não mudou em relação ao 4o trimestre de 2022: "Esclarecemos nas ligações do WICG que o Chrome está comprometido em oferecer uma solução utilizável que considera também os interesses de privacidade dos usuários. Nesse sentido, agradecemos o feedback da comunidade sobre casos de uso específicos que podem ser afetados pelo limite de domínio. Assim, a equipe pode considerar maneiras de resolver esses casos de uso sem deixar de proteger a privacidade do usuário." |
| Envio de QPS alternativo | Proposta de maneira alternativa de enviar listas globais para QPS | No momento, estamos nos preparando para enviar conjuntos primários (QPS) no Chrome e configuramos um repositório centralizado do GitHub para aceitar envios de conjuntos. Como esperamos que o QPS preencha uma lacuna com as soluções da plataforma da Web em preparação para a descontinuação dos cookies de terceiros, esperamos aprender com elas como o QPS é aproveitado pelos autores de sites. À medida que a lista de conjuntos aumenta com o tempo e o ecossistema se adapta a um mundo pós-cookies de terceiros, também podemos amadurecer o processo ao ponto em que podemos considerar esquemas alternativos descentralizados como o proposto. Com o processo atual, esperamos instituir tempos de vida útil definidos, o que nos permitirá desenvolver o processo de entrada ao longo do tempo. Podemos revisitar essa ideia assim que o processo de envio estiver concretizado. |
| Moderação do repositório | Promove a moderação da comunidade do repositório de envios de QPS para evitar abusos. Usuários de má-fé podem sobrecarregar facilmente o processo, empregando origens de burner para propor conjuntos, e um volume esmagador de solicitações pode afetar as operações de propostas de conjuntos genuínos. | Tentamos tornar as verificações o mais objetivas possível usando verificações de validação técnica. Acreditamos que essa é a abordagem mais escalonável no processo de inscrição. Para cumprir esse objetivo, também vamos garantir que o processo seja resiliente a envios de spam / queimadores. |
| Subconjuntos associados | O FPS vai oferecer suporte aos casos de uso de fluxo de fornecedor/SaaS de terceiros por meio de subconjuntos associados? | Os fluxos de SaaS / fornecedor de terceiros não são um caso de uso atualmente considerado no escopo dos conjuntos primários. Gostaríamos de receber mais feedback sobre o uso de cookies entre sites nesses casos de uso. |
| Integração de QPS + CHIPS | Solicitação de integração de QPS + CHIPS para oferecer suporte a casos de uso, como testes A/B | Estamos discutindo esse caso de uso e também pensando em discutir isso em uma chamada WICG. Agradecemos mais informações aqui. |
| GDPR | Proposta de um novo subconjunto de QPS para ser modelado de acordo com os conceitos do GDPR | Discutimos essa proposta internamente e comparamos com outros feedbacks recebidos, além das nossas metas de privacidade. Fornecemos uma resposta explicando por que não vamos analisar essa proposta no momento. |
| Memória | Mudança esperada no tamanho da memória do navegador quando a lista de QPS é incorporada | Já houve precedentes de navegadores para armazenar esses tipos de listas com impacto mínimo na memória, como a lista de proteção de rastreamento de desconexão. Embora a lista de conjuntos primários seja copiada localmente para cada cliente do Chrome, continuaremos monitorando o tamanho do arquivo e temos confiança de que podemos otimizar o consumo da memória. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limitações dos frames Fenced Frames | Clareza sobre as limitações impostas pelos Fenced Frames | Em março, atualizamos nosso artigo explicativo sobre Fenced Frames, que fornece informações sobre os recursos dele, e aceitamos qualquer outro feedback. |
| Expandir informações de acesso | Solicitação para expandir o acesso a informações sobre frames vizinhos | Queremos entender melhor por que isso é um requisito do ecossistema e aceitamos qualquer outro feedback. |
| Frames e iframes isolados | Perguntas sobre a paridade de recursos entre Fenced Frames e iframes | Todos os relatórios e APIs do Sandbox de privacidade vão estar disponíveis para iframes e FencedFrames da mesma maneira. |
| Redimensionar frames de cercas | Restringir mudanças no tamanho do frame afeta alguns casos de uso. | Temos interesse em saber mais sobre os tipos de casos de uso afetados pela restrição. Por isso, queremos receber mais feedback. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Worklets de terceiros | Terceiros podem gravar no armazenamento compartilhado, particionado por origem? Ou chamar outros worklets para medição de terceiros? | A origem do contexto de navegação de onde o código está sendo executado determina de qual armazenamento compartilhado os dados são gravados. Quando um código de terceiros é adicionado a uma página, ele pode ser incorporado como um iframe com o próprio contexto de navegação, o que permite que o código de terceiros grave na própria origem. O código de terceiros também pode ser incorporado como um script em vez de um iframe, o que não altera o contexto de navegação, e o terceiro pode gravar no armazenamento compartilhado do incorporador. Somente o proprietário do armazenamento compartilhado pode ler a partir desse armazenamento compartilhado. |
| Eliminação de duplicação | A eliminação de duplicação não seria possível para interações fora do ecossistema Chrome. | O armazenamento compartilhado fornece saídas de alcance único baseadas no navegador Chrome no Chrome. Estamos interessados em trabalhar com adtechs para entender como esses resultados podem ser usados como parte dos modelos de alcance mais amplos delas. Entendemos que os resultados em si podem ser responsáveis apenas por uma parte das interações e estamos interessados em trabalhar com adtechs para explorar outras metodologias de modelagem que podem ser colocadas em camadas. |
| Janela de lookback de conversão | Solicite uma janela de lookback da taxa de conversão para conferir as mudanças na conversão ao longo do tempo. | Isso pode ser implementado pelo processamento dos vários caminhos de conversão no lado do cliente usando o armazenamento compartilhado, que oferece flexibilidade adicional para análises avançadas em relação ao armazenamento seguro de navegador não particionado. |
| Prazo de validade do item | Solicitação para estender o período de validade para 90 dias | A política de retenção de dados foi atualizada em novembro de 2022 e declara que cada chave é apagada após trinta dias da última gravação. Agradecemos seu feedback para entender se a nova política funcionará para o ecossistema. |
| Rotação de criativos | Os casos de uso da rotação de criativos não refletem as ações reais pós-leilão. | Estamos interessados em ouvir mais empresas de tecnologia de publicidade de compra sobre se a documentação da rotação criativa é precisa ou não. |
ÍCONES
Nenhum feedback foi recebido neste trimestre.
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Endpoint de declaração de identidade | Permitir explicitamente solicitações arbitrárias para o endpoint de declaração de identidade. | Estamos colaborando com o Mozilla nessa solicitação de envio para limitar a capacidade dos sites de fazer solicitações credenciadas de origem cruzada silenciosamente sem causar incômodo ao usuário. Além disso, vamos continuar analisando e respondendo a outros feedbacks. |
| Preencher automaticamente a identidade | O FedCM pode ser usado para pré-preencher formulários de login com um provedor de identidade da lista da FedCM? | A preocupação com esse caso de uso é que isso pode resultar no vazamento de informações quando um site que não interagiu com o usuário pode consultar o último IdP usado por ele. Estamos discutindo esse problema com mais detalhes e Agradecemos seu feedback. |
| Seleção de conta contextual | Proposta para adicionar indicadores de contexto na interface de seleção de conta | Estamos analisando essa proposta e aceitamos outras discussões. |
Combater spam e fraudes
API Private State Token (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Pesquisa de coleta de recursos | No início do primeiro trimestre, terminamos de coletar os resultados da pesquisa sobre quais recursos são necessários para vários casos de uso antifraude e os compartilhamos publicamente (minutos, resultados). | Planejamos incorporar esse feedback à medida que desenvolvemos novas propostas e protótipos para APIs personalizadas que preservam a privacidade para recursos antifraude. Esperamos priorizar o desenvolvimento quando houver necessidade suficiente e quando houver tecnologia atual que possa ser aproveitada para introduzir o recurso na Web, preservando a privacidade do usuário. Por exemplo, a integridade do dispositivo e da inicialização foi altamente classificada e muitas plataformas têm APIs que compartilham com segurança uma avaliação da integridade do dispositivo. Por isso, ela é uma boa candidata para buscar análises nos grupos da comunidade. |
| Intenção de enviar feedback da PST | Como parte da intenção de envio, recebemos uma preocupação ao prosseguir já que estamos usando uma versão mais antiga do cartão de privacidade. Também recebemos feedback de que a especificação não estava clara em determinadas seções e precisa ser melhorada para facilitar a compatibilidade do navegador. | Planejamos implementar muitas das alterações de especificações sugeridas antes de enviar para o GA, bem como algumas alterações na API. O feedback veio direto
no final do primeiro trimestre. Por isso, estamos acompanhando os problemas do
github com detalhes específicos e uma atualização do nosso plano de lançamento, em
andamento, a partir da publicação deste relatório de feedback. Para as mudanças maiores na API, podemos analisá-las, mas achamos que a melhor maneira de avançar é prosseguir com o lançamento para disponibilidade geral e receber feedback prático de mais desenvolvedores. Esperamos continuar essa discussão e buscar a padronização do navegador. Se e quando um novo padrão surgir, vamos considerar a adoção e desenvolver um plano para fazer a transição com cuidado. |