Relatório trimestral do 1º trimestre de 2024 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 específicos em relação às APIs Topics, Protected Audience 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
- ARA
- API Attribution Reporting
- 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
- API PAT
- API Protected Audience (antes conhecida como FLEDGE)
- PatCG
- Grupo da comunidade de tecnologias de publicidade privada
- RP
- Entidade confiável
- RWS
- Conjuntos de sites relacionados (antigamente "Conjuntos primários")
- 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 ou tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Governança | Interesse em um período de comentários público para atualizações de governança do Sandbox de privacidade. | Estamos abertos a feedback razoável das partes interessadas sobre qualquer desenvolvimento significativo relacionado ao Sandbox de privacidade, incluindo a governança futura do Sandbox de privacidade. |
| Teste | Fases de teste adicionais para 3PCD, além do teste facilitado do Chrome atual de 1%. | Não temos a intenção de oferecer testes facilitados pelo Chrome além do 1% atual do tráfego do Chrome ativado desde o início de janeiro. |
| Web para app | A 3PCD em dispositivos móveis não deve acontecer antes que a interoperabilidade total entre a Web e o app seja alcançada. | Concordamos que é desejável oferecer suporte à interoperabilidade entre apps e a Web. Por isso, lançamos a medição de atribuição entre apps e na Web e estamos testando soluções de segmentação da Web para apps. No entanto, não planejamos atrasar o 3PCD na Web para dispositivos móveis. Não temos a meta de 100% de cobertura no final do 3PCD. Em vez disso, esperamos que a compatibilidade no Android para medição entre apps e da Web seja razoavelmente alta no 3PCD e aumente com o tempo, à medida que os usuários atualizam os smartphones. |
| Função do navegador | O Chrome parece estar assumindo o papel de um servidor de anúncios ou SSP. | O Chrome não assume o papel de servidor de anúncios ou SSP. Com a API PA, o Chrome oferece um contêiner para que servidores de anúncios, SSPs, DSPs e outras adtechs tragam a própria lógica de lances e pontuação. |
| Orientações sobre casos de uso | Orientações mais claras sobre quais casos de uso serão compatíveis com as APIs do Sandbox de privacidade. | No início do projeto do Sandbox de privacidade, a documentação para desenvolvedores se concentrava principalmente em trazer os desenvolvedores para os processos de discussão e feedback de todas as propostas. Isso significa que o conteúdo geralmente era estruturado para entender a motivação e os conceitos por trás do projeto, seguido de detalhes do desenvolvimento inicial e de testes de cada proposta. Isso foi eficaz para criar uma colaboração real do ecossistema no desenvolvimento das propostas, mas, à medida que as APIs foram avançando para a disponibilidade geral, um novo público de desenvolvedores passou a usar o site para criar com base nas APIs, em vez de contribuir com o desenvolvimento delas. Recentemente, atualizamos a navegação do site para desenvolvedores do Sandbox de privacidade para que ela se concentre em casos de uso, usando categorizações semelhantes ao IAB Tech Lab no relatório recente da força-tarefa do Sandbox de privacidade. Vamos continuar com essa abordagem baseada em casos de uso para a documentação. |
| Ambiente de desenvolvimento local | Como continuar a desenvolver e testar nosso front-end localmente em http://localhost quando o cookie é SameSite=Secure e o back-end é exibido por uma CDN? | Estamos discutindo esse problema aqui e agradecemos o feedback do ecossistema. |
| Mitigação de 3PCD | Existe uma maneira programática de saber se os 3PCs estão bloqueados ou quando as heurísticas estão ativas? | No Chrome, a detecção de recursos e o document.hasStorageAccess chamado em um iframe permitem que um desenvolvedor saiba se a origem no iframe tem acesso a 3PCs. |
| Teste de vídeo | No momento, não é possível testar anúncios em vídeo no Sandbox de privacidade. | O Chrome postou uma discussão e uma demonstração de várias maneiras possíveis de usar o vídeo com a API PA hoje (consulte 242 e 254 no nosso repositório de demonstrações no GitHub). Eles não são códigos de amostra que as adtechs vão adotar em massa, mas sim uma prova de conceito e demonstração das técnicas que podem oferecer suporte à renderização de vídeo VAST com a API PA. Durante esta discussão, também ficou claro que, embora a renderização de vídeo já seja possível hoje, há mudanças que o Chrome pode fazer para simplificar a implementação com a API PA. Por exemplo, as atualizações de substituição de macros (discutidas aqui), que já estávamos planejando abordar com base no feedback sobre casos de uso de verificação de anúncios de terceiros para a proteção da marca, também abordariam o feedback no caso de uso de vídeo, em que o comprador procura quais macros do vendedor usar na renderização. Até o momento, a maioria das discussões se concentrou na renderização de anúncios em vídeo VAST. A renderização de anúncios nativos pode usar as mesmas abordagens e é mais fácil de várias maneiras. No momento, os anúncios nativos parecem receber menos atenção do que os vídeos, mas isso é apenas uma questão de priorização do setor de adtech, não uma barreira técnica para a implementação. |
| Medição de não anúncios | O 3PCD pode afetar as soluções de medição de público-alvo que não são relacionadas a anúncios. | As APIs de medição não exigem que o caso de uso esteja relacionado a anúncios. Enquanto a ARA é mais específica para uma jornada de publicidade típica,a agregação privada é de uso geral. Esses dois blocos de construção podem ser usados para abordar uma ampla gama de atividades de medição. |
| Criadores de conteúdo | O Sandbox de privacidade foi estruturado para incentivar os criadores de conteúdo a produzir mais conteúdo para o YouTube e menos para os próprios sites. | O objetivo do Sandbox de privacidade é manter a atividade das pessoas em uma Internet aberta e livre. Sabemos que os editores dependem de anúncios para produzir conteúdo e disponibilizá-lo o mais amplamente possível. Os anunciantes ajudam as pessoas a descobrir novos produtos ou ofertas que elas possam querer. Os recursos do Sandbox de privacidade permitem que sites de todos os tipos, incluindo aqueles que trabalham com criadores de conteúdo, mostrem anúncios úteis com base na atividade das pessoas com diferentes partes, sem revelar a identidade do usuário a essas partes. |
| Linhas do tempo mais claras | Cronogramas de lançamento mais claros e detalhados para as tecnologias do Sandbox de privacidade. | A documentação da API do Sandbox de privacidade inclui páginas de status e disponibilidade da API. Essas páginas listam os próximos recursos e as respectivas linhas do tempo (por exemplo, API PA, ARA). Confira uma visão central desses status aqui. |
| Machine learning | As adtechs não conseguem treinar corretamente os modelos de aprendizado de máquina até que o 3PCD se estenda além de 1%. | A expansão da 3PCD para mais navegadores de teste não garante que as APIs vão ter mais uso, o que provavelmente é o que as adtechs estão procurando para treinar ainda mais os modelos de aprendizado de máquina. Se o uso mais amplo do ecossistema não for o que as adtechs procuram para treinar modelos de aprendizado de máquina, não há motivo para expandir o 3PCD. Uma adtech que queira treinar modelos com mais tráfego pode fazer isso hoje sem aumentar o 3PCD. Isso pode ser feito sem que o Chrome pareça avançar no 3PCD antes do fim da paralisação. |
| Caso de uso sem suporte | No momento, os casos de uso de DSPs de autoatendimento não estão sendo considerados. | Há vários DSPs de autoatendimento que fornecem feedback público regularmente sobre as APIs. Vários desses DSPs que enviam feedback público regularmente também se cadastraram como testadores. Além disso, o Chrome está engajado em temas típicos de DSP de autoatendimento, como servidores de anúncios de terceiros e de vídeo. As chamadas semanais recentes da API PA abordaram esses tópicos. |
| Teste de origem | Solicitação de OT para sites que querem uma aceleração mais agressiva e cobertura de teste para 3PCD. | O Chrome está desenvolvendo um OT próprio, que permite que as origens ativem o comportamento de desativação de cookies de terceiros. As origens de nível superior que se registrarem para o teste e implantarem tokens terão os 3PCs bloqueados como se o dispositivo do usuário tivesse a proteção contra rastreamento ativada. Essa OT vai oferecer uma oportunidade valiosa para que os sites realizem testes mais amplos de alternativas de longo prazo para os 3PCs, antes da eventual desativação programada para ocorrer após a consulta com a CMA. Ainda estamos trabalhando para finalizar o cronograma de lançamento da OT. |
| Relatório do IAB Tech Lab | Feedback sobre o Sandbox de privacidade recebido do relatório do IAB Tech Lab. | Respondemos ao relatório do IAB Tech Lab em detalhes aqui. Também reconhecemos que "o relatório levanta questões sobre documentação fragmentada, requisitos comerciais, auditorias de terceiros, credenciamento do setor, escalonabilidade, transparência e governança futura, que serão abordadas com o ecossistema e atualizadas nas nossas perguntas frequentes públicas". Já abordamos a documentação fragmentada anteriormente. Abordamos os requisitos comerciais em Garantias de dados e alguns produtos do Google Ads compartilharam as abordagens deles. Tratamos das auditorias de terceiros na Garantia de integridade do algoritmo. Em relação à acreditação, esperamos que esses órgãos continuem a acreditar produtos, incluindo o uso de tecnologias, em vez das próprias tecnologias. Em relação à escalabilidade, continuamos abertos a dados de desenvolvedores que demonstrem problemas. Em relação à transparência e governança, continuamos desenvolvendo em público no GitHub e em fóruns como o W3C, enquanto interagimos com a CMA de acordo com os compromissos. |
| Login do Google | Os logins do Google levariam à possibilidade de o Google usar dados de login de identificação cruzada, o que é contrário aos Compromissos. | O recurso Fazer login com o Google não permite que o Google use dados contrários aos Compromissos. |
| Compatibilidade | Quais são os planos de suporte às APIs do Sandbox de privacidade e compatibilidade com versões anteriores / posteriores? | Quando o Chrome lança um recurso para disponibilidade geral, nosso objetivo é manter o suporte a ele. É claro que nem sempre é possível manter a compatibilidade com versões anteriores. Nesses casos, temos um processo claro para descontinuação e remoção de recursos atuais, descrito aqui. Esperamos continuar adicionando mais recursos às APIs do Sandbox de privacidade ao longo do tempo, em resposta ao feedback do ecossistema sobre casos de uso que se beneficiariam com um suporte melhor. Nesses casos, tendemos a incluir algum tipo de técnica de detecção de recursos para que uma adtech interessada em testar um novo recurso possa perguntar diretamente ao navegador se ele tem suporte. Isso é melhor do que pedir aos desenvolvedores que verifiquem um determinado número de versão do Chrome, já que alguns recursos podem não ser lançados para todos os usuários do Chrome ao mesmo tempo. Por exemplo, nosso trabalho de detecção de recursos para a API PA pode ser encontrado aqui. |
| Implementação do servidor | Em vez de acoplar à própria implementação, o Chrome precisa especificar os comportamentos que uma implementação satisfatória de um servidor de indicadores confiáveis, um servidor de agregação e qualquer outro componente necessário que não seja do navegador precisa atender. Isso permitiria a inovação dentro de limites de privacidade aceitáveis. | Agradecemos e apoiamos o desejo de inovação de terceiros. Para todas as APIs e serviços, nosso objetivo é oferecer flexibilidade às adtechs para implementar a funcionalidade delas. Por exemplo, permitimos que as adtechs usem informações comerciais confidenciais para criar a lógica de lances em leilões. Além disso, recebemos feedback contínuo das adtechs e, quando justificado, incorporamos esse feedback aos nossos designs. Para permitir que outras pessoas executem o próprio código em ambientes de execução confiáveis, o Sandbox de privacidade precisa analisar o código (e todas as mudanças) para confirmar se ele atende às garantias de privacidade. Isso vai exigir um esforço significativo da equipe do Sandbox de privacidade. Por isso, gostaríamos de entender quais benefícios a parte interessada quer alcançar, que não são atendidos por nós hoje. |
| Heurísticas | Quais são os planos de longo prazo para as heurísticas? | De acordo com o que outros navegadores indicaram, pretendemos desativar essas heurísticas à medida que as soluções alternativas forem amplamente usadas, sujeitas a mais análises de viabilidade. Compartilhamos isso aqui. |
| Volume de teste | Volume de tráfego diferente ao comparar dimensões diferentes. | O experimento de 1% tem critérios de exclusão que levam a diferenças na qualificação para o experimento entre diferentes populações de clientes do Chrome. Por exemplo, o experimento exclui usuários do Chrome Enterprise. Portanto, é esperado que a fração de tráfego com rótulos de experimento seja maior nos fins de semana. É normal que haja diferentes porcentagens de tráfego em diferentes fatias de dados (como região geográfica, data e plataforma), e isso está de acordo com o que observamos nos dados do Chrome. |
| Reativar manualmente o 3PC | Os sites vão poder saber quantos usuários (%) reativaram manualmente os cookies depois que o 3PCD for aplicado? | Os usuários poderão reativar o acesso de 3PC no nível do site usando o Bypass do usuário se encontrarem uma falha. Os 3PCs também podem ser reativados por outras medidas, como a API Storage Access. Há medidas técnicas, como hasStorageAccess(), que permitem que os sites detectem se os 3PCs estão ativados ou desativados. No entanto, o Chrome não vai facilitar uma maneira de os sites saberem os motivos da reativação. |
| Proteção antirrastreamento | Por quanto tempo o recurso de interface da Proteção antirrastreamento do Chrome vai estar disponível? | A interface da Proteção contra rastreamento na barra de endereço vai continuar após a descontinuação dos 3PCs. |
| (Também informado nos trimestres anteriores) Suporte a vários navegadores |
Outros fornecedores de navegadores que adotam as APIs do Sandbox de privacidade. | Outros fornecedores de navegadores, como Apple, Mozilla e Microsoft, são participantes ativos em fóruns públicos em que princípios de privacidade e abordagens baseadas em navegadores estão sendo discutidos. Estamos animados com as discussões colaborativas em fóruns como a recente reunião anual do TPAC do W3C e os fóruns do PATCG do W3C, em que vemos sinais de convergência. Por exemplo, o Microsoft Edge anunciou recentemente o plano que "visa maximizar a compatibilidade sintática" com a API PA e a ARA, além de oferecer outros recursos para desenvolvedores. |
| Opção alternativa para incorporações incompatíveis após a 3PCD | Forneça hooks de API para detectar se um iframe / incorporação de terceiros está em conformidade com o 3PCD ou não. | Estamos discutindo a solicitação aqui e agradecemos o feedback do ecossistema. |
| Teste | Solicite flags adicionais em instâncias gerenciadas do Chrome que desativam temporariamente os comportamentos personalizados. | Estamos considerando essa solicitação para instâncias gerenciadas do Chrome e agradecemos outras informações do ecossistema, caso essa flag seja útil. |
Inscrição e atestado
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Verificação de atestado | Como o Google vai garantir a autenticidade dos atestados? | Todos os registrantes precisam manter o arquivo de atestado no lugar enquanto usam as APIs. O Google valida se o arquivo está no lugar e se a sintaxe está correta, mas não valida o comportamento da adtech em relação ao idioma do atestado. |
| Processo de inscrição na API Private Aggregation | Existe uma maneira de verificar o status da inscrição na API Private Aggregation? | Todos os inscritos aprovados recebem um e-mail da equipe de suporte de inscrição após a validação. Se o participante tiver dúvidas durante o processo, ele pode entrar em contato com a equipe de suporte (que será conectada a ele após o envio do formulário de inscrição). A equipe de suporte vai responder e responder a perguntas e fornecer qualquer orientação adicional necessária. |
Mostrar conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| (Também informado nos trimestres anteriores) Classificador: cronograma e documentação |
Deve haver algum mecanismo para revisar a classificação ou, pelo menos, mais transparência sobre como o modo de classificação determina as categorias. | Nossa resposta não mudou em relação aos trimestres anteriores: "A classificação incorreta de sites pode tornar o indicador de tópicos um pouco menos útil como um indicador geral, mas os sites específicos que são classificados incorretamente não são mais ou menos prejudicados do que qualquer outro site. Isso acontece porque as informações contextuais de um site sempre estarão disponíveis para leilões, o que forneceria informações comparáveis ao tema correto, mesmo em caso de classificação incorreta. Gostaríamos de receber seu feedback sobre esse assunto aqui. |
| Google Ad Manager | O Google Ad Manager já está incorporado na maioria dos sites e terá informações muito mais amplas sobre os tópicos dos usuários do que os concorrentes que estão presentes em menos sites. | O requisito de observação existe para garantir que a API Topics não resulte na divulgação de dados do usuário para mais entidades do que as tecnologias que a API está substituindo (incluindo cookies de terceiros). Outras soluções do setor, como o Prebid, trabalham com 10.000 sites e permitem que os participantes do mercado chamem a API Topics usando a tecnologia deles. Além disso, vale ressaltar que o limite de até cinco principais temas por semana pode ter um efeito de equalização, já que os participantes do mercado presentes em muitos sites que podem aprender mais de cinco temas equivalentes usando 3PCs serão limitados a cinco. |
| (Também informado nos trimestres anteriores) Utilidade para diferentes tipos de partes interessadas |
Preocupações sobre o valor criado e a distribuição desse valor para sites, dependendo do nível de tráfego ou da especialização do conteúdo. | Sabemos que os sites especializados têm mais probabilidade de contribuir com tópicos mais específicos do que os domínios de interesse geral. No entanto, nem todos os sites especializados contribuem com temas de valor comercial. Além disso, essa dinâmica reflete o status quo e é totalmente independente do fim do suporte a 3PCs no Chrome. Além disso, no ambiente atual, alguns sites oferecem mais valor do que outros nos sistemas de relevância de anúncios com base em 3PC. Além disso, os temas entre sites especializados podem ser mutuamente benéficos, já que anunciantes diversos podem veicular campanhas em diversos conjuntos de temas, e a lógica de lances pode observar o valor em uma ampla gama de temas. |
| Nomes de host x URLs completos | A classificação com base nos nomes de host dos sites é suficientemente eficaz e reduz o risco de privacidade em comparação com URLs completos? | Consideramos usar URLs de informações ou títulos de páginas, além de nomes de host, e determinamos que os benefícios potenciais seriam superados pelos riscos à privacidade e à segurança do usuário. Um exemplo de risco à privacidade do usuário é a classificação de informações sensíveis incluídas no URL ou no título da página em tópicos do usuário. |
| Temas como indicador | Pedido de orientação sobre como combinar a API Topics com outros indicadores e quais outros indicadores podem ser úteis. | As soluções de adtech podem alcançar os melhores resultados ao combinar todas as ferramentas disponíveis, como aprendizado de máquina e indicadores seguros de APIs que preservam a privacidade, com dados contextuais, de criativos e próprios. Confira mais instruções neste link. |
API Protected Audience (antes conhecida como FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Testar o volume de tráfego | Os testadores estão relatando um baixo volume de resposta de lances para o leilão da API PA. | 1. A densidade de lances está relacionada à participação do ecossistema na API PA, que deve continuar aumentando em 2024 e além. No fim das contas, cabe aos anunciantes, agências e provedores de tecnologia determinar como alocar os orçamentos de campanha. Alguns participantes do ecossistema podem adiar o investimento em várias soluções "sem cookies", incluindo a API PA, até depois do 3PCD. Nesse momento, esperamos que eles aumentem a alocação do orçamento da campanha para essas soluções. 2. O volume de solicitações de lances em leilões da API PA pode ser afetado por (1) porque os editores e os provedores de adtech podem decidir não iniciar leilões da API PA se acharem que a demanda é baixa. Cabe aos editores determinar a prioridade de atualizar as páginas e participar. Por esses motivos, esperamos que os publishers levem algum tempo para testar e aumentar o tráfego gradualmente. Esse relatório também inclui uma resposta do Google Ad Manager sobre os controles do editor para a participação na API PA. |
| (Também informado nos trimestres anteriores) 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? | Os mecanismos de relatórios dos anúncios da API PA retêm as informações usadas para distinguir o tráfego humano do tráfego de bots. Além disso, as técnicas atuais de inclusão ou exclusão de domínios podem ser usadas na API PA. Isso é descrito com mais detalhes na nossa resposta ao relatório do IAB Tech Lab sobre o Sandbox de privacidade. |
| Restrição de mesma origem no proprietário do IG e no URL da lógica de lances | Com o requisito de mesma origem, os endpoints de um proprietário do IG serão forçados a passar pelo mesmo balanceador de carga, o que pode levar à rejeição de redirecionamentos. | O requisito de mesma origem para carregamento de script é uma proteção de segurança importante. Confira alguns detalhes sobre uma solução proposta que equilibra o feedback do ecossistema e outras considerações aqui. |
| Leilão privado com vários slots | Há muito espaço para permitir leilões particulares de vários slots dentro dos limites de privacidade usando ruído e integração mais estreita com as práticas atuais de anúncios. | Estamos considerando esse feedback e avaliando a solicitação de leilões com várias tags em relação ao aumento da complexidade e dos riscos de privacidade associados a esse recurso. Discutimos esse problema aqui durante uma chamada do Grupo da comunidade do Incubador da API do PA (WICG, na sigla em inglês). |
| Vendedores de nível superior | A estrutura atual da API PA oferece a qualquer vendedor de nível superior muito mais dados e entendimento do valor relativo das impressões do que os editores ou vendedores de componentes. | Em um leilão de vários vendedores, cada vendedor tem o melhor lance. Além disso, aprendemos com o ecossistema que os editores podem querer considerar a demanda vendida diretamente ao lado dos melhores lances de cada vendedor com quem trabalham. É necessário analisar todas essas possíveis oportunidades de monetização para determinar qual anúncio veicular. Essa situação, em que é necessário que algum ator veja o conjunto completo de opções para escolher um anúncio a ser veiculado, é anterior à API PA. A API PA pretende oferecer suporte a leilões de vários vendedores e à vontade dos editores de considerar o melhor lance de cada vendedor ao lado das campanhas de publicidade vendidas diretamente, quando aplicável. Isso significa que precisa haver um mecanismo para escolher entre essas oportunidades de monetização, como já existe. Não acreditamos que o navegador deva selecionar qual anúncio será veiculado. Portanto, o conceito de um vendedor de nível superior é necessário para selecionar um anúncio vencedor entre muitas possibilidades. A lógica do vendedor de nível superior precisa considerar os melhores lances de cada vendedor com quem o editor escolhe trabalhar. A lógica do vendedor pode optar por fornecer informações sobre as campanhas vendidas diretamente pelo editor, quando essas informações estiverem disponíveis. Todas essas informações podem ser consideradas na lógica de seleção de anúncios de nível superior. Isso significa que a lógica de nível superior identifica os melhores lances do leilão da API PA e, quando aplicável, todas as opções de anúncio vendido diretamente pelo editor para determinar um vencedor. O Google Ad Manager detalha a implementação da API PA como um vendedor de nível superior neste relatório no tema "Acesso à informação". |
| Separação de anúncios competitivos | Pedido de separação de anúncios competitivos, como impedir que anúncios de marcas concorrentes apareçam um ao lado do outro. | Não sabemos como garantir a separação competitiva no atual ecossistema de publicidade digital programática, com lances e vários vendedores. No entanto, a API PA permite que os vendedores busquem outros indicadores em tempo real com base em uma combinação de renderURL e nome de host (que representa o domínio do editor) que podem ser usados durante a função scoreAd() ao avaliar criativos. Isso pode ser usado pelos vendedores para impedir que anúncios de marcas concorrentes apareçam um ao lado do outro, supondo que o editor queira aplicar essa regra. |
| Informações limitadas | A API PA reduz as informações disponíveis para os editores, como valor do anúncio, nome do comprador do componente, nome do anunciante, URL da página de destino, tamanho do criativo, tempo de resposta, taxa de lances e lances perdidos. | Propomos algumas soluções possíveis aqui e aceitamos outros feedbacks do ecossistema. |
| Relatórios no nível do evento | Os editores não conseguem informações suficientes sobre o anúncio veiculado após a descontinuação da API PA de relatórios no nível do evento. | Sabemos dos diferentes casos de uso de relatórios que precisamos continuar a oferecer suporte quando os relatórios de eventos forem desativados. Por isso, a data de desativação dos relatórios de eventos não será antes de 2026. Até lá, convidamos você a participar ativamente enquanto nos envolvemos com o ecossistema em caminhos duradouros, que podem incluir novas ideias para coletar informações preservando a privacidade. |
| Vários SSPs | O valor agregado de ter várias SSPs será muito baixo para os editores. | Não acreditamos que isso seja correto e gostaríamos de receber mais feedback do ecossistema para entender o motivo dessa afirmação. |
| Atividades de curadoria | Não é possível realizar atividades de curadoria com a API PA. | Recebemos feedback sobre a capacidade dos vendedores de usar a API PA para disponibilizar informações do público-alvo aos compradores na Web (também conhecida como extensão de público-alvo). Acreditamos que isso seja possível hoje, usando a funcionalidade de delegação do PA com os contratos comerciais. Ao mesmo tempo, estamos considerando ativamente se e como podemos acomodar melhor esses tipos de casos de uso. |
| Desativação do comprador | A recusa padrão do comprador provavelmente vai causar resultados menores nos leilões de componentes. | Ao definir um leilão de PA de um único vendedor ou de vários vendedores, o vendedor precisa listar explicitamente os compradores no campo interestGroupBuyers do AuctionConfig. Isso é baseado no feedback do ecossistema de que os vendedores têm contratos com alguns compradores e não com outros. Portanto, eles precisam de controle explícito sobre quais compradores incluir no leilão. Convidamos você a discutir mais sobre o assunto no GitHub. |
| Tamanho do anúncio | Não foi possível fazer o pré-filtro com base no tamanho do anúncio e do slot. | Estamos trabalhando para adicionar esse recurso. Mais detalhes estão disponíveis aqui. |
| Suporte para segmentação negativa do Instagram | Uma API para oferecer suporte à segmentação negativa do Instagram: veicular anúncios somente se o usuário não pertencer a um grupo. | Esta questão do GitHub propôs uma maneira alternativa de implementar a segmentação negativa, em que o navegador informa diretamente ao servidor de anúncios quais regras de segmentação negativa devem estar em vigor para uma solicitação de anúncio específica. Embora essa seja uma abordagem interessante, todas as versões dessa ideia que investigamos permitem que o servidor identifique o usuário de forma exclusiva. |
| Lei dos Serviços Digitais | Como um editor pode usar os frames limitados, mas também impedir que as respostas com informações sujeitas à Lei de Serviços Digitais sejam renderizadas? | Como acontece com qualquer nova tecnologia, cada empresa é responsável por garantir que o uso do Sandbox de privacidade esteja em conformidade com a lei. O Google não pode dar conselhos jurídicos. Para cada API, publicamos uma documentação técnica extensa, que deve fornecer a base para fazer as avaliações legais necessárias. Os frames limitados não são necessários para uso na API PA antes de 2026, permitindo que as partes interessadas tenham mais tempo para garantir que o uso dessa tecnologia esteja em conformidade com toda a legislação relevante. |
| Documentação | A função updateAdInterestGroups() é temporária? | Não anunciamos nenhum plano de descontinuar o updateAdInterestGroup. No futuro, poderemos aplicar proteções de privacidade semelhantes às que mencionamos publicamente para outros mecanismos de atualização do IG, por exemplo, usando um endereço IP também como proxy e adicionando um pouco de atraso antes da atualização. |
| Suporte a metadados de compra e propriedade de lógica para não DSPs | Solicitação de uma maneira de atuar como proxy para DSPs. | Estamos cientes do feedback de segmentos que não são DSP e estamos considerando essa solicitação. Queremos receber mais feedback do ecossistema. |
| Relatórios | Pedido para adicionar o recurso de gerenciador personalizado para o intervalo / valor de indicadores nos relatórios de agregação privada. | Estamos cientes disso, e este pedido de recurso está na nossa fila para análise. Agradecemos o feedback do ecossistema aqui. |
| Documentação | Há um link em que é possível conferir todos os cabeçalhos de resposta que precisam ser definidos pelo anunciante e pelo domínio do proprietário (delegado)? | Estamos planejando atualizações na documentação para esclarecer isso e agradecemos o feedback do ecossistema. |
| Lances com várias torres | Solicitação de uma explicação do fluxo de trabalho (treinamento e inferência) por meio de um diagrama de arquitetura / bloco sobre como uma abordagem multitorre é prevista no contexto da API PA. | Agradecemos o feedback. Temos algumas apresentações sobre o assunto que vão servir de base para criarmos mais documentação. |
| Segmentação negativa | Capacidade do Sandbox de privacidade de proteger públicos sensíveis e menores de idade de anúncios inadequados, por exemplo, jogos de azar. | A API PA não considera o conteúdo dos anúncios mostrados. Isso está sob o controle dos desenvolvedores de adtechs que usam a PA. Em geral, o editor e os provedores de adtechs podem bloquear criativos de anúncios nos leilões da Protected Audience usando informações contextuais da página e conjuntos de regras do editor. Isso reflete nosso entendimento da abordagem do ecossistema para esses desafios. Para os compradores, a funcionalidade de segmentação negativa do IG também pode ser útil para alguns casos de uso de compliance. |
| Design de API | O Google está resistindo e quer que as adtechs usem uma função de lance universal, aumentando a latência, em vez de diferentes biddingLogicURLs em diferentes IGs, o que é permitido. | Durante nossas discussões sobre a latência do leilão, destacamos que a reutilização do mesmo script em todas as IGs de um comprador tornaria os lances desse comprador mais rápidos. Confira mais detalhes aqui, além de outras recomendações para melhorar a latência do leilão da API PA. |
| Marketing baseado em contas | A API PA não é uma API limpa para casos de uso de marketing baseado em conta. | Gostaríamos de receber feedback do ecossistema sobre casos de uso específicos que eles acreditam não ser possíveis e incentivar os participantes do ecossistema a continuar essa discussão no nosso repositório público do GitHub ou em ligações semanais. |
| Teste A/B | Quando a API PA é configurada na GAM para um editor, ela precisa ser ativada para todo o inventário ou nenhum. Isso limita a capacidade dos editores de realizar um teste A/B viável. | Resposta fornecida pelo Google Ad Manager : os controles da API PA no Google Ad Manager (GAM) afetam a capacidade do GAM de usar a API, desde que ela esteja disponível. Portanto, os editores podem executar testes A/B usando a funcionalidade de política de permissões do Chrome para desativar o uso da API em um subconjunto de tráfego a ser usado como um grupo de controle para um teste A/B. |
| Machine learning | Os editores precisam de mais controle sobre o uso proposto de aprendizado de máquina do GAM. | Resposta do Google Ad Manager: em janeiro de 2024, lançamos um controle que permite aos editores desativar o regulador de aprendizado de máquina e ativar os leilões da API PA com vendedores que não são do Google em todo o tráfego. Confira mais detalhes sobre esse controle na Central de Ajuda. |
| (Também informado nos trimestres anteriores) Leilões de nível superior |
Capacidade de usar o servidor de anúncios do publisher do Google sem dar ao GAM controle do leilão da API PA de nível superior. | Resposta fornecida pelo Google Ad Manager: Por motivos explicados no Relatório do terceiro trimestre de 2023 do Google, os planos do GAM para a integração com a API PA não incluem o suporte a editores que usam o GAM como servidor de anúncios do editor sem controle do leilão de nível superior. |
| Acesso à informação | O GAM tem acesso a informações valiosas de concorrentes, incluindo preços de leilão contextual, indicadores fornecidos por compradores aos SSPs para o leilão da API PA e parâmetros de configuração dos SSPs. | Resposta do Google Ad Manager: Há anos, temos um forte foco na justiça do leilão, incluindo nossa promessa de que nenhum preço de nenhuma das fontes de publicidade não garantidas de um editor, incluindo os preços de itens de linha não garantidos, será compartilhado com outro comprador antes que ele dê lances no leilão. Isso foi reafirmado em nossos compromissos com a Autoridade de Concorrência da França. Para leilões da API PA, pretendemos manter nossa promessa e não compartilhar o lance de nenhum participante do leilão com outro participante antes do término do leilão em leilões com vários vendedores. Para deixar claro, não vamos compartilhar o preço do leilão contextual com nenhum leilão de componentes, incluindo o nosso, conforme explicado nesta atualização. Além disso, não usamos informações sobre configurações de leilão de componentes, incluindo indicadores fornecidos por compradores para SSPs, como parte do nosso próprio leilão. Na verdade, gostaríamos de mudanças na API PA que permitam aos vendedores de componentes especificar as configurações de leilão de componentes de uma forma ofuscada do vendedor de nível superior. |
| Leilões de componentes | Como o leilão de nível superior, o GAM controla quais SSPs executam leilões de componentes para cada oportunidade de anúncio. | Resposta do Google Ad Manager: como servidor de anúncios do editor, o GAM oferece uma API leve para SSPs com que um editor pode trabalhar para especificar as configurações de leilão de componentes pela API Google Publisher Tag (GPT). Confira mais detalhes neste link. Se uma SSP fornecer uma configuração de leilão de componentes por meio dessa API, ela será incluída na lista de leilões de componentes para essa oportunidade de anúncio. O GAM não impõe restrições aos leilões de componentes incluídos. Qualquer SSP que queira realizar um leilão de componentes poderá fazer isso, desde que o editor tenha permitido que ele execute o código necessário na página do editor. |
| Leilões de componentes | O GAM poderia aplicar um piso específico e não divulgado a cada lance vencedor do leilão de componentes. | Resposta do Google Ad Manager: O Ad Manager tem se concentrado na justiça do leilão há anos. Para manter um leilão justo e transparente, não aceitamos preços mínimos que se aplicam apenas a segmentos específicos de demanda. Esse é um princípio consistente no nosso produto e continuará sendo assim para os leilões da API PA. |
| Servidores de anúncios de terceiros | Os servidores de anúncios de terceiros não teriam acesso à participação do Google no leilão de nível superior, o que limitaria a capacidade de se beneficiar da demanda do SSP do Google no contexto da API PA. | Resposta fornecida pelo Google Ad Manager: no momento, o GAM oferece suporte ao teste da API PA com vários vendedores pelo GAM usando a API descrita aqui. No momento, não é possível participar do GAM como um leilão de componentes em outros leilões de nível superior. |
| (Também informado nos trimestres anteriores) Desempenho dos leilões da API PA |
Relatório de testadores de que os leilões da API PA têm alta latência. | Recebemos preocupações sobre a latência e, por isso, desenvolvemos vários recursos na API PA que permitem que as SSPs definam limites na latência do DSP e façam melhorias que podem diminuir a latência. Recentemente, atualizamos nosso guia de práticas recomendadas sobre latência, que inclui mais informações sobre como aproveitar esses recursos. Também estamos desenvolvendo novas melhorias de latência, algumas delas podem ser conferidas aqui. |
| (Também informado nos trimestres anteriores) Renderização de vídeo |
Suporte para renderização de vídeo usando a API PA e frames delimitados. | Em janeiro, publicamos uma demonstração de como o vídeo in-stream pode funcionar em um leilão de PA, com mais detalhes sobre abordagens alternativas. Também observamos que os participantes do ecossistema estão começando a propor como a renderização de vídeo funciona para os parceiros que se integram a eles, como as propostas do GAM sobre a construção de renderURL compatível com vídeo ou o processo completo de E2E. Além disso, estamos ouvindo o feedback do ecossistema sobre as mudanças que podemos fazer para aumentar a adoção, e uma dessas mudanças está detalhada no GitHub. Continuamos engajados com o ecossistema para identificar e resolver a tempo qualquer outro obstáculo à adoção que possamos encontrar. |
| (Também informada nos trimestres anteriores) Política de processamento de dados |
Qual é a política de processamento de dados para a API IGs / PA? | No design da API PA, todos os dados armazenados em IGs ou sobre quais pessoas estão em quais IGs (i) permanecem no dispositivo ou (ii) são processados nos serviços de lances e leilões (B&A, na sigla em inglês) executados em um ambiente de execução confiável (TEE). Em ambos os casos, os dados não podem ser lidos por nenhuma outra parte nem usados de nenhuma outra forma, exceto para produzir lances no leilão. Algumas melhorias de privacidade que o Chrome está explorando envolvem interação com um servidor de k-anonimato operado pelo Google. Essa interação está sendo projetada com cuidado para evitar o compartilhamento de informações sobre os usuários e para ser executada em um TEE, garantindo a paridade das informações em todo o ecossistema de anúncios. O Google se comprometeu com o CMA a projetar e implementar as propostas do Sandbox de privacidade de uma maneira que não distorça a concorrência ao auto-referenciar os negócios do Google e a considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes. Continuamos trabalhando em estreita colaboração com a CMA para garantir que nosso trabalho esteja em conformidade com essas obrigações. |
| (Também informado nos trimestres anteriores) Vida útil do IG |
Pedido para estender a vida útil de IGs de 30 para 90 dias. | Essa mudança exige uma avaliação cuidadosa, pesando os benefícios para o setor contra o impacto nos usuários do Chrome e outras partes interessadas. Estamos considerando essa solicitação e aceitamos mais feedback aqui. |
| (Também informado nos trimestres anteriores) modelingSignals |
Solicite um novo campo além dos indicadores de modelo que só podem codificar informações de exibição e clique. | Respondemos a esse feedback com uma contraproposta aqui. Estamos engajados com o setor para entender a opinião deles sobre nossa proposta e avaliamos os benefícios para o setor em relação ao impacto nos usuários do Chrome e outras partes interessadas. |
| Outros bits em reportWin() | Forneça mais bits em reportWin() do limite atual de 12 antes do 3PCD. | No momento, estamos analisando abordagens para oferecer suporte a esse caso de uso. Isso está demorando um pouco porque também estamos procurando abordagens que possam ajudar a garantir um plano de privacidade de longo prazo. |
| Design do leilão | Solicitações para um único leilão que retorna URLs de renderização com a pontuação correspondente. | Consideramos compartilhar vários renderURLs e a pontuação deles de um único leilão de PA, mas não implementamos isso devido a questões de privacidade. Entendemos o desejo de evitar a exibição do mesmo anúncio várias vezes para um usuário em uma única página e agradecemos a discussão no GitHub. |
| reportWin | registre campos arbitrários na função reportWin(). | Isso já está acontecendo durante o período de teste. Quando o Chrome encerrar o suporte a 3PCs, a versão forDebuggingOnly da API vai migrar para permitir a depuração com amostragem reduzida, especificada aqui. |
| Vendedores de componentes | Ter um mecanismo independente para contar as próprias impressões e outros eventos, sem depender apenas dos relatórios das adtechs. | Essa solicitação de recurso está na fila para mais análises. Não prevemos resolver esse problema durante o período de teste facilitado pelo Chrome. |
| Faturamento de custo por clique | Implementar o faturamento por custo por clique na API PA. | Estamos considerando esta solicitação aqui e a consideramos uma solicitação de sugestões sobre como implementá-la com a plataforma atual da API. |
| browserSignals | Adicionado incomingBidInSellerCurrency à especificação de browserSignals para o vendedor. | Estamos considerando essa solicitação e aceitamos mais feedback aqui. |
| Suporte a metadados de compra e propriedade da lógica para não DSPs | O design atual da API pode levar a uma mudança significativa nas campanhas de retargeting no nível do produto, em que elas podem precisar migrar para plataformas que funcionam como DSPs e provedores de DCO. | Estamos discutindo esse problema e gostaríamos de receber mais feedback aqui . |
| Suporte a metadados de compra e propriedade da lógica para não DSPs | Compartilhe exemplos em que o DSP não é o proprietário do IG. | Entendemos que os não participantes de lances gostariam de usar algumas funcionalidades de IGs, mas não outras. Estamos avaliando ativamente as opções para resolver esses casos de uso e agradecemos o feedback aqui. |
| Controles de tempo limite | Os editores precisam poder determinar o número de IGs que podem participar e o tempo limite de nível superior / global. | Entendemos que há um desejo de melhorar os controles de tempo limite e a visibilidade entre o vendedor de nível superior e o componente, e estamos considerando essa solicitação. |
| Tamanho de vários anúncios | Suporte da API PA para casos de uso de vários tamanhos de anúncio. | Estamos considerando essa solicitação e agradecemos o feedback do ecossistema. |
| Documentação | Existe uma lista de atributos do Instagram que estão sujeitos a k-anon? | Respondemos a essa pergunta aqui. |
| Depuração | Melhorias nos recursos de depuração da API PA. | Reconhecemos a importância de ferramentas de depuração robustas para desenvolvedores que trabalham com a API PA. Temos o compromisso de melhorar a experiência do desenvolvedor, buscando maneiras de integrar melhor as buscas de arquivos .well-known com as ferramentas de desenvolvimento. Nosso objetivo é oferecer mais visibilidade e recursos de solução de problemas no ambiente de desenvolvimento. Estamos discutindo esse problema aqui e gostaríamos de receber mais feedback. |
| Rótulos | Todos os usuários nos rótulos de tratamento do modo B têm as APIs do Sandbox de privacidade ativadas? | As atribuições de grupo do experimento do Chrome são determinadas aleatoriamente e são independentes das configurações do Chrome configuradas pelo usuário. Embora essas APIs possam estar disponíveis para usuários em grupos de tratamento específicos (por exemplo, treatment_1.*), a funcionalidade delas pode ser modificada ou desativada nas configurações do Chrome. Grupo "control_2" do modo B: a inclusão nesse grupo desativa de forma inerente as APIs relevance e measurement do Sandbox de privacidade, e essa configuração não pode ser substituída pelo usuário nas configurações do Chrome. |
| Uso do API | A chamada para reportWin() e a renderização do anúncio estão acontecendo em paralelo ou uma após a outra? | A função reportWin() é chamada diretamente após a conclusão de runAdAuction(). Ao mesmo tempo, o processo de renderização do anúncio pode começar quando o resultado do leilão é colocado em um iframe ou em um frame restrito. Depois que reportWin() terminar a execução e o anúncio começar a renderizar, os URLs fornecidos para sendReportTo() serão buscados. |
| (Também informado nos trimestres anteriores) Suporte ao Teste A/B |
Solicitar suporte para testes A/B da API PA. | Estamos discutindo essa solicitação aqui e agradecemos seu feedback. |
| Ajuste da programação | A proposta do Google para gerenciar a tomada de decisão necessária pelo servidor KV não é útil, já que os vendedores não conseguem interagir com o back-end, o que dificulta a modelagem do tráfego. | Como discutido no problema do GitHub, a exposição de se uma DSP individual tem IGs presentes pode ter problemas de impressão digital do usuário. Sugerimos outras alternativas para o problema e estamos abertos a outras sugestões. |
| Ajuste da programação | Os mecanismos de armazenamento em cache adicionam uma camada significativa de complexidade e impedem que as DSPs saibam a forma real do tráfego em que vão dar lances. | O mecanismo de armazenamento em cache foi oferecido apenas como uma sugestão. As AdTechs podem escolher usar as sugestões que atendem ao caso de uso delas. Confira mais informações. |
| Rótulos | O Chrome precisa compartilhar o rótulo como um parâmetro nas solicitações para os servidores confiáveis do comprador e do vendedor. | Essa parece ser uma solicitação razoável, porque está alinhada com o objetivo de usar dados de IG de forma responsável. No entanto, estamos considerando a solicitação, sujeita a análise interna, e vamos divulgar atualizações públicas sobre o assunto à medida que as discussões avançarem. |
| Uso do API | A definição explícita do grupo "control_1" foi esclarecida no documento "Outras orientações da CMA para terceiros sobre testes". Especificamente, há preocupação de que uma mudança na redação possa ser interpretada erroneamente como exigindo a exclusão de todas as APIs do Sandbox de privacidade do control_1. | Expressamos nossas opiniões sobre isso em esta conversa do GitHub. No entanto, não podemos falar em nome da CMA e sugerimos que você entre em contato diretamente com ela para resolver qualquer problema relacionado à interpretação das orientações de teste. |
| Uso do API | O Chrome vai permitir que joinAdInterestGroup() seja chamado em uma página em branco enquanto redireciona para outro recurso? | Se um usuário estiver visitando um site, o proprietário do site poderá delegar a capacidade de chamar joinAdInterestGroup a terceiros. Essa delegação permite que terceiros criem IGs sem precisar adicionar nenhum tipo de redirecionamento por uma página em branco. Envie seu feedback sobre motivos específicos para criar IGs no meio de um redirecionamento em vez de usar o mecanismo de delegação pretendido. |
| Uso do API | As trocas precisam poder gravar IGs nas páginas dos editores com quem trabalham e delegar a permissão para dar lances em um determinado IG a qualquer comprador ou DSP. | Recebemos o feedback e estamos avaliando se esse pedido pode ser atendido. Queremos receber mais feedback do ecossistema. |
| Uso do API | Não há notificação de perda de depuração se ninguém vencer um leilão da API PA. | As funções reportWin e reportResult do Chrome foram criadas para gerar relatórios de vitórias no nível do evento no sistema de leilão de privacidade (PA, na sigla em inglês). Em circunstâncias em que todos os lances são rejeitados durante um leilão de PA, não é esperado que essas funções sejam invocadas, já que nenhum vencedor é determinado. Uma atualização recente do Chrome pode explicar discrepâncias em que os URLs transmitidos para forDebuggingOnly.reportAdAuctionLoss() não aparecem no painel de rede das Ferramentas do desenvolvedor. Recomendamos verificar essa funcionalidade usando um build do canal Canary ou Dev do Chrome. |
| Uso do API | O adCost retornado de generateBid pode ser negativo (ele já é arredondado estocasticamente para 2 bytes)? | AdCost é o custo do clique ou da conversão do anunciante transmitido de generateBid() para reportWin(). Esse valor pode ser nulo ou duplo. Valores negativos serão ignorados e não serão transmitidos. O valor será arredondado de forma estocástica quando transmitido. |
| Melhoria da API | É possível usar servidores de execução confiáveis e criptografados para processar a segmentação / coortes / atribuição e os leilões em vez do navegador Chrome? | Recomendamos que você conheça os componentes e as opções baseados em TEE na API PA (por exemplo, servidores KV e serviços de B&A) e os componentes baseados em TEE de relatórios de atribuição e agregação privada (por exemplo, serviço de agregação) que respondem a essa pergunta. |
| Melhoria da API | A resposta do leilão do Sandbox de privacidade pode ser uma resposta de lance (como o lance de cabeçalho) em vez de uma resposta de anúncio (como tags de anúncio)? | Esse tipo de mudança muda fundamentalmente as propriedades de privacidade da API PA, então não é algo que estamos considerando. |
| Controles do editor | Os editores podem bloquear criativos da API PA nas páginas? | O Chrome tem uma proposta de verificação de criativos em tempo real que ainda não está disponível para testes. Embora isso ainda não esteja disponível, observamos que a maioria dos SSPs criou soluções para permitir isso. |
| Uso do API | Qual é o limite de tamanho das perBuyerSignals? | Na forma clássica, o perBuyerSignals não tem limitações de tamanho no Chrome. As principais restrições são que os dados permanecem serializáveis em JSON e não causam consumo excessivo de memória. No entanto, perBuyerSignals muito grandes e complexos podem afetar negativamente a performance. Existe um método alternativo para transmitir perBuyerSignals pelo directFromSellerSignalsHeaderAdSlot. Essa abordagem transmite perBuyerSignals em um cabeçalho, sujeito a um limite de tamanho máximo de 10 KB para toda a resposta do cabeçalho. Além disso, os servidores individuais podem impor as próprias restrições ao tamanho máximo do cabeçalho. |
| Documentação | A documentação sobre a chamada registerAdBeacon dentro de generateBid precisa ser alterada. | Atualizamos esta documentação em 17 de fevereiro. |
| Uso do API | Como o reportEvent escolhe o URL de beacon certo entre várias opções registradas? | Cada leilão resulta em uma configuração separada, que, por sua vez, resulta em um mapa de relatórios separado. Os leilões individuais (e os frames resultantes) são completamente separados uns dos outros e não compartilham dados. O texto explicativo Relatórios de anúncios de frames limitados oferece mais detalhes sobre esse assunto. |
| Interface do Chrome | Adicionar um filtro na guia "Application -> "Interest groups" das Ferramentas do desenvolvedor do Chrome, permitindo filtrar por proprietário do IG (ou talvez também pelo nome do IG). | Estamos avaliando esse pedido e agradecemos o feedback do ecossistema. |
| versão headless do Chrome | Suporte à API PA no Chrome sem cabeça. | Alguns componentes da API PA estão vinculados ao Chrome, como as chamadas k-anon para os servidores do Google, que podem não funcionar no "velho" Chrome Headless. Acreditamos que isso pode ser resolvido com a "nova" versão do Chrome Headless lançada no Chrome 112. |
| Uso do API | No caso de relatórios de perda com reportAdAuctionLoss, estamos vendo "topLevelWinningBid=0" em muitos casos. Qual é a interpretação disso? | O valor de topLevelWinningBid é originado da função scoreAd() no componente do vendedor de nível superior. Esse valor desempenha um papel na determinação do resultado do leilão de nível superior. De acordo com a explicação, um valor de topLevelWinningBid igual a zero ou a qualquer número negativo significa que o anúncio correspondente não está qualificado para ganhar o leilão. Esse mecanismo pode ser usado, por exemplo, para filtrar anúncios segmentados por grupo de interesse que não superam um candidato segmentado por contexto. Embora um topLevelWinningBid com valor zero possa indicar que um leilão contextual prevaleceu, a especificação da API PA reconhece que outros fatores podem contribuir para esse resultado. |
| Teste A/B de modo | Esclarecimento sobre a seleção de tráfego e as solicitações de desativação do Modo B e do Modo A. | Os critérios de inclusão do Modo A e do Modo B são os mesmos. O objetivo é ter grupos representativos do tráfego normal do Chrome, desde que eles ofereçam suporte às APIs do Sandbox de privacidade e ao método de rotulagem. Algumas configurações de cliente não são compatíveis. Para fins do experimento, é importante comparar apenas o tráfego rotulado com outro tráfego rotulado. Os usuários no modo B têm o recurso de proteção contra rastreamento ativado e, portanto, recebem uma notificação sobre esse recurso. |
| Melhoria da API | É possível incluir "lifetimeMs" como uma propriedade direta na chamada joinAdInterestGroup ou gerenciá-la como um argumento separado? | Estamos considerando cuidadosamente o feedback da comunidade de desenvolvimento da Web sobre a funcionalidade "joinAdInterestGroup" na proposta da API PA. Um ponto-chave de discussão é o método ideal para gerenciar os tempos de vida da IG. Estamos avaliando os benefícios de um argumento separado para o parâmetro "lifetimeMs", já que ele promove flexibilidade e adaptabilidade para possíveis melhorias futuras na especificação. Estamos discutindo esse problema aqui e gostaríamos de receber mais feedback. |
| Uso do API | Possibilidade de aumento das taxas de falsos negativos no framework da API PA devido a colisões com IDs de navegador de baixa entropia. | A equipe do Chrome está ativamente envolvida no refinamento contínuo do framework da API PA. Agradecemos a discussão sobre possíveis taxas de falsos negativos decorrentes de colisões de ID do navegador. Estamos avaliando esse feedback com cuidado e vamos trabalhar para garantir que as análises atualizadas reflitam todos os fatores relevantes. Nosso compromisso é oferecer uma solução que atinja os resultados de privacidade desejados, mantendo a precisão e a confiabilidade. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Um identificador de navegador de baixa entropia é necessário para evitar que os clientes enviem solicitações de "junção" repetidamente para o mesmo objeto em um sistema de k-anonimato? | Sabemos e agradecemos a discussão em andamento sobre o uso de identificadores de navegador na implementação de sistemas de k-anonimato. Entendemos as preocupações levantadas sobre as possíveis implicações de privacidade desses identificadores. Embora nossa implementação inicial tenha usado um identificador de baixa entropia como um mecanismo antiabuso, estamos explorando ativamente técnicas alternativas, como tokens de contagem anônimos, que priorizam a privacidade do usuário e mantêm a integridade do sistema. Temos o compromisso de encontrar soluções que equilibrem o uso responsável de dados com proteções de privacidade robustas e agradecemos o diálogo contínuo com a comunidade de pesquisa. Estamos discutindo isso aqui e agradecemos seu feedback. |
| Uso do API | O AMP (Accelerated Mobile Pages) oferece suporte à API PA. | No momento, o AMP não oferece suporte nativo à API PA. Agradecemos o feedback adicional do ecossistema se o suporte do AMP for uma prioridade alta. |
| Melhoria da API | Considere remover o tipo das verificações de k-anonimato. | Estamos considerando cuidadosamente o feedback sobre a possível otimização das estruturas de solicitação de k-anonimato. Entendemos a sugestão de consolidar parâmetros e, possivelmente, unificar tipos para agilizar o processo. Nosso objetivo é garantir a eficiência e a manutenção. Por isso, estamos avaliando todas as opções enquanto continuamos desenvolvendo nossas soluções de privacidade. Estamos discutindo esse problema aqui e gostaríamos de receber mais feedback. |
| Interface do Chrome | Solicitação de mecanismo para usuários menos técnicos acessarem e gerenciarem com facilidade os IGs aos quais pertencem, incluindo possíveis controles de desativação no nível do site. | Reconhecemos a importância de oferecer ferramentas fáceis de usar para entender e gerenciar IGs. Analisamos vários métodos e descobrimos que identificar IGs pelo site em que foram adicionados oferece o melhor equilíbrio entre clareza e proteção da privacidade. No momento, o gerenciamento global de IGs está nas configurações do Chrome. Estamos sempre buscando maneiras de melhorar a experiência do usuário nessa área. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Segurança da API | A API PA é vulnerável a vazamentos de privacidade por interações de anúncios criativos, mesmo no contexto de frames restritos? | Sabemos que há o potencial de vazamento de informações por interações sofisticadas com anúncios. Estamos investigando ativamente a interação entre os frames cercados, a API PA e possíveis vetores de ataque. Mitigar os riscos de privacidade é nossa maior prioridade, e temos o compromisso de desenvolver soluções robustas que equilibrem a inovação com a proteção do usuário. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Latência | O tempo limite padrão de 50 ms para a lógica de lances do comprador é um valor realista? | Entendemos as preocupações levantadas sobre possíveis inconsistências entre a especificação e o tempo das solicitações de rede para a lógica de lances. Estamos revisando ativamente as especificações para garantir a precisão e investigando as configurações de tempo limite padrão ideais para equilibrar desempenho e viabilidade. Estamos discutindo esse problema aqui e gostaríamos de receber mais feedback. |
| Documentação | Possível vazamento de tempo na especificação em que um site pode inferir se um anúncio falhou no limite de k-anonimato e possíveis implicações para o rastreamento entre sites. | Identificamos o problema relacionado a um possível vazamento de tempo. Confirmamos uma discrepância na especificação e estamos tomando medidas para garantir que o status de k-anonimato dos anúncios seja determinado antes do leilão para evitar esses vazamentos. Levamos essas preocupações a sério e vamos atualizar a especificação para refletir essas mudanças. Estamos discutindo esse problema aqui e gostaríamos de receber mais feedback. |
| Uso do API | Maneiras de implementar uma lista de bloqueio do SSP na API PA. | Reconhecemos a necessidade de mecanismos para gerenciar restrições de anúncios por SSPs. Recomendamos que você use soluções que priorizam a avaliação no dispositivo e aproveitem os metadados de anúncios atuais para proteger a privacidade do usuário e permitir flexibilidade. Estamos comprometidos em trabalhar com os desenvolvedores para identificar as abordagens ideais na API PA. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Alguém pode dizer ao navegador para fingir que está usando a API PA de uma maneira que os sites não consigam detectar? | Sabemos que, na forma atual, a desativação da API PA pode ser detectada por sites. Estamos trabalhando ativamente em recursos como lances adicionais e segmentação negativa, além da renderização de frames delimitados, para melhorar a privacidade e oferecer opções de desativação não detectáveis. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Teste A/B de modo | Tráfego de data center que se passa por tratamento 1.1. | A equipe do Chrome confirmou com a equipe do GAM que esse tráfego está sendo filtrado do experimento. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Eficiência e imparcialidade da implementação de interestGroupBuyers na API PA. | Sabemos que há uma discussão em andamento sobre a eficiência e a justiça do campo "interestGroupBuyers" nos leilões da API PA. Sabemos que há um equilíbrio entre eficiência, privacidade e justiça do mercado. Embora os vendedores precisem gerenciar relacionamentos comerciais com os compradores, estamos buscando maneiras de otimizar o processo de correspondência. Isso pode incluir ajustes dinâmicos com base em dados em tempo real e modelos híbridos. Continuamos comprometidos em encontrar soluções que priorizem a privacidade do usuário e apoiem um ecossistema de publicidade competitivo. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Interface do Chrome | Possíveis problemas de memória e clareza da interface relacionados ao Instagram no Chrome. | Entendemos as preocupações sobre a exibição de IGs no DevTools. Embora a visualização atual reflita todos os eventos de IG para acompanhamento histórico, reconhecemos o valor de fornecer uma visibilidade mais clara do estado atual dos IGs armazenados. Vamos analisar as otimizações e possíveis melhorias na interface para melhorar os insights dos desenvolvedores. Em relação ao gerenciamento de memória, a implementação do IG foi projetada para evitar vazamentos de memória, mas monitoramos e otimizamos continuamente o uso de recursos. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Documentação | O autor original está encontrando um erro ao tentar usar tamanhos de anúncio nomeados diretamente no campo "sizeGroup" da função "joinAdInterestGroup". Ele quer saber se esse é o comportamento esperado. | Reconhecemos o valor da simplificação da configuração de anúncios na função "joinAdInterestGroup". Estamos trabalhando para resolver essa limitação e planejamos ativar essa funcionalidade em atualizações futuras. Essa melhoria está alinhada ao nosso compromisso de oferecer aos desenvolvedores ferramentas flexíveis e eficientes para gerenciamento de anúncios. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Rótulo de teste facilitado pelo Chrome | Solicitar dados diretos sobre o modo A em comparação com o B e rótulos exatos em sendReportTo para que possamos acompanhar o experimento de forma consistente. | Estamos discutindo essa solicitação aqui e agradecemos seu feedback. |
| Documentação | O nome de domínio do vendedor está incluído nas solicitações feitas ao servidor confiável do vendedor para fins de validação? | Confirmamos a omissão inicial do parâmetro de nome de host da documentação da API Protected Audience Server KV. Queremos garantir aos desenvolvedores que o nome de domínio do vendedor seja incluído automaticamente nas solicitações para o servidor confiável do vendedor. Essa funcionalidade é essencial para processos robustos de validação de anúncios. Atualizamos a documentação para corrigir essa omissão e continuaremos priorizando a clareza e a transparência para a comunidade de desenvolvedores. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Métodos possíveis para incluir o nome do Instagram nas chamadas de rastreamento de impressões de anúncios para fins de geração de relatórios. | Temos o compromisso de equilibrar a necessidade de mecanismos de relatórios robustos com o princípio fundamental da privacidade do usuário. A inclusão de nomes do Instagram no acompanhamento de impressões de anúncios está sujeita a proteções de k-anonimato criadas para evitar a identificação de indivíduos. Vamos continuar buscando soluções inovadoras de geração de relatórios dentro dessas restrições de privacidade. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Recurso da API | Solicitar que o servidor confiável do comprador receba cabeçalhos HTTP de dicas do cliente. | Estamos acompanhando essa solicitação de recurso aqui. |
| Uso do API | Se o arquivo de delegação precisa carregar o cabeçalho "Access-Control-Allow-Origin", já que ele determina o comportamento de associação do IG para o navegador. | Temos o compromisso de nos alinharmos às práticas recomendadas de segurança na Web. O requisito do cabeçalho "Access-Control-Allow-Origin" para arquivos de delegação garante a consistência com os princípios do CORS e evita a exposição não intencional de informações sensíveis. Estamos buscando maneiras de otimizar esse processo e manter uma postura de segurança forte. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Permitir que os servidores de anúncios personalizem criativos no framework da API PA. | Sabemos que os servidores de anúncios podem desempenhar um papel na personalização de criativos. Estamos avaliando ativamente soluções para oferecer suporte a servidores de anúncios na API PA, como o modelo "IG conjunto", em que os lances e a lógica de seleção de criativos de anúncios podem ser combinados. Nosso objetivo é encontrar um equilíbrio entre ativar recursos robustos de criativos de anúncios e proteger a privacidade do usuário. Agradecemos a colaboração e o feedback para aprimorar a API e atender às necessidades de todas as partes interessadas neste link. |
| Preocupações com privacidade | Disponibilidade de identificadores alternativos (por exemplo, O uso de RampID, ID5 e outros identificadores em solicitações de lances contextuais pode prejudicar as metas de privacidade da API PA, facilitando a coleta de dados em vários sites. | Entendemos a possível tensão entre os identificadores entre sites e os objetivos de privacidade da API PA. Embora os editores possam compartilhar esses identificadores, o objetivo do design da API PA é separar a seleção de anúncios da necessidade de acompanhamento entre sites. Temos o compromisso de promover um ecossistema de publicidade com foco na privacidade e incentivamos os desenvolvedores a priorizar a abordagem da API PA. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Armazenamento em cache | É possível impedir a reutilização de scripts de lances em vários leilões? | Confirmamos o comportamento de armazenamento em cache observado dos scripts de lances no framework da API PA. Embora os mecanismos de cache HTTP padrão sejam compatíveis, a reutilização de scripts em leilões é possível devido ao comportamento de suspensão do dispositivo e ao design dos executores de lances. A equipe está investigando soluções para dar aos compradores mais controle sobre o armazenamento em cache de script e gerenciar as estratégias de lances de maneira eficaz. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Centralize os relatórios de atividades de lances em todas as IGs de uma DSP, respeitando a privacidade do usuário. | Priorizamos a privacidade do usuário ao projetar a API PA. Embora não seja possível fazer o envio direto de eventos de lances individuais devido aos riscos de rastreamento entre sites, oferecemos mecanismos como armazenamento compartilhado e agregação privada. Isso permite que as DSPs tenham insights agregados sobre a atividade de lances, de uma forma que preserva a privacidade do usuário. |
| Uso do API | A busca de sendReportTo() em reportResult() só acontece 94% do tempo em relação a uma busca registrada com forDebuggingOnly.reportAdAuctionWin(). | Embora eles não tenham o mesmo tempo, é possível que os dois URLs sejam buscados ao mesmo tempo. Em alguns casos, o worklet do vendedor do componente foi descartado e precisa ser recarregado para executar a função reportResult(). No entanto, nem o tempo necessário para buscar a lógica de pontuação nem o tempo para recarregar o worklet afetam o tempo limite de 50 ms para reportResult(). O Chrome vai usar cabeçalhos de armazenamento em cache para definir o comportamento de busca nos casos em que o worklet precisa ser recarregado. Saiba mais sobre as fases de um leilão de PA aqui. |
| K-anonimato | Solicitação de confirmação de que o nome do interestGroup não afeta o k-anonimato da veiculação de anúncios. | Para que um criativo seja considerado k-anônimo, o conjunto de URL do proprietário do IG, URL do script de lances, URL do criativo e tamanho do anúncio precisa atender ao limite especificado (k) em um período anterior (w). O status de k-anonimato é atualizado periodicamente (p). |
| Interface do Chrome | Proposta para fornecer o tipo de "visibilidade interna" que muitos frameworks MVC, ORM etc. oferecem. Por exemplo, comece com o registro simples de eventos internos selecionados em um novo painel na seção "Ferramentas do desenvolvedor" -> "App" -> "App". | Estamos discutindo a proposta aqui e agradecemos mais feedback. |
| Interface do Chrome | A participação no IG das ferramentas para desenvolvedores não mostra elementos relacionados à prioridade. | Resolvemos esse problema aqui. |
| Melhoria da API | Seria melhor permitir que o servidor de anúncios do criativo rastreasse os próprios eventos. É possível configurar uma lista de domínios de rastreamento permitidos? | Compartilhamos uma proposta aqui e aceitamos mais feedback do ecossistema. |
| Solicitação de recurso de API | A API PA pode ser ampliada para oferecer suporte a transações de mídia que não são RTB e manter casos de uso importantes, como veiculação de anúncios e DCO? | Estamos discutindo o problema aqui e agradecemos mais feedback. |
| Tempo limite do leilão do editor | Os editores precisam controlar a duração do leilão para evitar impressões perdidas, especialmente em configurações de lances de header, em que os anúncios são selecionados sequencialmente. | Entendemos a importância de dar aos editores controle granular sobre os tempos limite dos leilões de anúncios. Estamos analisando ativamente como implementar um mecanismo de tempo limite de leilão global, possivelmente no objeto "auctionConfig", considerando cuidadosamente os casos extremos. O objetivo desse recurso é otimizar as taxas de preenchimento de impressões para os editores, e vamos continuar colaborando com a comunidade para encontrar a melhor solução. Estamos discutindo o problema aqui e agradecemos mais feedback. |
| Melhoria da API | O design atual de IGs na API PA gera tamanhos de metadados grandes devido a renderURLs longos. Os testadores gostariam de uma maneira de compactar esses URLs para maior eficiência. | Sabemos que é importante otimizar o tamanho dos metadados do Instagram, principalmente para leilões de anúncios sensíveis à eficiência. Acreditamos que uma solução baseada em modelos para compactar renderURLs oferece um potencial significativo. Vamos avaliar cuidadosamente os designs de modelos propostos e garantir que todas as soluções implementadas incluam mecanismos robustos de prevenção de abuso para manter a estabilidade do navegador. A colaboração com a comunidade de padrões da Web para desenvolver a abordagem ideal, considerando essas considerações, continua sendo uma prioridade. Estamos discutindo o problema aqui e agradecemos mais feedback. |
| Uso do API | Os testadores que lidam com formatos de anúncios nativos querem otimizar o processo de leilão do Sandbox de privacidade recuperando vários resultados de anúncios em uma única chamada para reduzir a carga da rede e melhorar a velocidade de renderização do anúncio. | Entendemos as preocupações com o desempenho da renderização de anúncios nativos no Sandbox de privacidade. Temos o compromisso de encontrar um equilíbrio entre eficiência e proteções de privacidade do usuário. Embora a exibição de vários anúncios com pontuação máxima comprometa a privacidade, estamos buscando ativamente maneiras de otimizar o processo de leilão. Nosso objetivo é melhorar o suporte da API PA para formatos de anúncios nativos e investigar mecanismos alternativos para melhorar a eficiência dentro das fortes restrições de privacidade do Sandbox de privacidade. Estamos discutindo o problema aqui e agradecemos mais feedback. |
| Uso do API | Flexibilidade na forma como os lances de anúncios são pontuados e classificados no Sandbox de privacidade, principalmente para representar níveis de prioridade ou regras de marketplace privado. | Entendemos a necessidade de um controle detalhado sobre a pontuação e a classificação de anúncios no Sandbox de privacidade, principalmente em cenários de lances complexos. Reconhecemos as soluções propostas usando tuplas e funções matemáticas para alcançar a pontuação multidimensional sem sacrificar a privacidade do usuário. Embora essas abordagens possam aumentar a complexidade para os desenvolvedores, elas oferecem a expressividade necessária. Estamos comprometidos em encontrar maneiras de simplificar esses processos, possivelmente com funções auxiliares ou diretrizes, para garantir o uso ideal dos recursos do Sandbox de privacidade na lógica de leilão avançada. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| reportEvent() | Adicione um novo evento reservado (beacon automático, talvez) acionado pelo navegador quando um frame com um criativo de anúncio for inicializado. | Estamos discutindo essa solicitação aqui e agradecemos seu feedback. |
| adCost | Permitir a divisão de adCost. | Cada valor de custo é uma oportunidade de enviar uma quantidade limitada de informações fora do leilão. Permitir uma lista inteira de N desses custos seria suficiente para enviar um identificador de usuário completo, o que permitiria o acompanhamento entre sites. Estamos discutindo isso aqui e agradecemos seu feedback. |
| resolveToConfig | O resolveToConfig precisa ser herdado do nível superior e exposto em browserSignals? | Estamos discutindo essa solicitação aqui e agradecemos seu feedback. |
| Ferramentas melhores | Existe algo semelhante a chrome://topics-internals, mas para a API PA? | Não há nada exatamente igual. No entanto, há ferramentas para desenvolvedores para a API PA . |
| Rótulos | O Chrome pode usar rótulos para identificar a população de 20% de k-anon? | Estamos considerando essa solicitação e agradecemos o feedback do ecossistema. |
| Documentação | Os worklets de leilão do Sandbox de privacidade vão se tornar tipos de worklet padrão? | Devido a requisitos exclusivos de privacidade e segurança, esses worklets são significativamente diferentes dos tipos de worklet padrão do navegador. Por isso, não esperamos que eles se tornem tipos de worklet padrão na especificação HTML em breve. Nosso compromisso é melhorar os recursos para desenvolvedores com explicações claras sobre a implementação e o ambiente de execução de worklets de leilão, tornando essas informações mais acessíveis para os participantes do Sandbox de privacidade. Discutimos isso mais detalhadamente aqui. |
| Servidor de chave-valor (KV) BYOS | As partes podem aprender sobre vários IGs (do mesmo proprietário) agrupados por um usuário por meio de consultas de serviços KV em uma configuração de serviço KV BYOS. | Isso não será mais possível quando os servidores KV forem executados em TEEs, e podemos garantir que eles possam obedecer ao modelo de confiança publicado. |
| userBiddingSignals | atualize parte dos "userBiddingSignals" e mantenha outros. | Isso já é possível sem a necessidade de mudanças na API. |
| Uso do API | Implemente o limite de frequência em vários IGs no Sandbox de privacidade, usando o servidor KV ou dados "prevWinsMs" modificados. | Sabemos que há interesse em recursos avançados de limite de frequência no Sandbox de privacidade. Sabemos que as restrições atuais de compartilhamento de dados entre IGs podem apresentar desafios na implementação dessas estratégias. Embora o servidor KV ofereça um mecanismo potencial com proteções de privacidade adequadas, recomendamos que os desenvolvedores busquem soluções em um único modelo de IG. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
| Uso do API | Os vendedores de componentes (aqueles que participam de leilões imbricados no Sandbox de privacidade) precisam ter visibilidade sobre os tempos limite de leilões de nível superior para otimizar as próprias configurações e evitar atrasos desnecessários. | Reconhecemos a necessidade de melhorar a coordenação do tempo limite entre vendedores de nível superior e vendedores de componentes no Sandbox de privacidade. Estamos investigando ativamente a adição de novos mecanismos de tempo limite, incluindo um possível tempo limite para o leilão completo, e analisando maneiras de aplicar tempos limite de nível superior aos leilões de componentes. Nosso objetivo é melhorar a eficiência e a previsibilidade para todos os participantes do processo de leilão do Sandbox de privacidade. Estamos discutindo esse problema aqui e agradecemos seu feedback. |
Serviços da API Protected Audience
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Ambientes de execução confiáveis (TEEs) | É mais caro executar TEEs em nuvens públicas em vez de data centers de adtechs no local? | Nossa resposta é semelhante aos trimestres anteriores: Nosso modelo de segurança de TEE atual se beneficia das práticas de implementações de nuvem pública. Em particular, os TEEs baseados em hardware atuais não protegem contra todos os ataques físicos. Nossos provedores de nuvem pública com suporte, AWS e Google Cloud, criaram e implementaram mitigações para riscos de acesso físico, incluindo de funcionários. Confira os detalhes a seguir sobre o suporte local. As adtechs nos disseram que executar serviços em nuvem é mais caro do que data centers de adtechs locais. Não podemos avaliar essas declarações, mas adoraríamos receber mais feedback sobre os custos e continuar avaliando opções para expandir nosso suporte a TEE. |
| TEEs | Suporte a TEEs em ambientes de nuvem não públicos | Nossa resposta é semelhante à dos trimestres anteriores: Continuamos a analisar o suporte a opções além das soluções baseadas em nuvem pública, mas não temos planos atuais para oferecer suporte a TEEs locais. Nesta fase, considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações locais, acreditamos que continuar a expandir e melhorar as implantações baseadas em nuvem (por exemplo, oferecer suporte ao Google Cloud além da AWS) é o mais benéfico para o ecossistema. No entanto, agradecemos mais feedback sobre por que esse requisito é necessário e viável, considerando as restrições de privacidade e segurança. |
| Outros provedores de nuvem | Suporte a outros provedores de nuvem | Estamos sempre abertos a sugestões de outros provedores de nuvem, mas planejamos oferecer suporte ao Google Cloud e à AWS quando o 3PCD for aplicado. Consulte este texto explicativo para mais informações. |
| API B&A Services | Qual é a orientação do Google para a API B&A Services? A prioridade será acima ou abaixo da API Protected Audience do navegador Chrome nos leilões de dispositivos? | Nossa resposta é semelhante aos trimestres anteriores: Continuamos comprometidos com o design atual de lances no dispositivo da API Protected Audience. Os serviços de B&A foram propostos para explorar possíveis soluções que ofereçam suporte a um subconjunto de casos de uso em que a capacidade computacional ou a velocidade de rede do dispositivo possa ser limitada. |
| Padronização | Os serviços de B&A não passaram por um processo de padronização. | A proposta de serviços de B&A está no meio de uma fase do processo de padronização, e agradecemos o envolvimento adicional para apoiar essa meta. Ela começou com uma proposta (com base em propostas anteriores), está sendo incubada publicamente por meio de uma extensa discussão aberta no W3C, e os desenvolvedores interessados podem começar a testá-la e enviar feedback. Esse é o padrão usual para o desenvolvimento de recursos da Web, conforme descrito, por exemplo, na nossa postagem do blog neste link. |
| Servidor KV | Exposição do URL completo ao servidor KV do comprador para segmentação por conteúdo / contexto / site. | Estamos discutindo essa solicitação aqui e agradecemos o feedback do ecossistema. |
| Documentação | A documentação de "Componentes confiáveis/forçados x opcionais" no GitHub causa confusão em algumas adtechs que têm seu próprio conjunto de imagens de implantação e infraestrutura. | Queremos melhorar a documentação sobre "Componentes confiáveis/forçados x opcionais" e gostaria de saber do ecossistema se esse trabalho precisa ser priorizado. |
| Melhoria da API | O código de status HTTP de uma chamada do servidor KV também precisa estar disponível para a função scoreAd() como um parâmetro. | Estamos avaliando esse pedido e agradecemos o feedback do ecossistema. |
| Documentação | Fornecer mais informações sobre como os workloads de JS e WASM seriam processados exatamente com a execução de UDF. | Estamos analisando a possibilidade de fornecer essas informações e agradecemos o feedback aqui. |
| Documentação | Pedido para atualizar o nome do repositório. | Renomeamos o repositório para "protected-auction-key-value-service". Isso está de acordo com o termo da coleção de serviços a que ele pertence, que também tem outros repositórios, como a discussão sobre os serviços da Protected Audience e os repositórios da documentação sobre os serviços do Protected Auction. |
| Documentação | Removemos a referência à API Cloud Debugger em bidding_auction_services_gcp_guide.md. | Atualizamos a documentação e removemos a referência. |
| Uso do API | A latência introduzida pela pesquisa KV está demorando mais de 50 ms. O processo leva quase 100 ms. Você tem alguma orientação sobre o que tem funcionado bem para outros vendedores? Você tem alguma sugestão sobre como medir os tempos limite e o tempo? |
A chamada do servidor KV acontece no contexto dos executores de script, ou seja, no ambiente protegido especial do navegador Chrome. O objetivo é proteger as informações nesses script runners contra qualquer acesso que não seja de API. Confira uma explicação detalhada neste link. |
| Uso do API | Há um tempo limite para o servidor KV responder em um determinado período? | Os vendedores podem especificar o campo "perBuyerCumulativeTimeouts" na configuração do leilão. Esse tempo limite inclui o tempo necessário para buscar indicadores de lance confiáveis. |
| Latência | Como a equipe do Sandbox de privacidade está trabalhando para resolver a latência? | Para conferir as estratégias que estamos analisando para manter a latência dentro dos limites aceitáveis, consulte este link. |
Como medir anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Otimização manual da campanha | A ARA não é compatível com a otimização manual de campanhas. | Discutimos esse cenário com a adtech e mostramos como o ARA pode ser usado para otimizar campanhas manuais. A ARA foi criada de uma forma que permite a personalização e a flexibilidade da adtech para resolver uma variedade de casos de uso. Algumas sugestões incluíam o uso de diferentes configurações flexíveis no nível do evento e relatórios de eventos com relatórios de resumo para reduzir o impacto do ruído e atender às necessidades de otimização manual e automática. Estamos abertos a mais feedback do ecossistema sobre a personalização e a flexibilidade das configurações da ARA. |
| Tipo de conversão | O Google só permite oito tipos de conversão, o que é limitado. | Implementamos a maioria dos relatórios flexíveis de eventos, que oferece às adtechs mais flexibilidade em relação ao número de janelas de relatórios, de relatórios de atribuição e de bits de dados de acionador que podem ser usados. As adtechs podem escolher uma configuração que permite medir até 32 tipos de conversão diferentes. |
| Limite de eventos de relatório agregável | O mínimo numérico de 20 eventos de conversão por relatório agregável não é viável para anunciantes menores com orçamento limitado. | Não há um número mínimo de eventos de conversão necessários por relatório agregável. Além disso, há várias decisões de design que podem ser tomadas para otimizar relatórios agregáveis para anunciantes menores, como alterar a estrutura / dimensões principais acompanhadas, testar diferentes níveis de epsilon, testar frequências de lote mais longas e testar diferentes alocações de orçamento de contribuição entre as metas de medição. As adtechs menores também podem experimentar a combinação de relatórios de nível de evento e relatórios de resumo como uma forma de reduzir o impacto do ruído. |
| Dados em tempo real | A privação de dados em tempo real (por exemplo, sobre cliques, sessões e conversões) que as DSPs usam para adaptar a estratégia de lances e melhorar a eficácia da campanha vai contra o compromisso de manter as funcionalidades atuais. | Mesmo com a ARA, os cliques e as sessões permanecem em tempo real, e as conversões são sempre posteriores, mesmo com 3PCs. |
| Campos ausentes | Requisitos ausentes no lançamento do evento totalmente flexível: i) campo "Currency" e ii) campo "orderID / TransactionID". | Não planejamos oferecer suporte a um campo de moeda ou ID do pedido / ID da transação no nível do evento flexível completo, porque já existem maneiras de fazer isso com os relatórios atuais. Estamos abertos a mais feedback sobre esses campos e vamos reconsiderar se houver outros casos de uso que exijam isso. As maneiras de usar o design atual do ARA para medir informações de tipo de moeda e ID do pedido: 1. Com base no feedback, a moeda é determinada pela localização geográfica do usuário, que pode ser adicionada como parte do source_event_id como uma forma de determinar qual moeda foi usada. 2. Com base no feedback, o campo do ID do pedido é necessário para garantir que as conversões e os valores não sejam contados duas vezes por engano. Isso pode ser feito usando chaves de eliminação de duplicação. |
| proposta de orçamento de privacidade | O Orçamento de privacidade do ARA limita a capacidade de medição em várias dimensões | A ARA foi projetada para permitir que as adtechs personalizem as próprias configurações de ARA para abranger vários cenários de atribuição. Com o design atual da ARA, as adtechs precisam pensar na troca entre as dimensões mais importantes para medir e o impacto do ruído nos dados. Adicionar ruído aos dados, dependendo da granularidade das dimensões que estão sendo medidas, é essencial para a privacidade. Estamos abertos a mais feedback do ecossistema sobre a capacidade de medir em diferentes dimensões, mas precisamos entender os casos de uso específicos que exigem isso. |
| Atualizar especificação | Embora o Google tenha dito que mudou de janelas fixas para janelas flexíveis de relatórios de eventos, isso não foi refletido nas especificações técnicas do Google, que ainda têm uma janela mínima de uma hora. | Atualmente, os relatórios flexíveis no nível do evento permitem que as adtechs mudem o número de relatórios de atribuição por evento de origem, os bits de dados do acionador e o número/comprimento das janelas de relatórios. O ARA ainda tem uma janela mínima de 1 hora para relatórios no nível do evento, o que é essencial para manter a privacidade e mitigar certos tipos de ataques de reconstrução de histórico. Como os relatórios de resumo fornecem informações agregadas, as adtechs podem ativar o recebimento de relatórios agregáveis imediatamente, sem atraso, se necessário para os casos de uso. |
| Design de API | A preocupação de que reduzir as informações nos relatórios de conversão e adicionar ruídos possa afetar o ecossistema mais do que o Google. | O Google se comprometeu com o CMA a projetar e implementar as propostas do Sandbox de privacidade de uma maneira que não distorça a concorrência com a autoreferência do próprio negócio do Google e a considerar o impacto na concorrência na publicidade digital e nos editores e anunciantes de todos os tamanhos. |
| Correção de atribuição | A ARA não permite que o provedor de tecnologia controle e verifique a atribuição correta. | Há muitas soluções disponíveis na ARA que oferecem recursos de verificação: 1. As adtechs podem verificar se o comportamento do ARA corresponde às expectativas: – O código do lado do cliente do ARA é de código aberto. – O código do lado do servidor do ARA também é de código aberto, e os coordenadores garantem que apenas as versões permitidas do serviço de agregação possam descriptografar e processar relatórios agregáveis. 2. O Chrome forneceu às adtechs uma biblioteca de simulação para verificar o comportamento de atribuição, em que a adtech pode testar como a ARA realiza a atribuição em um ambiente simulado. 3. A ARA oferece suporte a vários indicadores de depuração que ajudam a verificar se o processamento esperado ocorreu ou não e por que. |
| (Também informado em trimestres anteriores) Ruído |
Feedback de que o nível de ruído é muito alto e está afetando a utilidade dos relatórios. | Conversamos com as adtechs sobre esse mesmo feedback e identificamos maneiras de personalizar a ARA para que ela se adeque melhor aos casos de uso, mesmo com ruídos. Temos uma documentação para desenvolvedores que contém a maioria das decisões de design e personalizações que discutimos com as adtechs. A ARA foi projetada para permitir que as adtechs personalizem as próprias configurações da ARA para abranger vários cenários de atribuição. No entanto, as adtechs precisam pensar na troca entre as dimensões mais importantes para medir e o impacto do ruído nos dados. Estamos abertos a mais feedback do ecossistema sobre o impacto do ruído e podemos oferecer mais orientações sobre as alavancas de ARA que podem ser usadas para mudar o impacto do ruído. |
| Atribuição entre domínios | Como acompanhar as atribuições que são de vários domínios? | As adtechs podem redirecionar para diferentes URLs de relatórios para resolver esse caso de uso. Estamos abertos a mais feedback do ecossistema sobre esse aspecto do design do ARA. |
| Melhoria da API | Mude regularmente o fator de escalonamento usado ao registrar a atribuição nos relatórios de resumo da ARA. | Com base na discussão no GitHub, parece que o processamento de vários fatores de escalonamento no serviço de agregação provavelmente resultará em uma quantidade maior de ruído adicionado aos relatórios de resumo em comparação com a funcionalidade atual. Estamos abertos a mais feedback sobre a necessidade de fatores de escalonamento como parte de relatórios agregáveis, mas queremos destacar a possível troca por um aumento de ruído. Também estamos avaliando se outros recursos futuros do ARA podem ajudar a resolver esse caso de uso. |
| Uso do API | Oportunidade de unificar a forma como os eventos de atribuição são compartilhados com todos os participantes, o que é benéfico para SSP, DSP etc. | Planejamos sincronizar com a adtech para entender melhor o feedback e as limitações que estão enfrentando. |
| Testar o volume de tráfego | O tráfego de teste do Modo B para todos os Chrome está estável? | A inclusão em um grupo de experimentos não é afetada pelas configurações do Chrome. |
| Documentação | Suporte ao ARA para pixels. | Publicamos informações sobre como oferecer suporte a esse caso de uso e agradecemos o feedback do ecossistema. |
| Uso do API | A ARA pode não ser atribuída à origem correta para vendedores terceirizados em plataformas de e-commerce se a conversão não for feita pelo último contato. | As empresas podem usar filtros para evitar atribuição incorreta, ou seja, para que nenhum relatório de conversão seja gerado. Também estamos trabalhando em uma proposta de filtragem pré-atribuição para ajudar com esse caso de uso. |
| Compatibilidade com navegadores | A ARA terá suporte em diferentes navegadores? | Convidamos outros navegadores a adotar as APIs do Sandbox de privacidade e a continuar dedicando tempo para discutir nossa abordagem abertamente no W3C. Declaramos explicitamente a interoperabilidade como um objetivo para o envio do ARA, e o design do ARA tem como objetivo ser independente do navegador, com valores flexíveis especificados pelo fornecedor para fornecedores com diferentes posições de privacidade. Outros navegadores estão fazendo suas próprias escolhas sobre fornecer alternativas viáveis aos identificadores entre sites que possam oferecer suporte ao ecossistema digital de conteúdo e serviços. A Microsoft Edge indicou que vai oferecer suporte a ARA. |
| Uso do API | Qual é o tipo de origem esperado para os registros de origem do ARA para registerAdBeacon/reportEvent (e beacons automáticos navigation_start/commit)? | Depende se os beacons são automáticos ou manuais:
- reservado.* eventos automáticos (ou seja, do tipo de origem de navegação). : os eventos acionados manualmente são do tipo de origem de evento. |
| Uso do API | O limite máximo de 20 relatórios agregáveis por origem significa que cada evento de origem tem 20 relatórios? O limite é global ou diário? Há um plano para aumentar o limite? | O limite de 20 relatórios agregáveis por origem é um limite global em que 20 relatórios agregáveis podem ser criados para cada origem. O limite é definido pelo navegador e não pode ser configurado. O objetivo desse limite é evitar o abuso da proteção de relatórios de atribuição reais com relatórios nulos. Discutimos isso mais detalhadamente aqui. |
| Uso do API | Suporte para e-mail marketing usando a ARA. | No momento, não há suporte direto para esse caso de uso no ARA (se você não controla o site de hospedagem de e-mail). Estamos discutindo isso aqui e agradecemos seu feedback. |
| Epsilon | Quando o valor de epsilon para a API Aggregate será determinado? | O valor atual de epsilon pode ser configurado por adtechs até um limite predefinido definido pelo Sandbox de privacidade (atualmente 64). Recomendamos testar diferentes valores de epsilon e identificar pontos de inflexão para seus próprios casos de uso e fornecer feedback. Vamos avisar as adtechs com antecedência antes de fazer qualquer mudança no intervalo de valores de epsilon. |
| Melhoria da API | Oferecer suporte a um caso de uso em que o anunciante pode inserir um identificador no campo trigger_data para fazer a correspondência com dados externos do CRM e permitir que os anunciantes verifiquem a qualidade das conversões. | Estamos discutindo a solicitação e aceitamos mais feedback aqui. |
| Uso do API | Como lidar com URLs de redirecionamento como URLs de destino. | As adtechs podem fazer o seguinte: 1. Coloque o URL final no campo de destino. 2. O campo de destino permite até três URLs, o que permite colocar vários URLs no campo. Para ambas as opções, é necessário saber o URL de destino final. Discutimos isso mais detalhadamente neste link . |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Mecanismo de descoberta de chaves | Solicitação de um mecanismo de descoberta de chave | Temos uma proposta de descoberta de chave e queremos receber feedback do ecossistema sobre ela. |
| Uso do API | Roteiro para a capacidade de observação no serviço de agregação | Estamos analisando opções para oferecer mais capacidade de observação e gostaríamos de receber feedback do ecossistema aqui. |
| Melhoria da API | Solicitação para poder solicitar relatórios novamente. | O serviço de agregação está trabalhando em uma proposta de solicitação em que as adtechs podem dividir o epsilon para cada relatório. Isso pode gerar mais ruído por consulta, mas permite que as adtechs façam novas consultas e mantenham a privacidade. |
| Melhoria da API | Gostaria de poder associar várias origens ao mesmo ID da AWS. | O serviço de agregação agora permite que vários sites sejam integrados à mesma conta de nuvem (Google Cloud ou AWS). Isso vai permitir que as adtechs usem o mesmo enclave do serviço de agregação para processar relatórios de vários sites e várias origens dos mesmos sites. |
| Uso do API | Quando os lotes agregáveis falham, não há certeza se o orçamento foi consumido ou não e se eles podem processar o lote novamente. Quando um serviço de agregação encontra um erro de orçamento para relatórios duplicados, os demais relatórios são perdidos. Como minimizar essa perda? | Em um cenário típico, se o job inteiro falhar, o orçamento não será consumido. Em casos raros em que o orçamento é consumido, as adtechs podem solicitar a recuperação do orçamento. Se a adtech encontrar falhas frequentes no job com o erro de orçamento esgotado, ela vai precisar confirmar a estratégia de agrupamento. Confira aqui as instruções sobre como fazer isso corretamente e evitar relatórios duplicados e erros. Envie seu feedback sobre recuperação de orçamento aqui. |
| Uso do API | O uso da API Private Aggregation com o acionador descrito aqui produziria um relatório agregável para cada leilão. Quais são os recursos de escalonamento do serviço de agregação? | O serviço de agregação não tem um limite máximo para o número de chaves ou relatórios em um lote, mas uma escala de 10^14 relatórios e 10^12 chaves não é aceita no momento devido à memória necessária. Nossa orientação de dimensionamento indica os intervalos que testamos e recomendamos para desempenho ideal, considerando a carga esperada e os tipos de instância de VM da nuvem compatíveis. |
| Processamento de dados | Se os dados criptografados tiverem informações pessoais, qual é o arranjo legal para fornecer dados criptografados ao serviço de agregação? Você pode garantir que o coordenador não vai acessar os dados criptografados? |
O serviço de agregação não compartilha dados criptografados / do usuário com o coordenador. O serviço de agregação usa o coordenador para o gerenciamento e a contabilidade de chaves. Confira alguns detalhes sobre o coordenador aqui. Para fins de contabilidade, o serviço de agregação só compartilha o ID compartilhado e a origem do relatório com o PBS para consumo de orçamento. Quando lançarmos um site múltiplo, vamos substituir a origem por site. O serviço de agregação é executado em um TEE, que é o único lugar em que os relatórios dos clientes podem ser descriptografados. O código executado no TEE é de código aberto e auditado por partes externas, conforme descrito aqui. |
API Private Aggregation
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Uso do API | Capacidade dos vendedores de componentes de enviar relatórios para vários servidores de agregação em um TEE. | O status atual da API Private Aggregation não oferece suporte a esse recurso. Discutimos esse problema aqui. |
| Documentação | Qual é o valor de epsilon usado nos testes do Google? | Para a API Private Aggregation, o valor ε especificado em uma consulta de serviço de agregação corresponde ao orçamento de contribuição L1 de 2^16 que é aplicado a cada 10 minutos. Há também um orçamento de contribuição L1 de 2^20 que é aplicado a cada 24 horas. Ou seja, o parâmetro de privacidade é ε em um período de 10 minutos e 16ε em um período de 24 horas (em vez de 144ε). Atualmente, o serviço de agregação oferece suporte a uma faixa de ε para testes (até 64) para permitir a experimentação com diferentes estratégias de agregação e fornecer feedback sobre a utilidade do sistema com diferentes parâmetros de privacidade para a agregação privada e outras APIs. Planejamos revisar o valor máximo permitido de epsilon ao longo do tempo, à medida que recebemos feedback dos testadores e adicionamos recursos que permitem o uso mais eficiente do orçamento de privacidade. |
Limitar o rastreamento oculto
Redução do user agent/dicas de cliente HTTP do user agent
Nenhum feedback recebido neste trimestre.
Proteção de IP (anteriormente Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| ID da resolução | O Sandbox de privacidade precisa ser mais claro ao afirmar que os IDs de resolução geralmente criados com base no IP não são sustentáveis para os anunciantes. | O Sandbox de privacidade deixou claro que nosso objetivo é reduzir o rastreamento entre sites. Nossas iniciativas públicas, que vão além dos cookies, são divulgadas em privacysandbox.com e no GitHub. Nosso objetivo é reduzir o rastreamento entre sites, inclusive o baseado em endereços IP. No entanto, cabe aos sites individuais decidir se vão ativar o rastreamento entre sites de forma proativa. Em uma era de maior escrutínio da conformidade regulatória, é prudente que as empresas entendam as práticas empregadas pelos provedores de serviços. |
| Chromecast | A Proteção por IP vai afetar o Chromecast ou outros dispositivos Chrome? | No momento, não há planos para que a Proteção de IP seja aplicada aos dispositivos Chromecast. |
| Lista de proteção de IP | A lista de terceiros identificados como possíveis usuários de endereços IP para rastreamento entre sites em toda a Web será publicada? | A lista será publicada quando estiver finalizada, conforme discutido aqui. |
Mitigação de rastreio por redirecionamento
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Isenção de logon único (SSO) | Como a mitigação de rastreamento de rejeições (BTM, na sigla em inglês) vai verificar os casos de uso de SSO para isenção? | O BTM será desativado pelas heurísticas do Chrome. Consulte o texto explicativo para mais detalhes. |
| Teste de descontinuação | A BTM está ativada para sites no teste de descontinuação do 3PC? | Não, o BTM respeita as exceções de cookies criadas pelo teste de descontinuação, conforme discutido aqui. |
proposta de orçamento de privacidade
Conforme observado no GitHub e no site para desenvolvedores,o Privacy Budget não é mais considerado como parte das propostas do Sandbox de privacidade.
Reforçar os limites de privacidade entre sites
Conjuntos de sites relacionados (antes chamados de "conjuntos próprios")
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Solicitação de recurso | O acesso automático a CHIPs e / ou particionamento de armazenamento é permitido em todo o RWS, sem a necessidade da API Storage Access nem da interação do usuário. | Estamos considerando os benefícios e a viabilidade de um recurso que possa realizar essa função. Uma consideração é uma possível lacuna na interoperabilidade entre navegadores, que o RWS aborda aproveitando a API Storage Access. Não há um equivalente atual para essa funcionalidade solicitada com suporte em outros navegadores. Recomendamos que os desenvolvedores enviem os casos de uso sobre esse problema para facilitar a discussão aqui. |
| Remoção de conjuntos não em compliance | Qual é o processo para remover conjuntos que não estão em conformidade do repositório? | Estamos trabalhando para definir um processo para isso e vamos compartilhar as atualizações assim que estiverem disponíveis. |
| Processo de restrição | Não está claro qual é o papel subjetivo do Google no processo de aplicação da RWS. | Como o RWS é um projeto contínuo e continuamos recebendo novos envios, alguns aspectos do processo e nossos critérios ainda estão sendo consolidados. Concordamos que é importante que nossas diretrizes de envio descrevam totalmente os requisitos para envio. Vamos adicionar mais detalhes às diretrizes para evitar ambiguidade e confusão. Nossa intenção é que o processo de envio seja o mais técnico possível para que possamos eliminar a participação humana e confiar totalmente nas verificações automáticas. PRs como essa exigem mais interação humana porque incluem comportamentos que não previmos, mas permitem identificar mais áreas para automação e maneiras de corrigir nossas diretrizes para evitar esses problemas no futuro. |
| Compartilhamento de dados | Solicitação de um recurso que permita aos proprietários de domínio indicar que gostariam que terceiros também compartilhassem dados do RWS, com consentimento do usuário. | A funcionalidade solicitada já está disponível em APIs como a FedCM e as APIs de acesso ao armazenamento que permitem o acesso à identidade autenticada depois que o usuário aceita uma solicitação de permissão. Agradecemos o feedback do ecossistema sobre casos de uso específicos que eles acreditam não ser possíveis. |
| Outros métodos de armazenamento | As informações salvas no armazenamento local ou de sessão também serão interpretadas como 3PCs? | O armazenamento local, o armazenamento de sessão e outras formas de armazenamento sem cookies, quando usados em contextos de terceiros, foram particionados no Chrome desde a versão 115. Confira mais detalhes nesta postagem do blog. |
| Limite de conjuntos associados | O que acontece com as organizações que enviam mais de cinco domínios, mesmo que o limite seja de cinco sites associados? | Esses conjuntos serão aceitos pelo processo do GitHub, mas o navegador (Chrome) só vai aplicar as regras de concessão automática da API Storage Access aos cinco primeiros domínios e ignorar os demais, conforme discutido aqui. |
| find_robots_txt | A verificação find_robots_txt não funciona com redirecionamentos. | Uma correção foi enviada para resolver esse problema aqui. |
| Gesto do usuário | Remover a exigência de gesto do usuário para accessStorage(). | Esse requisito foi feito com base em um design semelhante que está em vigor em todos os principais navegadores para a API requestStorageAccess. Convidamos você a enviar mais feedback e casos de uso neste problema do GitHub para ajudar a priorizar essa solicitação e permitir discussões entre navegadores. |
| Gesto do usuário | É necessário um gesto do usuário para conceder permissão de acesso ao armazenamento de terceiros após uma reinicialização do Chrome ou do SO? | Sim, mas gostaríamos de receber mais feedback do ecossistema sobre a mudança desse comportamento aqui. |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| adComponent | Falta de documentação e flexibilidade ao usar AdComponents com frames delimitados. | Vamos compartilhar mais documentação sobre esse caso de uso. Além disso, os componentes de anúncio têm suporte em frames restritos usando getNestedConfigs(), que está documentado na especificação aqui. |
| (Também informado nos trimestres anteriores) Renderizar adComponent |
Solicitação de códigos de exemplo sobre como renderizar adComponents no frame limitado. | Estamos compartilhando alguns códigos de exemplo aqui. |
| Verificação de anúncios de terceiros | O papel da verificação de anúncios de terceiros no contexto de frames restritos precisa de mais detalhes, especialmente em relação à segurança contextual/de marca. | Atualmente, os relatórios de anúncios com molduras restritas permitem que as DSPs enviem dados de impressão e de eventos de leilão para verificadores de anúncios de terceiros para verificação de brand safety pós-renderização e faturamento. |
| Anúncios expansíveis | Solicitação de suporte a anúncios expansíveis. | Se o anúncio precisar alternar entre dois tamanhos com a mesma proporção e não houver diferença funcional entre os dois (apenas o tamanho), o incorporador poderá redimensionar o frame reservado com o segundo tamanho do anúncio, e o navegador vai dimensionar o elemento do frame reservado de acordo com isso. |
| (Também informado nos trimestres anteriores) Suporte para inventário de vídeo e nativo |
Os frames delimitados são compatíveis com o inventário de vídeo e nativo? | Nossa resposta é semelhante aos trimestres anteriores: A API PA oferece suporte à renderização de vídeo usando um mecanismo que depende de iframes. No entanto, ainda não projetamos uma solução para renderização de anúncios em vídeo e nativos compatível com as cercas virtuais. Esse é um dos motivos pelos quais decidimos adiar a aplicação das cercas virtuais para 2026. Isso significa que, se um parceiro decidir aplicar os frames restritos agora, o suporte a vídeos e anúncios nativos será limitado. |
| Conselho consultivo | Solicita a criação de um conselho consultivo de fornecedores de anúncios nativos para garantir que as implementações de frames restritos sigam os padrões do setor. | Os frames delimitados não são necessários para uso na API PA antes de 2026. Com esse tempo extra, podemos continuar trabalhando com o setor para projetar e implementar o suporte a uma gama mais ampla de casos de uso essenciais. Já informamos que vamos evoluir os frames restritos antes do requisito para manter o suporte a anúncios em vídeo e nativos com a API PA. De acordo com nossos compromissos, vamos interagir e informar o CMA sobre essas mudanças e continuar a receber feedback do ecossistema antes de exigir o uso de frames restritos. Nosso modelo de engajamento do ecossistema no W3C e nas organizações de padrões de publicidade, como o IAB Tech Lab, permite que especialistas do setor de todos os tipos orientem os designs antes que eles sejam necessários. |
| (Também informada nos trimestres anteriores) Diferença de tamanho entre as plataformas |
Informa que o tamanho do conteúdo exibido no frame limitado parece diferente entre computadores e smartphones. | Esse é um problema conhecido do Chromium que estamos investigando. Envie seu feedback aqui. |
| Melhoria da API | O requisito de frames fechados foi adiado para 2025 para que os anúncios nativos sejam compatíveis com o Sandbox de privacidade? | Como mencionamos no comunicado público sobre a aplicação de molduras de cercas a partir de 2026, soubemos de um "esforço significativo para acomodar" as molduras de cercas. Certamente, um deles foi o Native, mas não foi o único fator. O objetivo era dar mais tempo para garantir que o ecossistema estivesse pronto para atender aos principais casos de uso, incluindo, mas não se limitando a, os nativos. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Desempenho | Os tempos de retorno do armazenamento compartilhado fora do worklet parecem depender da atividade no worklet. | Discutimos este resultado do teste. |
| Adoção mais ampla | O Shared Storage precisa ser um padrão do setor disponível em todos os navegadores. | Agradecemos seu feedback. O Chrome continua participando ativamente dos fóruns do W3C, incluindo o WICG, para defender a proposta, buscar feedback e impulsionar a adoção. |
| Objetos de lances | É possível ler do armazenamento compartilhado em generateBid (que já está em execução em um worklet) para aplicar a decisão de anúncio / lógica de negócios (como limite de frequência) com base em informações entre sites e selecionar um subconjunto de anúncios? | Não, é impossível ler do armazenamento compartilhado em worklets de lances. |
CHIPS
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Capacidade da partição | O comportamento foi esclarecido quando a capacidade da partição é excedida. | Quando a capacidade é atingida, os cookies mais antigos são ejetados dos cookies acessados mais recentemente para liberar memória até que o limite não seja mais ultrapassado. Os desenvolvedores vão notar o cabeçalho do cookie atualizado nas solicitações seguintes. |
| Acesso de terceiros ao iFrame | O conteúdo iFrame incorporado de terceiros que abre uma nova guia/janela para o mesmo site de terceiros precisa ter acesso aos mesmos cookies particionados que o abridor. | Estamos discutindo esse caso de uso e agradecemos o feedback do ecossistema aqui. |
| Cookies duplicados | Se houver um cookie particionado e um não particionado com o mesmo nome, qual valor de chave o navegador vai decidir enviar? | Quando há dois cookies com o mesmo nome (um particionado e outro não), ambos são recebidos. Infelizmente, não há como diferenciar um do outro. A especificação do RFC sobre isso está disponível aqui, o que explica que não se deve confiar na ordem em que os cookies são enviados. |
| Solicitação de recurso | Ative os cookies particionados de origem. | Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema aqui. |
FedCM
Nenhum feedback recebido neste trimestre.
Combater spam e fraudes
API Private State Tokens (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Visualização da Web | Os tokens de estado particular (PSTs) são mantidos em várias visualizações da Web no mesmo dispositivo móvel (perfil)? | Cada app que usa a visualização da Web terá um armazenamento local diferente, o que significa que os emissores de PST não podem emitir tokens na visualização da Web de um app e, depois, em um app separado, permitir o resgate de tokens. Isso também vale para outras formas de dados armazenados localmente em visualizações da Web, como cookies. Os PSTs ainda não estão totalmente disponíveis na WebView. Vamos enviar uma atualização sobre isso até o final do segundo trimestre. |
| Novo tipo de token | Proposta de um novo tipo de token. | Agradecemos esta proposta e a continuação da análise de aplicações e adaptações de PSTs. Esperamos saber mais sobre ela nas próximas reuniões do Grupo da comunidade de combate à fraude no segundo trimestre de 2024. |
| Identificação do usuário | Como impedir que os usuários sejam identificados com base nos PSTs específicos que eles têm? | No momento, isso é mitigado limitando as tentativas de resgate em um site a dois emissores, independentemente de haver ou não tokens disponíveis desse emissor. É necessário contar um emissor em relação ao limite, mesmo que não haja tokens disponíveis. Caso contrário, o site pode iterar por todos os emissores até encontrar uma correspondência positiva. |
| Registro | Por quanto tempo o registro será necessário para PSTs? | O registro vai continuar sendo obrigatório no futuro, conforme explicado neste link. |
| Suporte para outros navegadores Chromium | O registro de emissor do PST para outros navegadores baseados no Chromium será aceito pelo repositório de registro de emissor do Chrome? | O Chrome busca os principais compromissos e os distribui aos clientes do Chrome por um mecanismo chamado atualizador de componentes. À medida que outros navegadores adicionam suporte mais completo à API, eles precisam estabelecer um processo para receber os principais compromissos do cliente, seja por um método de atualização de componentes ou outro. Confira mais detalhes neste link. |