Relatório trimestral do 1º trimestre de 2023 que resume o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.
Como parte dos compromissos com o 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 em relação às APIs Topics, FLEDGE e Attribution Reporting.
O feedback recebido após o fim do período de geração de relatórios atual pode ainda não ter uma resposta considerada do Chrome.
Glossário de acrônimos
- CHIPS
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos próprios
- IAB
- Interactive Advertising Bureau
- IDP
- Provedor de identidade
- IETF
- Internet Engineering Task Force
- IP
- Endereço de Protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste da Origin
- PatCG
- Grupo da comunidade de tecnologias de publicidade privada
- RP
- Entidade confiável
- SSP
- Plataforma de fornecimento
- TEE
- Ambiente de execução confiável
- UA
- String do user agent
- UA-CH
- Dicas de cliente HTTP do user agent
- W3C
- World Wide Web Consortium
- WIPB
- IP Blindness proposital
Feedback geral, sem API/tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Testes e testes de avaliação | Relevância do teste para informar a avaliação do CMA se as APIs do Sandbox de privacidade não forem concluídas até o início do teste. | O desenvolvimento das APIs do Sandbox de privacidade está avançando.
Elas já estão disponíveis no teste de origem para testes e serão
disponibilizadas para 100% do tráfego neste verão. Além disso, esclarecemos os cronogramas de alguns recursos (como relatórios no nível do evento do FLEDGE, renderização do FLEDGE com iframes) que não serão afetados antes de 2026. Encorajamos o ecossistema a testar as APIs e enviar feedback à CMA com base no que os testadores esperam usar quando os cookies de terceiros forem descontinuados. Isso pode contribuir para a avaliação do impacto provável da descontinuação de cookies de terceiros. |
| Controles de usuário | Orientações claras para o ecossistema sobre as implicações dos controles do usuário nas APIs do Sandbox de privacidade | Não podemos dar conselhos jurídicos sobre quais controles do usuário o ecossistema pode usar. Ao mesmo tempo, o Chrome está testando a exibição de controles do usuário atualizados do Sandbox de privacidade ("Privacidade de anúncios aprimorada") 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 layouts e linguagem mais claros e úteis. Depois que o Chrome avaliar esses aprimoramentos e decidir se eles serão expandidos 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 caso o navegador seja comprometido. | Nosso explicativo
FLEDGE deixa claro que os dados de uma adtech só são compartilhados
com essa mesma adtech (com os worklets ou servidores
de confiança) ou quando compartilhados explicitamente por essa adtech (como quando um comprador
mostra ao vendedor o URL do anúncio que quer exibir). A única exceção
é que a verificação de k-anonimato precisa ser feita por um servidor global
centralizado, que é uma área para a qual continuamos dedicando recursos
significativos. Consulte o texto explicativo sobre
anonimato k para conferir uma visão detalhada de como pensamos sobre
privacidade. Além disso, estamos abertos a fornecer mais detalhes sobre como as proteções de adtech empregadas no design do servidor de k-anonimato funcionam. |
| Outro fórum para discussão | Solicitação de um fórum adicional ao W3C para que participantes do ecossistema não técnicos compartilhem 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 Improving Web Advertising Business Group (link em inglês) é um fórum de discussão por meio de ligações semanais e um repo do GitHub. A página Feedback do Sandbox de privacidade explica outros mecanismos para enviar feedback e participar de discussões. O Chrome também continua realizando eventos, como horários de atendimento públicos, para facilitar as perguntas e o compartilhamento de conteúdo. Além disso, o Chrome sediou ou participou de mais de uma dúzia de eventos do setor neste trimestre. |
| Esclarecimento sobre o cronograma | Esclarecimento sobre a data exata de disponibilidade geral no terceiro trimestre de 2023 | De acordo com o cronograma publicado em PrivacySandbox.com, a disponibilidade geral deve começar a ser lançada com a versão 115 do Chrome. |
| reCAPTCHA | Impacto das APIs do Sandbox para o caso de uso de detecção de spam do reCAPTCHA | Recebemos feedback do reCAPTCHA periodicamente para garantir que as propostas do Sandbox de privacidade não afetem significativamente a segurança da Web ou a fraude. Eles estão desenvolvendo o próprio plano para se preparar e se ajustar à descontinuação de cookies de terceiros. Portanto, essa pergunta é melhor respondida por eles. |
| Extensões do Chrome | As tecnologias do Sandbox de privacidade, como as medidas Anti Covert Tracking (ACT), serão aplicadas às extensões do Chrome? | Não fizemos nenhum anúncio sobre a aplicação da ACT nas extensões do Chrome. No entanto, se uma tecnologia coletar informações sobre um usuário de forma oculta, isso não estará alinhado aos nossos princípios de privacidade. |
Mostrar conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Revisão de design da TAG | A TAG lançou a análise de design inicial dos tópicos. | Continuamos comprometidos com os Tópicos e compartilhamos uma atualização sobre nosso compromisso na página de atualizações mais recentes e neste artigo. Respondemos ponto a ponto à análise da TAG e compartilhamos nossa visão de nível mais alto aqui. A API Topics vai continuar fazendo parte da coleção 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 futuros esforços para trabalhar com padrões entre navegadores nesse espaço. Esperamos continuar interagindo com o ecossistema para facilitar uma possível transição em que a API Topics poderia ser um padrão acordado com compatibilidade entre navegadores. |
| Abordagem dos tópicos | Suporte à abordagem aberta do Chrome para o desenvolvimento da API Topics | Agradecemos o sentimento e esperamos continuar trabalhando com o grupo do setor para desenvolver uma API Topics que agregue valor ao ecossistema como um todo. |
| (Também informado no 3º trimestre de 2022) A taxonomia de tópicos não é granular o suficiente |
A taxonomia de temas amplos não inclui temas mais específicos, incluindo aqueles específicos de região. | Atualização do primeiro trimestre: As melhorias na taxonomia são um esforço contínuo, e no segundo trimestre vamos anunciar uma taxonomia atualizada para a API Topics. Para criar essa nova taxonomia, trabalhamos em conjunto com empresas de todo o ecossistema. Estamos buscando ativamente feedback sobre a taxonomia mais útil para o ecossistema. Ao avaliar se é melhor expandir o número de tópicos ou incluir tópicos mais específicos, há algumas considerações, incluindo 1) possíveis implicações de privacidade (mais tópicos podem aumentar o risco de impressão digital) e 2) a capacidade de recuperar tópicos observados anteriormente (por exemplo, com mais tópicos, pode haver menos chances de uma adtech ter visto o tópico escolhido no passado). |
| (Também informado no 4º trimestre de 2022) Impacto nos indicadores próprios |
O indicador de tópicos pode ser muito valioso e, como resultado, desvaloriza outros indicadores próprios com base em interesses. | Acreditamos que a publicidade com base em interesses é um caso de uso importante para a Web, e a API Topics foi criada para oferecer suporte a esse caso. Sabemos que alguns grandes editores estão preocupados com o fato de que os Tópicos vão afetar negativamente as estratégias de dados próprios. Estamos ansiosos pelos testes do ecossistema, que vão fornecer insights sobre o impacto do Topics nos editores. |
| Casos de uso de temas não relacionados a anúncios | Uso de tópicos para fins diferentes da veiculação de publicidade baseada em interesses | A API Topics foi criada para atender ao caso de uso de publicidade com base em interesses, que acreditamos ser um caso de uso essencial para a Web aberta e sem custo financeiro. No momento, estamos buscando feedback sobre outros casos de uso e avaliando. |
| Status de ativação padrão | Impactos da legislação regional no consentimento padrão para o Topics | Não é nossa posição comentar sobre opiniões jurídicas. |
| (Também informado no 3º trimestre de 2022) Sites com categorias incorretas |
Segmentação de anúncios quando os tópicos são categorizados incorretamente para um determinado site | Atualização do 1º trimestre: No 2º trimestre, vamos anunciar um classificador atualizado para a API Topics e esperamos interagir com o ecossistema. Em resposta ao feedback atual, os sites são classificados por uma combinação de uma lista de substituição feita por humanos, que contém os sites mais populares, e um modelo de ML no dispositivo. O Chrome continua avaliando opções para que os sites contribuam com a classificação de temas. Todas as melhorias de utilidade precisam ser ponderadas em relação aos riscos de privacidade e abuso. Por exemplo, alguns dos riscos incluem: sites que usam autoclassificação como um método para codificar significados diferentes (e potencialmente sensíveis) em tópicos; sites que distorcem os tópicos para ganho financeiro; sites que atacam tópicos para diminuir a utilidade deles para outras pessoas (por exemplo, spam nos tópicos do usuário com ruído sem sentido). O público pode inspecionar esses componentes, com ferramentas disponíveis em chrome://topics-internals ou nesta colab. Com os testes, esperamos que a classificação melhore com o tempo. Agradecemos o feedback com exemplos de sites que podem estar na categoria errada. |
| Classificador de temas | Solicitação para retornar informações adicionais mostrando os motivos quando "Nenhum tópico" é retornado ao autor da chamada para fins de depuração | Entendemos e agradecemos que as ferramentas de depuração são úteis para desenvolvedores, já que eles trabalham para integrar a API Topics aos sistemas. No entanto, ao expor informações adicionais (como o motivo pelo qual nenhum Tópico foi retornado), podemos compartilhar acidentalmente informações que permitem que as partes descubram detalhes adicionais (por exemplo, se um usuário está no modo de navegação anônima, desativou a API etc.) além do pretendido, prejudicando a privacidade do usuário. Não planejamos oferecer outras ferramentas de depuração no momento, mas estamos abertos a feedback sobre quais ferramentas seriam valiosas. |
| Recuperação de informações particulares (PIR) | Solicitação para que a API Topics adote a Private Information Retrieval | Já investigamos o uso do PIR e compartilhamos as compensações aqui. |
| Stream de lances | Os tópicos serão representados de forma distinta 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 de públicos-alvo definidos pelo vendedor do IAB Tech Lab. Esperamos que os dois sejam representados de forma distinta no fluxo de lances. Saiba como os tópicos serão representados nas solicitações de lance do OpenRTB. |
API Protected Audience (antes conhecida como FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Disponibilidade do recurso FLEDGE | Esclarecimento sobre os cronogramas de teste e implementação de recursos do FLEDGE, como a aplicação de limite de quadro, k-anonimato e assim por diante. | Temos o status compartilhado de vários recursos do FLEDGE com escopo e quando eles vão ser compatíveis. Agradecemos seu feedback sobre o anúncio enquanto continuamos desenvolvendo o FLEDGE. |
| Restrições de renderização do produto | Pedido para afrouxar as restrições de anúncios compostos de várias peças para frames restritos do FLEDGE | Como anunciamos em fevereiro, o uso de frames cercados vai continuar opcional até pelo menos 2026, e o comportamento de iframes será compatível com urn-iframes. Faremos novas discussões sobre esse assunto. |
| Problemas de escalonabilidade | Desempenho do FLEDGE conforme o uso aumenta | Estamos acompanhando o feedback e entendendo melhor o contexto para propor soluções práticas. A primeira etapa foi separar o feedback em duas categorias:
|
| (Também informado no terceiro trimestre de 2022) Visibilidade da lógica de lances |
Preocupação de que a lógica de lances do DSP será exposta no JavaScript | Atualização do primeiro trimestre: Compartilhamos uma proposta que limitaria a capacidade de invasores de solicitar dados do servidor de forma exploratória (navegação forçada). Convidamos os participantes do ecossistema a compartilhar feedback ou apoio à proposta. |
| Dificuldades de teste | DSPs menores podem testar corretamente o FLEDGE e reduzir o risco de que os anunciantes só estejam interessados em testar com DSPs maiores | Estamos comprometidos em trabalhar com DSPs menores e incentivamos testes ampliados entre DSPs e anunciantes de todos os tamanhos à medida que o FLEDGE passa a estar disponível para todos. Gostaríamos de saber como podemos ajudar a testar o FLEDGE com outras pessoas no ecossistema e agradecemos as ideias e os esforços do setor para motivar os anunciantes a fazer testes com DSPs menores. |
| Remarketing dinâmico | O remarketing dinâmico ainda será possível com o FLEDGE após a descontinuação dos cookies de terceiros? | Estamos considerando uma resposta a essa pergunta e convidamos os participantes do ecossistema a compartilhar outros 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 com os participantes do ecossistema sobre fraude e abuso e receber mais feedback nessa área. |
| Preferências do usuário | Processo para salvar as preferências do usuário e usar na seleção de anúncios | Para anúncios específicos, a adtech relevante é a parte mais bem posicionada para oferecer controles sobre quais criativos são mostrados ou como eles são selecionados. |
| Proposta de testes quantitativos | Para que os testes quantitativos sejam justos, eles precisam ser realizados no tráfego sem cookies de terceiros ou com SSPs que usam apenas FLEDGE? Como evitar a mistura de indicadores de cookies de terceiros? | Agradecemos o feedback e estamos trabalhando com a CMA para projetar experimentos que vão fornecer 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 outros feedbacks sobre a proposta de testes quantitativos da CMA sejam compartilhados diretamente com a CMA. |
| Documentação mais clara | Pedido de documentação mais clara sobre a configuração do leilão | Esperamos compartilhar uma postagem no blog com mais informações sobre os relatórios de leilão FLEDGE nas próximas semanas. |
| Paralelização | O serviço de lances e leilões (B&A) vai oferecer suporte à paralelização? | Uma adtech que usa servidores de lances / leilões pode iniciar vários servidores que podem exibir resultados em paralelo. |
| Mitigação de abuso | O servidor de k-anonimato FLEDGE usando tokens de estado particular será suficiente para garantir a privacidade do usuário? | A motivação para o k-anonimato é menos focada no microdirecionamento e mais em ter uma reserva durante a fase provisória em que o FLEDGE permite relatórios no nível do evento. Compartilhamos mais ideias e agradecemos outro feedback. |
| Conflito de módulo ES | Solicitação para remover generateBid como uma função global, porque ela entra em conflito com
o módulo ES |
Estamos discutindo essa solicitação e agradecemos o feedback. |
| Leilão de componentes | Pedido para que os editores tenham mais controle sobre os designs de leilão | Lances e plano de leilão para oferecer suporte ao leilão de componentes, assim como o Chrome no dispositivo. |
| Cronogramas de B&A | Mais clareza sobre a linha do tempo para as adtechs interessadas em testar servidores de B&A | Atualizamos a explicação sobre o B&A e a seção de cronograma para incluir definições claras de cronogramas para diferentes fases de testes do Chrome-B&A, após o alinhamento com o CMA. |
| Esquema de controle de tempo limite | Melhoria do esquema de controle de tempo limite disponível atualmente para FLEDGE | Essa é uma proposta interessante. Vamos adicionar isso à fila de propostas para estudo e informar sobre nossos desenvolvimentos. |
| Fluxos de lances do criativo | Capacidade de analisar e filtrar um lance vencedor com base no criativo | Essa é uma proposta interessante. Vamos adicionar isso à fila de propostas para estudo e informar sobre nossos desenvolvimentos. |
reportWin |
Proposta para fornecer mais informações sobre o lance de maior pontuação
de um proprietário de grupo de interesse diferente do vencedor na
função reportWin |
Essa é uma proposta interessante. Vamos considerar adicionar outros indicadores nos relatórios agregados e agradecemos mais feedback aqui. |
| Tipos de evento | Padronizar tipos de eventos em APIs de medição quando integrados ao FLEDGE | Essa é uma proposta interessante. Vamos adicionar isso à fila de propostas para estudo e informar sobre nossos desenvolvimentos. Isso vai exigir coordenação com nossos esforços mais amplos nessa área, já que afetaria outras APIs do Sandbox de privacidade além do FLEDGE. Envie seu feedback adicional 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 compartilhamos na postagem do blog de fevereiro, os relatórios de vitórias de leilão no nível do evento vão ser aceitos até "pelo menos 2026". No momento, não temos mais detalhes para compartilhar, mas agradecemos mais feedback sobre por que é importante manter determinados dados disponíveis após a descontinuação dos cookies de terceiros. |
| Limite de grupos de interesse | Qual é o limite do número de grupos de interesse que uma origem pode adicionar a 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. Eles são usados como proteções e não devem ser atingidos durante a operação normal. |
| Indicadores no nível do evento | Suporte a uma proposta para ter indicadores no nível do evento para generateBid
e reportWin, que podem ser usados no treinamento de aprendizado de máquina |
Compartilhamos nossa decisão sobre indicadores projetados por navegadores e definidos por adtechs aqui. Agradecemos seu feedback. |
| Script de lances | Inclua o ID do usuário no URL do script de lances. | Isso não será possível, porque a FLEDGE tem o requisito adicional 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 de k-anonimato | O k-anonimato é aplicado no par (componentAd, size)? | Sim, será. Consulte turtledove/issues/312. |
| Requisitos dos serviços de lances e leilões | Como os serviços de B&A oferecem suporte aos participantes que se integram ao FLEDGE no dispositivo e outros com serviços de B&A? | Ainda estamos finalizando o design e agradecemos seu feedback. |
| Atribuição pós-visualização | A atribuição pós-visualização vai ser aceita? | No momento, não temos nenhum tipo de definição padrão de visibilidade e dependemos do próprio criativo para marcar um evento de visualização. Consulte turtledove/issues/452. |
| Segmentação por público-alvo parecido | O Sandbox de privacidade pode oferecer suporte à "segmentação por semelhança"? | Estamos discutindo o caso de uso aqui e agradecemos mais informações. |
| API de monitoramento em tempo real | Proposta de uma abordagem de monitoramento do FLEDGE em tempo real | Estamos discutindo a proposta e agradecemos outras informações aqui. |
| Relatórios do FLEDGE | reportWin e reportResult precisam ser feitos em ordem aleatória para evitar
relatórios excessivos ou insuficientes. |
O reportResult() precisa ser executado primeiro pelo vendedor antes do
reportWin() pelo comprador para que os indicadores do vendedor de reportResult()
possam ser incluídos em reportWin(). Consulte o
texto explicativo para mais informações. |
| Servidores de chave-valor (K/V) personalizados | Os servidores K/V personalizados vão ter suporte no futuro? | Discutimos a pergunta aqui e agradecemos qualquer outra contribuição. |
| Leilão de nível superior | É necessário ser o servidor de anúncios para executar as mecânicas de leilão de nível superior? | A API FLEDGE não especifica qual parte precisa fazer a chamada. Não há requisitos nesse sentido no design do FLEDGE. Qualquer pessoa pode realizar o leilão do FLEDGE (incluindo leilões de vários vendedores). Conforme mencionado no relatório do 4º trimestre de 2022, o FLEDGE permite que cada editor escolha a estrutura do leilão, incluindo a escolha de vendedores de nível superior e componentes. |
| Escopo da API | O FLEDGE pretende trabalhar com dados próprios? | Vamos publicar conteúdo no segundo trimestre de 2023 esclarecendo que os dados próprios podem ser usados com o FLEDGE para 1) usar como lógica para determinar a participação no grupo de interesse e 2) alimentar como indicadores de lances do usuário para uso na geração de lógica de lances subsequente. |
| Grupos de interesse entre domínios | Possibilidade de criar grupos de interesse entre domínios | Qualquer informação disponível no momento de adicionar 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 informar a criação de grupos de interesse será limitada. |
| Lógica de lances do lado do cliente | Transferir a lógica de lances do lado do servidor para o lado do cliente | Queremos saber mais sobre quais áreas são desafiadoras ou estão faltando no processo de portabilidade e agradecemos qualquer outro 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 eles podem armazenar objetos em JSON ou buffer de protocolo e serializar em string. |
| Lista de bloqueio de anunciantes | Quais indicadores seriam adequados para fornecer a um comprador uma lista de bloqueio de anunciantes? | O lugar apropriado está em auctionSignals ou em
perBuyerSignals. |
| Unidade de lances | Suporte a diferentes unidades de lances, como CPI e CPM | Gostaríamos de saber por que isso é necessário, considerando o design atual, e adoraríamos receber mais feedback. |
| Lógica do leilão | O navegador ou o servidor de anúncios decide o vencedor de um leilão? | Toda a seleção de vencedores é executada dentro do sandbox, e todas as decisões são tomadas pelo código do vendedor. O navegador simplesmente fornece um ambiente fechado e particular em que o código do comprador e do vendedor é executado. |
| Permissions-Policy | A política de permissões do FLEDGE atual vai continuar sendo aplicada após o término do teste de origem? | No teste do Origin, 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 vão precisar para 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 interesses com o mesmo trustedBiddingSignalsUrl. O limite de tamanho de 2 MB
é uma restrição. |
A restrição existe para que os autores de chamadas no dispositivo evitem sobrecarregar os recursos no dispositivo. Os autores de chamadas de um servidor de B&A terão uma restrição mais flexível. |
| Indicadores de relatórios | Adicione um indicador adicional, "script-errors", 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 problemas de privacidade com essa proposta e convidamos os participantes do ecossistema a compartilhar mais insights sobre por que isso é necessário. |
| Tamanho da janela do k-Anon | Aumento do tamanho da janela K-Anon do limite atual de sete dias. | Estamos analisando essa questão e aguardando mais informações do ecossistema. |
| Performance do dispositivo | Como a FLEDGE lida com o desempenho do dispositivo se o usuário estiver em um grande número de grupos de interesse? | O FLEDGE oferece várias opções de tempo limite, priorização e limite em SSPs e DSPs que dão às adtechs um controle detalhado em situações em que a performance do dispositivo pode ser um motivo para limitar a participação no leilão quando o dispositivo está em um grande número de grupos de interesse. |
| Testes de serviços de B&A | Solicitar que os participantes do ecossistema usem o próprio servidor durante a fase de teste para ter mais registros disponíveis para depuração | A B&A permite que os usuários iniciem e dimensionem os servidores de 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 da B&A TEE e estamos desenvolvendo recursos para oferecer suporte a ela. Estamos procurando mais feedback sobre o assunto. |
| Requisitos regulatórios | O FLEDGE vai trabalhar com provedores de nuvem em diferentes países para apoiar a conformidade com os requisitos regulatórios locais? | Estamos sempre abertos a sugestões para outros provedores de nuvem, mas atualmente estamos planejando oferecer suporte ao GCP e à AWS quando a descontinuação de cookies de terceiros for aplicada. Consulte este explicador para mais informações. |
Como medir anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Análise de dados de impacto do ruído | Orientações sobre como realizar a análise de dados sobre o impacto do ruído | Compartilhamos mais
documentação sobre ruído e sobre decisões de design e ruído que podem ser
usadas para mudar o impacto do ruído nos dados de adtech. Também há um guia mais detalhado. |
| Relatórios nulos | Mais clareza na implementação de relatórios nulos | No momento, estamos trabalhando em uma proposta para implementar relatórios nulos e vamos compartilhar mais detalhes em breve. A implementação de relatórios nulos nos permitirá reduzir atrasos nos relatórios sem comprometer a privacidade. |
| Nível de barulho | Como ajustar o nível de ruído com base no comprimento da janela de atribuição | Agradecemos a proposta e estamos considerando adicioná-la à especificação. Envie seu feedback. |
| Tamanho dos dados do acionador | Por que o tamanho dos dados do acionador é limitado a três bits? | O tamanho é limitado a 3 bits e 8 valores distintos para garantir que a quantidade de informações de contexto/entre sites sobre um usuário seja limitada. Convidamos os participantes do ecossistema a enviar feedback sobre se a parametrização atual para relatórios de eventos faz sentido. |
| Acionadores de relatórios no nível do evento | Permitir a priorização em uma chave de eliminação de duplicação | Estamos investigando soluções para esse problema e agradecemos mais informações. |
| Compatibilidade com depuração | Mais clareza sobre a depuração após a descontinuação dos cookies de terceiros | Gostaríamos de oferecer suporte ao debug após a descontinuação dos cookies de terceiros e estamos pensando em opções. Estamos em busca de mais feedback e ideias. |
| Alternativas de conversão de clique | Solicitar mais orientações sobre alternativas para conversões de clique | Recomendamos que o ecossistema use a API Attribution Reporting como um sistema de medição particular durável para casos de uso de medição de conversões aplicáveis. Existem outras alternativas, 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 | Mais clareza sobre o nível de suporte da Attribution Reporting a casos de uso de faturamento baseado em conversões | Estamos trabalhando para publicar publicamente e esclarecer o escopo da API Attribution Reporting para faturamento. A API Attribution Reporting não
tinha um escopo inicial que oferece suporte direto ao faturamento do CPA. Ela
oferece suporte ao faturamento de CPC e CPM, que é a estrutura de faturamento usada pela
maioria das adtechs. Isso pode ser compatível no futuro se houver mais feedback do ecossistema. |
| Suporte a casos de uso | Documentação de casos de uso da API Measurement | Estamos trabalhando para esclarecer a documentação de todas as plataformas de relatórios do Sandbox de privacidade. |
| Qualidade do clique | Pedido para adicionar um indicador para distinguir cliques intencionais e não intencionais em um anúncio | Estamos discutindo o pedido e agradecemos mais informações. |
| Solução de métricas | Suporte a soluções de medição em vários DSPs | A API Attribution Reporting pode ser usada pelos provedores de medição para
eliminar duplicações entre vários DSPs. Além disso, propomos
o suporte a uma lista de URLs em attributionsrc,
o que vai facilitar a compatibilidade das DSPs com as solicitações da API Attribution Reporting do provedor de medição. Aceitamos
qualquer outro feedback sobre a proposta acima. |
| Relatórios no nível do evento | Solicitar que o número de dias antes do envio do relatório esteja disponível diretamente | Essa solicitação já pode ser calculada pelas adtechs usando as informações disponíveis. Não recebemos nenhum outro feedback do ecossistema sobre essa solicitação, mas estamos abertos a feedback. |
source_registration_time |
Adicione source_registration_time nos relatórios de atribuição no nível do evento. |
Estamos considerando essa solicitação e agradecemos o feedback sobre se os participantes do ecossistema acham esse recurso útil. |
| Modo de navegação anônima | As soluções de medição vão estar disponíveis quando o usuário estiver no modo de navegação anônima? | Não, as soluções de medição não estarão disponíveis quando um usuário estiver no modo de navegação anônima. Os cookies de terceiros estão desativados por padrão no modo de navegação anônima. |
| Data clean rooms | As APIs de medição serão compatíveis com as clean rooms? | Uma data clean room típica é um ambiente em que dados de identificadores individuais de diferentes fontes são enviados para um banco de dados para executar análises com base na mesclagem desses dados. Os dois frameworks de medição para as APIs do Sandbox de privacidade são relatórios de eventos e de resumo. Os relatórios de evento contêm um ID de evento fornecido pela adtech que pode ser usado em um cleanroom de dados, mas as informações associadas à conversão são limitadas e ruidosas. Os relatórios criptografados que podem ser agregados 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 uma entrada para as análises que você realiza ou como informações complementares. |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 4º trimestre de 2022) Relatório de atrasos |
Qual é o atraso esperado nos relatórios? | Atualização do 1º trimestre de 2023: Após o feedback dos parceiros, compartilhamos propostas para diminuir o atraso e mitigar o impacto dele. As duas propostas foram aceitas pelas adtechs durante as chamadas do WICG. |
| Regra "Sem duplicatas" | Como você lida com um "relatório agregável atrasado" se os relatórios agregáveis, que têm o mesmo ID compartilhado, já foram processados? | Compartilhamos uma proposta sobre a adição de um atraso extra de relatório às informações compartilhadas dos relatórios agregáveis e a definição de ID compartilhado para o serviço de agregação para abordar parcialmente o impacto da perda de atraso na API agregada. Agradecemos qualquer feedback sobre a proposta. |
| Processamento de dados | Solicitação 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 usar o Privacy Budget para permitir esse caso de uso e agradecemos mais feedback. |
| (Também informado no 2º trimestre de 2022) Ergonomia da consulta | Ative a consulta de agregação de chaves. | Atualização do primeiro trimestre de 2023: A solicitação de recurso ainda está sendo considerada, mas não temos propostas para compartilhar no momento. |
| Limitações do teste de origem | Esclarecer o escopo do serviço de agregação, como a "regra de não duplicidade", que não é aplicada no teste de origem. | Estamos atualizando nossa documentação para esclarecer o que vai estar disponível no teste de origem e no GA. |
API Private Aggregation
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Orçamento de contribuição de agregação particular | O orçamento de contribuição L1 é muito restritivo. | Cada chamada para a API Private Aggregation é chamada de contribuição. Para
proteger a privacidade do usuário, o número de contribuições que podem ser
coletadas de uma pessoa é 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 design atual, definimos um limite para as contribuições de uma origem de relatório 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 ajustem os valores que contribuem com base no volume esperado, ou seja, não apenas usando um valor de 1. Portanto, pode ser melhor usar um valor menor para os eventos mais comuns para evitar esgotar o orçamento. No momento, estamos buscando feedback sobre o orçamento de contribuição da API de agregação particular em relação ao limite numérico e ao escopo. Estamos considerando mudar o escopo de por origem para por site e mover a restrição atual para uma janela de 10 minutos com uma restrição diária maior. |
Limitar o rastreamento oculto
Redução de user agent/Dicas de cliente HTTP do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Adoção do UA-R | Dos 10.000 sites mais acessados no Reino Unido, apenas 1% dos sites que usam publicidade programática estão enviando dicas de cliente HTTP. As DSPs que não migraram podem ter um impacto nos recursos antifraude. | Depois de realizar uma análise no mesmo conjunto de dados, descobrimos que, se você considerar o uso do UA-CH usando a tag <meta> HTML e as APIs do 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 o feedback do ecossistema, estamos confiantes em avançar com o lançamento gradual da Fase 6 da redução do UA, de acordo com o cronograma publicado, mantendo a CMA informada. Os sites tiveram quase dois anos de antecedência para se preparar para a transição, e um teste de descontinuação ainda está disponível para sites que não estão prontos. |
| Dicas para outros formatos | Pedido para que o UA-CH forneça outros formatos, como TV e VR | Agradecemos a proposta e estamos analisando a possibilidade de incorporá-la ao design. Agradecemos mais feedback. |
| Testes automatizados | Pedido para resolver o bug UA-CH no Chrome sem cabeça antes da Fase 6 do UAR ser enviada | O bug em questão foi corrigido. |
| Suporte a 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 tem suporte. | Para navegadores iOS que não são o Safari (incluindo o Chrome no iOS), o projeto do WebKit precisa adicionar suporte ao UA-CH antes que ele possa ser ativado, porque ele controla a pilha de rede. |
Proteção de IP (anteriormente Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informados no 4º trimestre) Casos de uso de geolocalização | A Proteção de IP pode impedir que casos de uso legítimos de geolocalização funcionem no futuro, como a personalização de conteúdo com base na geolocalização. | Nossa resposta não mudou desde o 4º 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 buscando feedback do ecossistema sobre a granularidade da geolocalização por IP." |
| Conformidade com as normas | Se uma região tiver menos de 1 milhão de habitantes, o limite atual de 1 milhão para proteção de IP 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. Estamos buscando feedback do ecossistema sobre conformidade regulatória em proteção de IP. |
| Mitigação de abuso | As partes podem contornar a proteção de IP compartilhando endereços IP não mascarados com outras pessoas. | Estamos cientes do risco de que a proposta atual de proteção de IP
não impeça tecnicamente que as partes compartilhem endereços IP
desmascarados com outras pessoas. Estamos trabalhando em mitigações que vão evitar
esse risco de abuso. À medida que iteramos a proposta, incentivamos mais feedback e discussão. Especificamente, gostaríamos de saber de casos de uso em que as partes acreditam que precisam compartilhar endereços IP não mascarados com outras partes. |
| Bloqueio de rede | As partes podem contornar o bloqueio de rede usando proxies de proteção de IP. | A entidade que executa o bloqueio precisa desativar a proteção de IP para esse cenário. Respondemos ao problema e agradecemos o 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 da TAG, para evitar lances em inventários de anúncios com grande probabilidade de fraude (ou pelo menos não monetizável). Caso uma adtech também seja um rastreador e possa estar sujeita à proposta de proteção de IP, essa empresa pode perder a capacidade de realizar uma verificação básica contra anúncios antes de comprar o inventário de publicidade. | Encorajamos mais feedback e discussão sobre a proposta de proteção de PI em possíveis problemas e soluções. Uma opção é aplicar listas semelhantes à Proteção de IP, para que não haja proxy de clientes originados de endereços IP sinalizados anteriormente. |
Reforçar os limites de privacidade entre sites
Conjuntos próprios
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado no 4º trimestre) Limite de domínio | Pedido para expandir o número de domínios associados | Nossa resposta não mudou desde o 4º trimestre de 2022: "Esclareceremos nas ligações do WICG que o Chrome está comprometido em oferecer uma solução utilizável que considere os interesses de privacidade dos usuários também. Nesse sentido, gostaríamos de receber feedback da comunidade sobre casos de uso específicos que podem ser afetados pelo limite de domínio, para que a equipe possa considerar maneiras de resolver esses casos e continuar protegendo a privacidade do usuário." |
| Envio de QPS alternativo | Proposta de forma alternativa de enviar listas globais para o QPS | No momento, estamos nos preparando para enviar conjuntos próprios (FPS) no Chrome e configuramos um repositório centralizado do GitHub para aceitar envios de conjuntos. Como esperamos que o FPS preencha uma lacuna com as soluções de plataforma da Web atuais em preparação para a descontinuação de cookies de terceiros, esperamos aprender com elas como o FPS é aproveitado pelos autores do site. À medida que a lista de conjuntos cresce com o tempo e o ecossistema se adapta a um mundo pós-cookies de terceiros, também podemos amadurecer o processo até o ponto em que podemos considerar esquemas descentralizados alternativos, como o proposto. Com o processo atual, esperamos definir tempos de vida, o que nos permitirá evoluir o processo de entrada ao longo do tempo. Podemos revisitar essa ideia quando o processo de envio estiver mais maduro. |
| Moderação de repositório | Ativar a moderação da comunidade do repositório de envio de QPS para evitar abusos. Pessoas mal-intencionadas podem facilmente sobrecarregar o processo usando origens de uso único para propor conjuntos, e um volume excessivo de solicitações pode afetar as operações de propostas de conjuntos genuínos. | Estamos tentando 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 para o processo de envio. Para atingir esse objetivo, também vamos garantir que o processo seja resistente a envios de spam / temporários. |
| Subconjuntos associados | O FPS vai oferecer suporte a casos de uso de fluxo de fornecedor/SaaS de terceiros com subconjuntos associados? | Os fluxos de fornecedores terceirizados / SaaS não são um caso de uso que é considerado atualmente no escopo dos conjuntos próprios. Agradecemos mais feedback sobre como os cookies cross-site são usados para esses casos de uso. |
| Integração de FPS + CHIPS | Solicitação de integração de FPS + CHIPS para oferecer suporte a casos de uso como testes A/B | Estamos discutindo esse caso de uso e também considerando discutir isso em uma chamada do WICG. Aceitamos mais sugestões aqui. |
| GDPR | Proposta de um novo subconjunto de FPS a ser modelado de acordo com os conceitos da GDPR | Discutimos essa proposta internamente e a comparamos com outros feedbacks recebidos, além das nossas metas de privacidade. Enviamos uma resposta explicando por que não vamos seguir essa proposta no momento. |
| Memória | Mudança esperada no tamanho da memória do navegador quando a lista de QPS é incorporada. | Há precedentes de navegadores armazenarem esses tipos de listas com impacto mínimo na memória, como a lista de proteção contra rastreamento do Disconnect. Embora a lista de conjuntos próprios seja copiada localmente para cada cliente do Chrome, vamos continuar monitorando o tamanho do arquivo e temos confiança de que podemos otimizar o uso de memória. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Limitações dos frames isolados | Esclarecimento sobre as limitações impostas por Fenced Frames | Em março, atualizamos nosso texto explicativo sobre frames delimitados, que fornece informações sobre os recursos e aceitamos qualquer feedback adicional. |
| Expandir as informações de acesso | Solicitação para expandir o acesso a informações sobre frames vizinhos | Estamos tentando entender melhor por que esse é um requisito do ecossistema e agradecemos qualquer outro feedback. |
| Frames isolados e iframes | Perguntas sobre a paridade de recursos entre frames cercados e frames inline | Todas as APIs e relatórios disponíveis do Sandbox de privacidade vão estar disponíveis para iframes e FencedFrames da mesma forma. |
| Redimensionar frames isolados | A restrição de mudanças no tamanho do frame afeta alguns casos de uso. | Queremos saber mais sobre os tipos de casos de uso que são afetados pela restrição e gostaríamos de receber mais feedback. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Worklets de terceiros | Terceiros podem gravar no Shared Storage particionado por origem? Ou chama outros worklets para medição de terceiros? | A origem do contexto de navegação em que o código está sendo executado determina em qual armazenamento compartilhado os dados são gravados. Quando o 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 seja gravado na própria origem. O código de terceiros também pode ser incorporado como um script em vez de um iframe, 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 esse armazenamento. |
| Desduplicação | A eliminação de duplicação não seria possível para interações fora do ecossistema do Chrome. | O armazenamento compartilhado tem como objetivo fornecer saídas de alcance exclusivas com base no navegador Chrome. Temos interesse em trabalhar com as adtechs para entender como essas saídas podem ser usadas como parte dos modelos de alcance mais amplos. Entendemos que as saídas podem representar apenas uma parte das interações e que é interessante trabalhar com as adtechs para explorar outras metodologias de modelagem que podem ser sobrepostas. |
| Janela de lookback de conversão | Solicitar uma janela de lookback para a taxa de conversão e conferir as mudanças na conversão ao longo do tempo | Isso pode ser implementado processando os vários caminhos de conversão no lado do cliente usando o armazenamento compartilhado, que oferece mais flexibilidade para análises avançadas em relação ao armazenamento de navegador seguro não particionado. |
| Janela de expiração do item | Pedir a prorrogação do período de validade para 90 dias | A política de retenção de dados foi atualizada em novembro de 2022 e afirma que cada chave é limpa após 30 dias da última gravação. Agradecemos o feedback para entender se a nova política vai funcionar para o ecossistema. |
| Rotação de criativos | Os casos de uso de rotação de criativos não refletem as ações reais pós-leilão. | Queremos saber a opinião de mais empresas de adtech do lado do comprador sobre se a documentação de rotação de criativos está correta ou não. |
CHIPs
Nenhum feedback recebido neste trimestre.
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Endpoint de declaração de identidade | Permita explicitamente solicitações arbitrárias para o endpoint de declaração de identidade. | Estamos colaborando com a Mozilla nessa pull request para limitar a capacidade dos sites de fazer solicitações com credenciais entre origens em silêncio sem causar aborrecimentos aos usuários. Também vamos continuar analisando e respondendo a outros feedbacks. |
| Preencher a identidade | O FedCM pode ser usado para pré-preencher formulários de login com um provedor de identidade da lista do FedCM? | A preocupação com esse caso de uso é que ele 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 e agradecemos mais feedback. |
| Seleção de conta contextual | Proposta para adicionar indicadores contextuais na interface de seleção de contas | Estamos considerando essa proposta e agradecemos outras discussões. |
Combater spam e fraudes
API Private State Tokens (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 de antifraude e os compartilhamos publicamente (atas, resultados). | Planejamos incorporar esse feedback ao desenvolver novas propostas e protótipos de APIs criadas especificamente para preservar a privacidade e oferecer recursos antifraude. Esperamos priorizar o desenvolvimento quando houver necessidade suficiente e tecnologia disponível para introduzir o recurso na Web, preservando a privacidade do usuário. Por exemplo, a integridade do dispositivo e da inicialização foi bem classificada, e muitas plataformas têm APIs que compartilham com segurança uma avaliação da integridade do dispositivo. Portanto, é um bom candidato para continuar a exploração nos grupos da comunidade. |
| Feedback sobre a intenção de envio de PST | Como parte da intenção de envio, recebemos uma preocupação em prosseguir porque estamos usando uma versão mais antiga do Privacy Pass. Também recebemos feedback de que a especificação não estava clara em determinadas seções e precisava ser melhorada para facilitar a compatibilidade do navegador. | Planejamos implementar muitas das mudanças sugeridas na especificação antes
do lançamento da versão GA, além de algumas mudanças na API. O feedback foi enviado no
final do primeiro trimestre, então estamos acompanhando as questões do
github com detalhes específicos e uma atualização do nosso plano de lançamento (em
andamento, desde a publicação deste relatório de feedback). Para mudanças maiores na API, estamos abertos a considerá-las, mas acreditamos que a melhor maneira de seguir em frente é lançar a 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 adotar e desenvolver um plano para fazer a transição com cuidado. |