Relatório trimestral do terceiro trimestre de 2023 com um resumo do feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.
Como parte do compromisso com a CMA, o Google concordou em fornecer relatórios trimestrais sobre o processo de engajamento das partes interessadas para as propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos Compromissos). Esses relatórios de resumo do feedback do Sandbox de privacidade são gerados agregando o feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral de feedback, incluindo, mas não se limitando a: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe o feedback recebido do ecossistema e está explorando ativamente maneiras de integrar os aprendizados às decisões de design.
Os temas de feedback são classificados por prevalência por API. Isso é feito agregando a quantidade de feedback que a equipe do Chrome recebeu sobre um determinado tema e organizando em ordem decrescente de quantidade. Os temas de feedback mais comuns foram identificados com a revisão dos tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), o feedback direto, o GitHub e as perguntas mais frequentes que surgiram pelas equipes internas do Google e formulários públicos.
Mais especificamente, as atas de reuniões de órgãos padrão da Web foram analisadas e, para feedback direto, foram considerados os registros do Google de reuniões individuais com as partes interessadas, os e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público. Em seguida, o Google coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas que surgiam em relação a cada API.
As explicações das respostas do Chrome ao feedback foram desenvolvidas a partir de perguntas frequentes publicadas, respostas reais feitas a problemas levantados pelas partes interessadas e determinação de uma posição específica para os fins deste exercício de geração de relatórios públicos. Refletindo o foco atual do desenvolvimento e testes, as perguntas e o feedback foram recebidos principalmente em relação às APIs Topics, Protected Audience e Attribution Reporting.
Talvez os feedbacks recebidos após o fim do período do relatório atual ainda não tenham uma resposta do Chrome considerada.
Glossário de siglas
- ÍCONES
- Cookies com estado particionado independente
- DSP
- Plataforma de demanda
- FedCM
- Gerenciamento de credenciais federadas
- QPS
- Conjuntos primários
- IAB
- Interactive Advertising Bureau
- IdP
- Provedor de identidade
- IETF
- Força Tarefa de Internet Engineering
- PI
- Endereço Protocolo de Internet
- openRTB
- Lances em tempo real
- Prorrogação
- Teste de origem
- PatCG
- Grupo da comunidade de tecnologia de publicidade privada
- RP
- Parte confiável
- SSP
- Plataforma de fornecimento
- TEE
- Ambiente de execução confiável
- UA
- String do user agent
- UA-CH
- Dicas de cliente HTTP do user agent
- W3C
- World Wide Web Consortium
- WIPB
- Deficiência de IP intencional
Feedback geral, sem API ou tecnologia específica
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Prontidão do ecossistema | As SSPs destacaram a preocupação de os editores não estarem prontos e não fazerem o trabalho de implantação necessário. | O foco do Sandbox de privacidade foi educar os editores, incluindo webinars e reuniões dedicados a esses editores e SSPs para impulsionar o trabalho de implantação. |
| Descontinuação de cookies de terceiros | As preocupações com a descontinuação dos cookies de terceiros (3PCD) aumentaram no quarto trimestre de 2023 devido à desativação da tecnologia do setor. | O cronograma do Sandbox de privacidade foi discutido com a CMA, com o sequenciamento levando para o segundo semestre de 2024. O Sandbox de privacidade vai publicar informações mais detalhadas sobre o sequenciamento da prorrogação do 3PCD. De acordo com os compromissos, a 3PCD está sujeita às questões de concorrência da CMA. |
| Google Ad Manager | O Google Ad Manager se recusa a expor a superfície da API, o que dificulta o teste. | Resposta fornecida pelo Google Ad Manager:pelos motivos explicados nesta resposta do Google Ad Manager, os planos do Google Ad Manager para a integração da API Protected Audience não incluem suporte ao servidor de anúncios do editor do Google sem controle do leilão de nível superior. |
| Google Ad Manager | O Google Ad Manager tem um preço mínimo secreto que é exposto somente a SSPs do AdX ou Open Bidding. | A documentação
pública do Google Ad Manager informa que o vencedor do
leilão contextual é transmitido para a lógica de pontuação de nível superior, e não
para qualquer leilão de componentes, incluindo o AdX ou o Open Bidding. Além disso, essa documentação descreve a lógica de pontuação de nível superior: "O Ad Manager vai comparar o lance vencedor de cada leilão de componentes, incluindo o leilão de componentes do próprio Ad Manager para lances de grupos de interesse dos compradores, bem como o melhor anúncio contextual (selecionado por alocação dinâmica), e veicular o anúncio com o lance mais alto". |
| Google Ad Manager | Os produtos do Google Ads precisam estar sujeitos às mesmas regras que os produtos de publicidade de terceiros. | Os produtos do Google Ads já estão sujeitos às mesmas regras que os terceiros. |
| Teste facilitado do Chrome | Adicione marcadores para navegadores que não estão em A ou B. | Não estamos pensando em fazer isso no momento, porque nossa investigação descobriu que a adição de rótulos que não são de experimentos pode complicar as preocupações de privacidade no tráfego no modo de navegação anônima. |
| Agências de publicidade | Agências ou empresas sem JavaScript em sites podem usar as APIs do Sandbox de privacidade? | Qualquer pessoa pode chamar as APIs do Sandbox de privacidade. Se uma agência ou qualquer outra pessoa quer criar tecnologias diretamente nas APIs, As APIs do lado do cliente exigem a integração com o cliente, assim como os cookies. Muitas das APIs, como os cookies, também têm uma interface de cabeçalho HTTP. Já vimos um framework do setor de publicidade, o Prebid, que cria integrações do lado do cliente com as APIs. Outras organizações podem fazer o mesmo. |
| Soluções do lado do cliente | Por que o Google está adotando soluções do lado do cliente para o Sandbox de privacidade se um engenheiro já demonstrou preocupação com a escalonabilidade dessas soluções em 2012? | A tecnologia de melhoria da privacidade (PET, na sigla em inglês) como campo de estudo evoluiu significativamente desde 2012 e, com ela, tem aplicativos comercialmente viáveis. No centro do Sandbox de privacidade estão combinações de PETs que não eram viáveis há mais de uma década. Além disso, a capacidade de computação pessoal aumentou, assim como as expectativas dos consumidores em relação aos navegadores e às expectativas regulatórias de privacidade. |
| Machine learning | Qual é o uso planejado pelo Google do Sandbox de privacidade para fins de machine learning? | Grande parte do ecossistema de adtech usa aprendizado de máquina atualmente, e não esperamos que isso mude. O Sandbox de privacidade não impede que as empresas de tecnologia de publicidade ou qualquer outra pessoa continuem usando o aprendizado de máquina. Além disso, o Sandbox de privacidade não exige que as empresas que fazem a integração com as APIs usem machine learning. É normal que as empresas continuem criando produtos e serviços para atender às necessidades dos clientes, incluindo machine learning ou não. Todos os aprendizados de máquina que os integradores do Sandbox de privacidade criarem vão ser conhecidos por eles e, portanto, não serão ocultados por eles. |
| Verificação de dados | Como as empresas podem verificar se os dados recebidos usando o Sandbox de privacidade são precisos e se o Google está disposto a ser analisado por uma entidade como o Media Ratings Council (MRC)? | As APIs do Sandbox de privacidade são criadas na plataforma de código aberto que alimenta o Chrome. As partes das APIs destinadas à execução em ambientes de execução confiáveis também são de código aberto e auditáveis. Qualquer pessoa que queira inspecionar o código pode, inclusive o MRC. |
| Suporte de produção (informado também nos trimestres anteriores) | Qual é o processo em vigor para que o Chrome ofereça suporte a problemas técnicos e encaminhamentos que afetam o ecossistema do Sandbox de privacidade? | O Google oferece uma variedade de canais para permitir que as adtechs relatem
problemas técnicos e ativem os encaminhamentos necessários para resolver
esses problemas. Além disso, o Chrome espera criar e escalonar ainda mais um
processo para resolver problemas técnicos e encaminhamentos que afetam a
integridade do ecossistema. O Chrome está comprometido em garantir recursos
para este esforço. Consulte nossa postagem para desenvolvedores se quiser mais informações sobre os fóruns públicos e privados para feedback e encaminhamento. |
| Modos de teste facilitados do Chrome | Mais informações sobre os cronogramas e as implementações exatas dos modos de teste facilitados do Chrome. | Compartilhamos uma postagem do blog
sobre os modos de teste e estamos trabalhando para compartilhar mais informações em breve. Queremos receber sugestões sobre o tamanho dos rótulos do modo de teste. |
| Integração com outros padrões do setor | As APIs do Sandbox de privacidade vão se conectar ao TCF v2.* e ao modo de consentimento? | Não temos planos de integrar as APIs do Sandbox de privacidade diretamente com o TCF v2 ou o modo de consentimento. No entanto, empresas e grupos comerciais do setor podem adaptar os próprios produtos e frameworks para trabalhar em conjunto com as APIs do Sandbox de privacidade. Por exemplo, com frameworks como o TCF, cada participante precisa determinar a própria abordagem de compliance com base no indicador do TCF que recebe e nas políticas do TCF associadas. Esperamos que as empresas determinem quando e como usar várias funcionalidades que os elementos básicos do Sandbox de privacidade oferecem. |
Registro e atestado
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Restrição | Com o processo de registro, o Google pode decidir qual empresa do ecossistema tem permissão para usar as APIs do Sandbox de privacidade. | O processo de registro e atestado envolve essencialmente a verificação da entidade (por exemplo, se a entidade tem um número DUNs, pode fornecer um link para uma Política de Privacidade etc.) e torna o atestado público um requisito para chamar as APIs. As entidades que puderem atender aos requisitos de registro serão validadas. Para as empresas que não têm um DUNs, estamos oferecendo um processo rápido e sem custo financeiro com a Dun & Bradstreet para a aquisição de um. O objetivo é melhorar as proteções de privacidade das APIs (pelas medidas mencionadas) e adicionar uma camada de transparência às APIs do Sandbox de privacidade para que as partes interessadas possam entender melhor quem está usando qual API e quais atestados estão fazendo. Estamos abertos a mais feedback do setor sobre esse problema, que já foi usado para moldar o processo. |
| Sobrecarga no novo registro | O arquivo de atestado expira a cada 12 meses e exige que os sites se inscrevam novamente. | Recebemos feedback do ecossistema e ajustamos nossa abordagem de acordo. Isso significa que os arquivos não expiram depois de 12 meses ou de qualquer período definido. Estamos atualizando nosso guia de inscrição para desenvolvedores com mais contexto. |
| Arquivo de atestado | Como o arquivo de atestado é usado? | Até o prazo de aplicação, todas as empresas que chamam APIs de relevância e medição precisarão fazer upload do arquivo de atestado no site delas e mantê-lo para visualização pública, desde que você pretenda
continuar chamando as APIs. Os sites podem esperar aproximadamente uma solicitação por hora do Sandbox de privacidade, e outras entidades em potencial também podem fazer consultas. Isso será realizado por meio do próprio mecanismo do sistema de registro para consultar os servidores das entidades registradas e garantir que o arquivo de atestado seja válido. Os atestados serão incluídos nos relatórios de transparência e ficarão visíveis para o público em geral. Esperamos que as empresas ajam de acordo com suas certificações declaradas, assim como o restante do ecossistema e os órgãos reguladores relevantes. |
| Inscrição | A inscrição é por site ou origem? | A inscrição é no nível do site. |
Mostre conteúdo e anúncios relevantes
Tópicos
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Desempenho | Preocupações de performance sobre o impacto da taxa de ativação da API Topics no Espaço Econômico Europeu. | Sugerimos que as partes interessadas preocupadas entrem em contato com a autoridade de proteção de dados relevante sobre esse problema. Elas são as melhores para lidar com essas preocupações e influenciar se as aplicações de tecnologias que aumentam a privacidade são incentivadas por leis ou tratadas como rastreamento, exigindo as mesmas abordagens para o consentimento. Isso pode fazer com que APIs como as do Sandbox de privacidade não fiquem disponíveis com tanta frequência. |
| Inscrição | Os bidders downstream precisam se inscrever na API Topics para usar indicadores da API Topics de SSPs upstream? | Os receptores downstream de temas além do autor da chamada inicial da API Topics não precisam ser registrados, embora muitos deles provavelmente estejam registrados para outro uso da API. Uma lista de participantes do Sandbox de privacidade vai ser fornecida de forma programática como parte dos esforços de transparência do programa. Isso permite que um autor da chamada da API Topics verifique se o destinatário para quem está enviando um tema está registrado, se o autor da chamada quiser. |
| Filtragem de tópicos | Solicite a aplicação da filtragem de outro autor da chamada aos temas que ele recupera na página, a fim de compartilhar apenas o que os compradores estão qualificados para recuperar. | Estamos analisando essa solicitação. Queremos receber mais feedback do ecossistema. |
| Exclusão de sites | Impeça que sites contribuam para os tópicos de um usuário. | Os tópicos não são chamados por padrão. É importante observar que nenhum conteúdo
da página é considerado quando os temas são selecionados, e todos
os temas são selecionados para garantir que não sejam sensíveis. Um site também pode
impedir que ele seja incluído no cálculo de temas usando
este cabeçalho de política de permissões: Permissions-Policy:
browsing-topics=(). |
| Observação de temas | Permita que os editores concedam permissões para que o Chrome classifique temas com base no conteúdo da página (por exemplo, cabeçalho ou corpo). | Anteriormente, pensamos em oferecer uma funcionalidade para classificar sites em tópicos com base no conteúdo da página e tomamos a decisão de não avançar com base em questões de privacidade e segurança. Esta proposta pode mitigar algumas dessas preocupações, mas não está claro até que ponto. Devido ao próximo período de experimento do CMA, não esperamos que essa mudança ocorra antes da 3PCD. Seu feedback é bem-vindo aqui. |
| Observação de temas | Fornecer políticas de permissão mais detalhadas para os editores. | A disponibilização de políticas de permissão mais refinadas para editores permitiria que os sites para editores prejudicassem a utilidade da API Topics para o ecossistema como um todo, sem afetar negativamente a utilidade da API Topics para o próprio site. Consulte a política de atualizações de permissões para oferecer suporte a permissões separadas para recuperação e observação do problema do GitHub para uma discussão mais detalhada sobre o assunto. |
| Tópicos médicos e de saúde | Por que a taxonomia da Topics não aborda temas nas categorias "Médica" ou "Saúde"? | As categorias médicas e de saúde são consideradas temas sensíveis e, portanto, excluídas da taxonomia da API Topics. |
| Recuperação de temas | A maneira mais rápida de as DSPs acessarem temas sem fazer buscas usando cabeçalhos. | Os métodos de cabeçalho são mais eficientes e baratos do que a criação
de um iframe de origem cruzada e uma chamada document.browsingTopics()
a partir dele. Um iframe de origem cruzada precisa ser usado para a chamada, porque
o contexto de nível superior para observar um tópico precisa corresponder ao contexto
em que os temas são acessados. Isso foi discutido em detalhes aqui. |
| Recuperação de temas | Solicitações para oferecer suporte à transmissão de temas por cabeçalhos em solicitações de tags de script de origem cruzada. | Do ponto de vista da segurança, isso não é possível. Cada documento e
seu ambiente de execução estão associados a uma única origem:
a do documento. Os subrecursos de terceiros carregados e executados
nesse mesmo ambiente são considerados de propriedade da origem do
documento. Isso evita o vazamento de dados sem consentimento de uma origem para outra. Uma alternativa é fornecer um atributo browsingTopics nas tags
<script>. Isso precisa ser limpo do ponto de vista da segurança e não pode aumentar a latência. Gostaríamos de receber
feedback das partes interessadas. |
| Reconhecimento | Melhore o reconhecimento público da API Topics e como ela vai ser usada. | Entramos em contato com a parte interessada que forneceu esse feedback e
o problema foi resolvido no GitHub.
A partir de agora, vamos continuar oferecendo suporte ao entendimento do ecossistema da API e esperamos receber as opiniões das partes interessadas. Enquanto isso, sugerimos que as partes interessadas que queiram saber mais sobre a API Topics se familiarizem com a documentação do Guia do desenvolvedor do Chrome. |
| Notificação | Notificação para alertar o usuário quando os temas dele estiverem sendo observados por um site. | Respondemos a esse feedback no GitHub (link em inglês). Os usuários podem saber mais sobre os controles da API Topics na Central de Ajuda do Chrome. |
| Machine learning | Como o ML pode ser usado para inferir temas dos usuários? | Estamos discutindo esse problema e envie seu feedback. |
| Utilidade para diferentes tipos de partes interessadas | Empresas de tecnologia de publicidade menores podem não conseguir observar as temas devido à forma como os navegadores os calculam. | Somente as adtechs que observarem o usuário acessar uma página sobre o tema
em questão nas últimas três semanas vão receber um tema. Se a adtech
não chamou a API nas três semanas anteriores para esse usuário
em um site sobre esse tema, o valor retornado vai estar
vazio. Esse recurso significa que as adtechs que oferecem serviços para um número maior de proprietários e, portanto, têm mais oportunidades de observar a visita de um determinado usuário ao site, podem receber mais temas do que outras adtechs. Esse recurso é essencial para as proteções de privacidade da API, porque limita a disponibilidade de informações sobre um usuário apenas às partes que já podem observar as mesmas informações subjacentes (atualmente por cookies de terceiros). |
| Solicitação XHR | Quando a inclusão da API Topics em solicitações XMLHttpRequest (XHR) vai ser
descontinuada? |
Como o Chrome anunciou
em agosto de 2023, começou a descontinuar o suporte ao XHR durante
a transição do teste de origem para a disponibilidade geral. Com a evolução da API Topics, o suporte a XHR só foi incluído para usuários com recursos de OT ativado e foi totalmente descontinuado quando os grupos individuais de experimento de OT foram integrados. Se você usava Topics com XHR, os sites não apresentarão falhas. Os tópicos não serão adicionados aos cabeçalhos da solicitação XHR. Recomendamos que você faça a transição para fetch da sua solicitação, use o atributo
iframe ou a API JavaScript para recuperar temas. A busca é compatível com todos os navegadores modernos, mas não com o Internet Explorer nem com o Opera
Mini. |
| Processo de atualização de taxonomia e classificador | Mais informações sobre a cadência de lançamento da taxonomia e do classificador da API Topics e como as empresas podem se preparar para essas atualizações. | Nossa resposta permanece inalterada em relação ao 2o trimestre: Conforme informado na postagem recente do blog, esperamos que a taxonomia evolua com o tempo e que, para a governança dela, eventualmente faça a transição para uma parte externa que representa as partes interessadas de todo o setor. Também compartilhamos o plano de ampliação no grupotopics-announce. |
| Abuso | Possível ataque pela cadeia de redirecionamento. | Estamos considerando esse problema e agradecemos seu feedback. |
| Tipos de inventário do editor | Quais tipos de inventário do editor vão ser compatíveis com os testes de API Protected Audience e Topics? | Nem a API Protected Audience nem a API Topics são restritivas em termos dos tipos de inventário em que podem ser usados. |
| Tempo de otimização | Não é recomendável que as novas taxonomias cheguem a 100%. | Após esse pedido de feedback do ecossistema e da discussão durante as reuniões da PATCG, anunciamos nosso plano para o lançamento da nova taxonomia. |
API Protected Audience (antiga FLEDGE)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Leilões de alto nível | Capacidade de usar o servidor de anúncios do editor do Google sem também dar ao Google Ad Manager o controle do leilão de nível superior da API Protected Audience. | Resposta fornecida pelo Google Ad Manager: Os planos do Google Ad Manager para a API Protected Audience não incluem suporte ao servidor de anúncios do editor do Google sem o controle do leilão de nível superior da API Protected Audience pelos motivos abaixo. Para atender corretamente nossos clientes no mercado de veiculação de anúncios do editor, o servidor de anúncios do editor do Google precisa manter o controle do leilão de nível superior da Protected Audience. Como servidor de anúncios do editor, nosso papel é fornecer aos editores estimativas para que eles possam negociar campanhas de venda direta sem reservas em excesso, além de definir o ritmo e a entrega de reservas diretas da maneira ideal. Para isso, é necessário gerar o leilão final para comparar toda a demanda direta e indireta qualificada. A estimativa e o ritmo são funcionalidades importantes que os editores esperam de um servidor de anúncios. Sem uma previsão precisa, os editores podem acabar vendendo demais o inventário, o que coloca a reputação da empresa em risco. O ritmo também é fundamental, já que não conseguir cumprir contratos de reserva com os anunciantes também corre o risco de prejudicar a relação direta entre editor e anunciante, o que pode causar um impacto significativo nos negócios dos editores. Dessa forma, não consideramos a atividade de um servidor de anúncios do editor na execução do leilão de público-alvo protegido de nível superior como diferente das outras atividades desse servidor. |
directFrom |
directFrompermite que o Google Ad Manager impeça o editor de ver o preço do leilão contextual. |
Resposta do Chrome: As informações transmitidas para o runAdAuction() não são provenientes do
vendedor, a menos que ele chame runAdAuction() pelo próprio iframe. Em
um leilão de vários vendedores, se torna impossível que todos os vendedores
criem o frame chamando runAdAuction(). directFromSellerSignals
solucionou esse problema carregando conteúdo de um pacote de recursos secundários
carregado da origem de um vendedor. Isso garante que a autenticidade e
a integridade das informações transmitidas para um leilão pelas
configurações dos leilões para vendedores não possam ser manipuladas. Se os editores
quiserem usar a API Protected Audience para entender as
informações que os provedores de tecnologia transmitem aos leilões da
API Protected Audience, eles podem solicitar essa funcionalidade a esses provedores.Resposta do Google Ad Manager: Mantemos nosso foco na imparcialidade do leilão por anos, incluindo nossa promessa de que nenhum preço de nenhuma das fontes de publicidade não garantidas de um editor, incluindo preços de itens de linha não garantidos, será compartilhado com outro comprador antes que ele dê um lance no leilão, que mais tarde reafirmamos em nossos compromissos com a Autoridade de Concorrência da França. Nos leilões da API Protected Audience, pretendemos cumprir nossa promessa usando directFromSellerSignals e não compartilhar o lance de um participante
com nenhum outro antes da conclusão
nos leilões com vários vendedores. Para esclarecer, não vamos compartilhar o
preço do leilão contextual com nosso próprio leilão de componentes, conforme explicado na atualização Esclarecimento adicional sobre a dinâmica do leilão de nível superior. |
| Exposição de informações | A lógica de negócios confidencial e os detalhes contratuais podem ser expostos pelo navegador. | A pessoa que usa um navegador da Web pode ver tudo o que está acontecendo no navegador. Quando um leilão de anúncios acontece no navegador, a pessoa que tem o navegador pode assistir ao leilão, incluindo ver quanto diferentes partes escolheram dar um lance. Como um navegador é o agente do usuário, não acreditamos que seja possível ou desejável tentar alterar isso. No entanto, somente a pessoa que usa o navegador tem visibilidade dessas operações. Um leilão no dispositivo realizado com a API Protected Audience não é observável para nenhum servidor, incluindo o do Google. |
PerBuyerExperiment |
O intervalo de valor atual de PerBuyerExperimentpermite que os compradores correlacionem os dados contextuais com a solicitação de servidor confiável. |
O uso da API Protected Audience dessa maneira é inconsistente com o atestado obrigatório do Sandbox de privacidade de que os usuários da API não tentarão burlar as proteções do Sandbox de privacidade. No futuro, o requisito de que os servidores de chave-valor sejam executados em ambientes de execução confiáveis (TEEs) vai fornecer proteção técnica contra esse ataque. |
| Política de mesma origem | Flexibilizar a política de mesma origem para permitir subdomínios. | Estamos considerando essa solicitação. Queremos receber mais feedback do ecossistema. |
| Criação do número de versão da API | Solicitação de controle de versões e notas de lançamento para mudanças na API Protected Audience. | Estamos considerando essa solicitação. Queremos receber mais feedback do ecossistema. |
| Leilões com várias SSPs | Permita que os indicadores de leilão de nível superior façam combinações JSON com o indicador
de componente auctionSignals. |
Estamos considerando essa solicitação. Queremos receber mais feedback do ecossistema. |
| Limite de lance | Aumente o limite do número de componentes do anúncio que inserem o lance, de 20 para 40. | Estamos considerando essa solicitação. Agradecemos qualquer feedback do ecossistema sobre por que isso seria útil. |
| (Também informado nos trimestres anteriores) Performance dos leilões de Protected Audience |
Relatório dos testadores de que os leilões da Protected Audience têm alta latência. | Em questões de latência, a API Protected Audience geralmente segue o paradigma padrão atual de criar controles que permitem aos vendedores decidir quanto tempo e recursos os bidders podem consumir e criar ferramentas que permitem aos compradores decidir a melhor forma de usar os recursos disponíveis para eles. Esses controles e ferramentas geralmente
já estão disponíveis, mas os benefícios só serão conquistados após
a adoção por compradores e vendedores. Além disso, o Chrome continua trabalhando em várias melhorias de infraestrutura para velocidade de leilão (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339 e crrev.com/1197323). Envie feedback sobre as duas metades desse esforço de latência: novas ferramentas que compradores e vendedores podem considerar úteis e relatórios de gargalos observados que os engenheiros do Chrome precisam investigar. |
| Filtragem da compra | Foi adicionado suporte à filtragem da compra com base em grupos de interesse. | Sugerimos várias maneiras de as SSPs e DSPs mudarem
os designs para lidar com isso:
|
| Controle do grupo de interesse do editor | Suporte a editores que buscam delegar o uso de grupos de interesse criados pelo editor. | Conversamos com várias partes sobre essa solicitação. Acreditamos que todos esses casos de uso envolvidos na "delegação" dos grupos de interesse criados pelo editor podem ser acomodados agora. Além disso, é preciso oferecer mais suporte para que alguns casos de uso fluam de maneira mais fluida no futuro. |
| (Também relatados no T2) Ambientes de execução confiáveis | Suporte a ambientes de execução confiáveis (TEE, na sigla em inglês) em ambientes de nuvem não públicos. | Nossa resposta é semelhante aos trimestres anteriores: Embora continuemos analisando opções de suporte para outras opções além das soluções baseadas na nuvem pública, não temos planos para oferecer suporte a TEEs no local. Neste estágio, considerando os requisitos de segurança do Sandbox de privacidade e os desafios significativos apresentados pelas implantações no local, acreditamos que continuar expandindo e melhorando as implantações baseadas em nuvem (por exemplo, oferecer suporte ao Google Cloud e à AWS) é o mais benéfico para o ecossistema. No entanto, convidamos outros feedbacks sobre por que esse requisito é necessário e viável, considerando as restrições de privacidade e segurança. |
| Ambiente de execução confiável | Os componentes no caminho de disponibilização do TEE, como o balanceador de carga, podem observar todo o tráfego e ter informações do endereço IP de cada solicitação. | No momento, o endereço IP é transmitido como um metadado nos cabeçalhos da solicitação para o serviço de anúncios do vendedor não confiável no caso de lances e leilões e leilões da Protected Audience no dispositivo. Consulte Encaminhamento de metadados para mais informações. A longo prazo, planejamos usar um proxy de adtech e rastrear o tráfego por um proxy de IP, o que vai impedir que os componentes observem todo o tráfego no caminho de veiculação. |
| Time to live (TTL) | O time to live (TTL) antes que os serviços precisem solicitar novas chaves seja definido ou se destina a ser flexível (ou dinâmico)? | Em geral, o TTL é estático. Atualmente, o TTL do público é de oito dias e a rotação acontece a cada sete dias. O TTL também é o mesmo para chaves privadas no caso do serviço de agregação. No caso dos serviços de lances e leilões, as chaves privadas e públicas são buscadas a cada N horas no caminho que não é de solicitação e armazenadas em cache na memória. Assim, não há um atraso de mais de N horas entre a rotação das chaves e os servidores que as coletam. O buffer de um dia entre a rotação e a expiração de chaves garante que os serviços continuem funcionando, mesmo que a geração da chave falhe. Estamos pensando em estender o TTL para ser mais resiliente a interrupções. Em caso de vazamento de chave, planejamos forçar manualmente a geração de chaves e invalidá-las mais cedo. Observe que as chaves públicas são armazenadas em cache nos clientes, atualmente por 24 horas, novamente para garantir que, em caso de interrupção do coordenador, os serviços ainda possam funcionar. |
| Modelagem de tráfego | Suporte à modelagem de tráfego para serviços de lances e leilões. | Os compradores podem indicar, com base em dados próprios do editor ou dados contextuais, a demanda para leilões de Protected Audience. Os vendedores também podem fazer determinações semelhantes no servidor de anúncios do vendedor ou no servidor do Ad Exchange. Os modelos podem ser treinados com dados próprios e em qualquer relatório agregado de leilões da Protected Audience. Os vendedores podem usar essas informações para evitar o envio de solicitações aos servidores de lances e leilões quando não houver demanda para leilões da API Protected Audience. Acreditamos que essa pode ser uma forma eficaz de moldar o tráfego. |
| Leilão de componentes | Quais leilãoSignals de nível superior são compartilhados com os vendedores de componentes? | Os compradores em um leilão de componentes só recebem indicadores do vendedor do componente. Em breve, vamos compartilhar a documentação sobre a sequência geral de um leilão combinado com lances de cabeçalho e o leilão da Protected Audience. |
| Renderização de vídeo | Suporte à renderização de vídeo usando Protected Audience e Fenced Frames. | A API Protected Audience oferece suporte à renderização de vídeos usando um mecanismo que depende de iframes. No entanto, ainda não projetamos uma solução compatível com o Fenced Frames, e esse é um dos motivos por que decidimos adiar a aplicação desse recurso para 2026. Isso significa que, se um parceiro decidir aplicar o Fenced Frames agora, ele não terá suporte para vídeos. |
| Limite de frequência | (Também informado nos trimestres anteriores) Controles de frequência por usuário em uma campanha e um grupo de anúncios. |
Nossa resposta não mudou em relação aos relatórios anteriores: A API Protected Audience vai oferecer suporte ao limite de frequência para leilões no dispositivo e campanhas contextuais e de marca. Limites de armazenamento compartilhado e específicos do site também podem ser usados para outros controles de limite de frequência. |
| Preferências de anúncio | A API Protected Audience oferece uma maneira de desativar ou colocar na lista de bloqueio por sites de anunciantes ou uma maneira de manter todos os grupos de interesse do mesmo proprietário? | Há várias maneiras de os usuários bloquearem o acesso à API Protected Audience e a outros recursos do Sandbox de privacidade. |
| Política de mesma origem para o URL de origem dos scripts de lances e leilões | Diminua a exigência de que todos os campos que especificam URLs para carregar scripts ou JSON tenham que ter a mesma origem do proprietário. | Estamos analisando esse pedido e recebemos mais feedback do ecossistema. |
forDebuggingOnly |
Potencial de uso indevido de forDebuggingOnly se ele
permanecer após o 3PCD. |
Nos últimos anos, recebemos feedback do ecossistema sobre lacunas de funcionalidades na Protected Audience quando os cookies de terceiros foram descontinuados, e estamos trabalhando para formular um plano de apoio após a 3PCD sem comprometer as metas do Sandbox de privacidade. Agradecemos qualquer sugestão e feedback adicionais sobre a falta de funcionalidades que o ecossistema gostaria de ver. |
| Vários grupos de interesse | Usar vários grupos de interesse no mesmo lance. | Atualmente, a API Protected Audience não oferece suporte a isso, já que resultaria em uma mudança no modelo de privacidade subjacente. Gostaríamos de receber outras discussões aqui. |
| Leilões no dispositivo | O Chrome no Android vai oferecer suporte a leilões da Protected Audience no dispositivo? | Sim, os leilões no dispositivo terão suporte no Chrome para Android. |
| Dados relacionados a cliques (no 2o trimestre de 2023) | Adicione dados relacionados a cliques ao browserSignals. | Continuamos a avaliar essa solicitação de recurso e esperamos receber mais feedback sobre por que ela deve ser priorizada. |
| Provedores do ambiente de execução confiável | Há diferenças significativas nas ofertas do ambiente de execução confiável de diferentes provedores de nuvem? | Não estamos cientes de nenhuma grande diferença, mas recomendamos que o ecossistema consulte os guias públicos de implantação para ver qual solução atende melhor às necessidades dele. Google Cloud AWS (link em inglês). |
| Informado nos trimestres anteriores Suporte à segmentação negativa de grupos de interesse |
Uma API que oferece suporte à segmentação negativa de grupos de interesse: exibir anúncios somente se um usuário não pertencer a um grupo de interesse. | Estamos analisando a implementação desse recurso e discutimos a solicitação. |
| Violação de conteúdo | Suporte a recursos que permitem aos usuários denunciar anúncios inadequados veiculados pela API Protected Audience em Fenced Frames. | Acreditamos que o mecanismo de relatórios de anúncios de frame cercados oferece boas opções para adtechs que querem um fluxo de relatórios de "Anúncios inadequados" gerado pelo usuário. Isso permitiria gerar relatórios de anúncios inadequados de maneira essencialmente inalterada em relação ao padrão do setor atual. Aceitamos solicitações de outros recursos se alguma lacuna ainda existir, inclusive durante o período após a remoção do cookie de terceiros, mas antes da renderização do Fenced Frame se espalhar. |
| Geração de relatórios da API Private agregação | Como podemos calcular o tempo que o usuário passou nesse grupo de interesse? | No Chrome M116 e versões mais recentes, é possível usar o tempo para retorno conforme definido em Pull/639. |
| Servidor K-anonimato | Mais informações sobre o servidor K-Anonimato. | Compartilhamos mais informações sobre os servidores K-Anonimato e aceitamos seu feedback. |
| URLs do criativo dinâmico | Suporte a URLs de criativos sem pré-declaração, sem deixar de respeitar o k-anonimato. | Estamos discutindo essa solicitação de recurso e aceitamos outros feedbacks sobre por que isso deve ser priorizado. |
| Requisito de K-anonimato | O requisito de k-anonimato nas atualizações do grupo de interesse vai ser incluído outra vez? | Não esperamos mudanças na posição declarada nesta postagem do GitHub. Conforme anunciado nessa postagem, decidimos remover o requisito de k-anonimato nas atualizações do grupo de interesse da Protected Audience, o que não tem um impacto significativo nas proteções gerais de privacidade da API. Planejamos considerar outras possíveis proteções mais diretas, como privacidade de endereço IP ou um servidor de atualização confiável, quando as tecnologias relacionadas forem mais desenvolvidas, implantadas e adotadas. |
| Teste Beta de serviços de lances e leilões | Quando o teste Beta dos serviços de lances e leilões vai começar? | Conforme descrito no Cronograma e no roteiro, a primeira fase de testes dos serviços de lances e leilões começa em novembro de 2023. |
| Sincronização | Solicitação de suporte à coordenação de criativos para redes de publicidade (SSP e DSP estão na mesma empresa ou propriedades). | Agradecemos o feedback sobre esse caso de uso e estamos procurando entender se mais adtechs têm interesse em ter esse suporte. Seu feedback é bem-vindo. |
| Publicidade nativa | Suporte a frame isolado para publicidade nativa. | Estamos pensando em oferecer suporte ao caso de uso e estamos discutindo possíveis soluções alternativas. |
| K-anonimato | Como maximizar os anúncios de grupos de interesse que atendem aos limites de k-anonimato? | Compartilhamos algumas orientações táticas sobre esse tópico. |
| Suporte a POST | Suporte ao envio de dados de leilão por solicitações POST. | Estamos avaliando essa solicitação de recurso e aceitamos outros envios de problemas do GitHub (link em inglês) sobre por que isso precisa ser priorizado. |
| Granularidade dos relatórios | Qual é a granularidade dos relatórios de anúncios de frame cercados com anúncios compostos de várias partes? | O design atual não permite capturar o ID ou a posição do produto, já que
isso pode comprometer a privacidade do usuário. Somente o reserved.top_navigation
pode ser invocado, que seria enviado quando houvesse uma ativação do usuário
(como um clique) no frame isolado do componente do anúncio, o que resulta em uma
navegação de nível superior. |
| Leilão de anúncios | Uma SSP que participa de um leilão de componentes pode acionar outro leilão de componentes? | Um componentSeller não pode incluir também componentAuctions.O leilão de vários vendedores tem apenas dois níveis: 1. Os leilões de componentes em paralelo. 2 Leilão de nível superior (em que o anúncio vencedor de cada componentAuction concorre). |
| Disponibilidade dos serviços de lances e leilões | Os lances e leilões estarão disponíveis durante a fase de teste facilitado do Chrome? | O servidor de lances e leilões não estará disponível durante a fase de teste facilitada do Chrome. |
| Indicadores de lances | Permitir que os navegadores solicitem e excluam indicadores de lances. | Estamos discutindo essa solicitação e Queremos receber mais feedback sobre por que ela deve ser priorizada. |
generateBid() |
Capacidade de atualizar o userBiddingSignals do interestGroup usando
updateURL. |
Estamos analisando essa proposta e aceitamos outros feedbacks e discussões. |
| Tipos de inventário do editor | Que tipos de inventário do editor serão compatíveis com os testes de Protected Audience e TOPICS? | Nem a API Protected Audience nem a API Topics são restritivas em termos dos tipos de inventário em que podem ser usados. |
| Integração de servidor para servidor | A integração direta entre a SSP e a DSP é necessária para a Protected Audience? | A integração direta entre a SSP e o DSP não vai ser necessária se ele não precisar processar indicadores de contexto no próprio servidor para transmitir essas informações processadas à função de lances no dispositivo. |
Um campo bid_currency em B&A |
Suporte para o campo bid_currency no serviço de lances e leilões. |
O B&A ainda não oferece suporte a um bid_currency, mas planejamos oferecer
esse suporte até o final de janeiro de 2024. Consulte o cronograma aqui. |
perBuyerSignals |
Existe um limite de tamanho para o app perBuyerSignals? |
Não há limite para o número de indicadores por comprador, mas o envio de muitos dados pode prejudicar o desempenho do navegador. |
| Casos de uso entre sites | Podemos usar grupos de interesse da API Protected Audience em vários sites? | A API Protected Audience não foi projetada para esses casos de uso, conforme explicado em turtledove/issues/282. |
| Solicitações HTTP do grupo de interesse | Inclua o Blob do grupo de interesse nos cabeçalhos HTTP. | Estamos analisando essa solicitação e recebemos mais feedback sobre ela. |
| Controle de qualidade de anúncios | Perda no controle de qualidade do anúncio relacionado às informações entre sites. | Gostaríamos de receber seu feedback e receber seu feedback. |
| Chrome DevTools | As solicitações de rede de público-alvo protegido enviadas ficam visíveis na guia "Rede" das Ferramentas para desenvolvedores do Chrome. | Estamos trabalhando para ativar essa funcionalidade na guia "Rede" e receberemos mais feedback sobre por que ela deve ser priorizada. |
| Ambiente de execução confiável | Quando os detalhes sobre quais métricas afetam a privacidade (e o nível delas) vão ser adicionados à explicação sobre o monitoramento do ambiente de execução confiável? | Estamos atualizando a explicação com essas informações. A explicação atualizada vai estar disponível a partir de novembro de 2023. |
directFrom |
Por que o directFrom não está empacotado como um pacote da Web? |
Compartilhamos a base para essa decisão aqui. |
| Delegação de impressão | Existe alguma maneira viável de fazer a delegação de impressões em que o resultado da seleção de um grupo de interesse é outra ação de segmentação? | Vários leilões aninhados não são compatíveis com nossas metas de privacidade por dois motivos. Primeiro, quando o vencedor de um leilão é renderizado dentro de um Fenced Frame, nossas metas de privacidade para a Protected Audience incluem a renderização do criativo resultante sem conhecimento do contexto: o URL da página ao redor ou o cookie primário são uma violação de privacidade. Nesse ambiente, um leilão aninhado não é viável. Segundo, o modelo da Protected Audience diz que o vencedor de cada leilão precisa ser baseado nos dados de apenas um site adicional. Os leilões aninhados seriam uma maneira de combinar isso, resultando na possibilidade de escolher anúncios com base em um perfil de vários sites. |
| Critério de dados em repouso | Explique mais detalhadamente o critério de dados em repouso no modelo de confiança de serviço de chave-valor. | Os dados no serviço de chave-valor são carregados na memória e veiculados de lá em vez de qualquer armazenamento em cache de leitura. |
| Indicador de dados do comprador | Existe um limite de tamanho definido para os indicadores buyer_data recebidos
das DSPs? |
No momento, não há limites impostos pelo navegador para sinais buyer_data
recebidos de DSPs. |
Medir anúncios digitais
Attribution Reporting (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Dispositivos diferentes | Planeje o suporte entre dispositivos para a API Attribution Reporting. | Entre dispositivos, há novos desafios de privacidade, além dos 3PCs, além de desafios de distribuição de tecnologia, considerando a variedade de dispositivos e plataformas que um usuário pode utilizar. Estamos explorando possíveis soluções, mas estamos focados nos casos de uso críticos atualmente suportados pela API Attribution Reporting e não temos planos de oferecer compatibilidade entre dispositivos antes da remoção dos cookies de terceiros. |
| (Também informado nos trimestres anteriores) Tamanho dos dados do acionador |
Por que o tamanho dos dados do acionador é limitado a 3 bits? | O tamanho é limitado a 3 bits e 8 valores distintos para garantir que a quantidade de informações entre sites e contextos sobre um usuário seja limitada. Convidamos os participantes do ecossistema a enviar feedback sobre se a parametrização atual para relatórios a nível de evento é suficiente. |
| Funil de conversão | Informar vários domínios que foram usados na conversão. | Esse caso de uso é possível porque a adição de vários destinos foi adicionada. Gostaríamos de receber mais feedback. |
| Suporte para o mesmo domínio em países diferentes | A API Attribution Reporting funciona com sites que têm o mesmo domínio, mas TLDs de vários países? | Esse problema foi discutido e resolvido com a parte interessada que levantou a dúvida. Se uma adtech precisar usar vários TLDs de país, ela precisará ter várias inscrições, com uma para cada TLD de país. |
| API Protected Audience e Attribution Reporting | As adtechs podem acessar as conversões de visualização para leilões da API Protected Audience e as conversões de clique para os Relatórios de atribuição? | Sim, o Sandbox de privacidade precisa oferecer suporte a VTCs e CTCs na API Protected Audience. |
| Atrasos de relatórios agregáveis | Reduza ainda mais os atrasos de relatórios agregáveis. | Recebemos feedbacks recentes sobre isso e compartilhamos algumas ideias aqui. Gostaríamos de receber mais feedback do ecossistema. |
| Atrasos de relatórios agregáveis | Reduzir os atrasos com a introdução da mediação do servidor. | Estamos analisando essa proposta e aceitamos seu feedback adicional . |
| Atrasos em relatórios a nível de evento | Reduzir os atrasos nos relatórios de eventos. | A proposta de nível de evento totalmente flexível, descrita em Configurações flexíveis no nível do evento, pode reduzir os atrasos nos relatórios de evento para até uma hora com uma compensação de ruído. |
| Origem do relatório de origem por fonte | A limitação de origens máximas de relatórios de origem por site de relatórios impede que as adtechs registrem fontes de diferentes origens de relatórios para uma única origem de editor. | Isso foi discutido com a parte interessada que apontou o problema,
e uma possível solução de usar uma origem de relatórios por
site de relatórios de fonte está sendo testada antes de tentar outras possíveis
soluções que envolvam redirecionamentos. Também estamos abertos a qualquer feedback do ecossistema sobre esse limite. |
| Relatórios de problemas | Como podemos informar erros ou problemas com a API Attribution Reporting ao Chrome? | Atualmente, recomendamos que as adtechs informem todos os erros da API Attribution Reporting que possam estar enfrentando como um problema no GitHub. Se eles estão enfrentando um problema relacionado ao Chrome, recomendamos criar um bug do Chromium. Os links sobre como e onde sinalizar problemas podem ser encontrados em Engajar e compartilhar feedback. |
| Eliminação de duplicação | Como eliminar a duplicação de conversões em diferentes pipelines e dispositivos? | A eliminação de duplicação em vários dispositivos e pipelines de medição é um desafio conhecido
e atual que as adtechs também enfrentam atualmente com os 3PCs. Com a
API Attribution Reporting, as adtechs podem decidir quando registrar
conversões específicas e adicionar metadados específicos para indicar quais
pipelines de medição foram usados para rastrear as conversões (em outras palavras,
parte da chave de agregação), que podem ser comparados com outros
pipelines de medição. Queremos receber mais feedback do ecossistema sobre esse assunto. |
| Eliminação de duplicação e prioridade | Solicite que a prioridade seja priorizada antes da eliminação de duplicação. | Estamos analisando esse pedido e envie seu feedback. |
| Combate à fraude | Risco de usuários mal-intencionados adulteram dados no nível do evento. | A verificação de relatórios não funciona para relatórios de evento pelos motivos descritos em Por que isso não oferece suporte a relatórios de evento?. |
| Tipo de conversão | Como podemos diferenciar entre visualização e navegação nos Relatórios de atribuição? | Temos a seguinte opção de filtragem integrada: source_type.
Mais detalhes disponíveis aqui. |
Serviço de agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Recuperação de orçamento | Algumas adtechs solicitaram a capacidade de reprocessar relatórios quando houver falhas, erros ou exclusões. | A equipe está explorando maneiras de abordar isso preservando a privacidade. |
| Registro no site | Várias adtechs solicitaram suporte para o processamento de várias origens na mesma conta para casos de uso como divisão de dados por local ou anunciante. Esse comportamento também é esperado pelas adtechs, já que o registro da API do cliente agora é baseado no site, e não na origem. A migração da origem para o registro no site simplifica o processo de integração de adtechs pela consistência com o processo de inscrição do cliente. | Em breve, lançaremos a migração do registro de origem para o registro do site para o serviço de agregação. O feedback do ecossistema será bem-vindo. |
| Plano de lançamento e descontinuação | Cronograma de lançamento e descontinuação dos recursos e patches do serviço de agregação publicados. O objetivo do plano é dar às adtechs visibilidade das nossas políticas de lançamento para que elas possam se preparar para os próximos lançamentos e descontinuações, além de garantir que elas executem versões estáveis e seguras dos serviços. | Recentemente, publicamos uma proposta para o plano de lançamento e descontinuação do serviço de agregação, e queremos receber outros feedbacks. |
| Coordenadores | O que acontece se os coordenadores abandonam o serviço de agregação? | Os dois coordenadores precisam estar totalmente disponíveis para que o sistema
funcione corretamente. A indisponibilidade curta é acomodada com novas tentativas nas nossas bibliotecas de cliente. A indisponibilidade mais longa de um dos dois coordenadores causará falha nos jobs de agregação. Os jobs poderão ser executados novamente se o orçamento de privacidade ainda não tiver sido consumido. No caso em que qualquer falha de serviço levou ao consumo de orçamento sem um relatório de resumo gravado no armazenamento de adtechs, recomendamos usar relatórios de depuração para extrair os resultados com a ferramenta de teste local. Também estamos trabalhando em recursos que permitam a recuperação do orçamento em caso de falhas para que as adtechs possam executar os jobs novamente. |
API Private agregação
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| URL do blob | Solicitação para compatibilidade com Blob Url no armazenamento compartilhado. | O suporte para URL do blob foi adicionado no Chrome M116. |
Limitar o rastreamento verso
Redução do user agent e dicas de cliente do user agent
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| JavaScript API | Disponibilidade da API User Agent Client Hints JavaScript. | Não há planos de remover essa funcionalidade, porque ela é nossa solução principal para parceiros que querem acessar ativamente os dados de alta entropia além do que está disponível por padrão no UA congelado e reduzido. |
| Informações do dispositivo e do formato | Capacidade dos sites de entender a entrada, a saída e outras informações que o dispositivo que visita o site pode oferecer. | Após o feedback do ecossistema, adicionamos suporte a essa solicitação. |
Proteção de IP (antigo Gnatcatcher)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Tráfego de terceiros qualificado | O que significa "tráfego de terceiros qualificado" na explicação? | Entendemos a importância dessa pergunta e estamos trabalhando para identificar qual tráfego de terceiros será qualificado ou não. Gostaríamos de receber seu feedback sobre esse assunto. |
| Auditorias de tráfego de rede | Suporte para que empresas realizem auditorias de tráfego de rede em suas redes. | Somente o tráfego de terceiros incorporado a sites próprios é afetado, o que limita a quantidade de tráfego que requer filtragem. Além disso, planejamos oferecer aos usuários a opção de usar ou não a proteção de IP. Para o Chrome controlado por empresas, haverá políticas corporativas para desativar a proteção de IP. Por fim, estamos explorando quais controles, se houver, serão fornecidos aos operadores de rede para desativar a proteção de IP. Gostaríamos de receber seu feedback sobre esse assunto. |
| Controle de acesso | A Proteção de IP pode afetar serviços da Web que usam endereços IP para controle de acesso. | Entendemos a importância dos casos de uso antifraude e o possível impacto deles. Buscamos feedback do ecossistema sobre como oferecer um suporte melhor aos casos de uso antifraude que normalmente dependem de endereços IP. |
| Comunicação entre os proxies de dois saltos | Como garantir que não haja informações entre proxies. | Estamos no processo de projetar as interações de proxy. Nosso objetivo é minimizar as chances de esse compartilhamento de informações ser feito por meios de negócios, processos e técnicos. |
| Autenticação que não é do Google | Suporte para autenticações que não são do Google. | Planejamos publicar mais detalhes sobre a autenticação de conta no futuro, mas compartilhamos algumas considerações iniciais. |
| Classificação do tracker | Como a Proteção de IP determina o que constitui um rastreador e as variantes dele? | Entendemos a importância dessa pergunta e estamos trabalhando para identificar qual tráfego de terceiros será qualificado ou não. Gostaríamos de receber seu feedback sobre esse assunto. |
| Análise de dados | A Proteção de IP pode afetar a precisão dos serviços de análise. | Queremos entender ainda mais o impacto da Proteção de IP e aguardamos feedback e exemplos adicionais do ecossistema. |
| Proxy | Se um usuário estiver usando proxy ou tiver definido manualmente um proxy, como a máscara IP funcionará nesse caso? | Queremos entender o impacto que a Proteção de IP pode ter em outros proxies. Não temos planos para compartilhar no momento. Seu feedback sobre esse tópico é bem-vindo. |
| Oferta premium | A proteção de IP será um recurso pago? | A Proteção de IP estará disponível para usuários do Chrome como parte da experiência principal do navegador. Ele não será pago. |
| Servidor proxy | Os mesmos servidores proxy serão usados durante as sessões do usuário? | Uma conexão HTTP/S usará um único par de proxies e apresentará um único endereço IP mascarado à origem. Além disso, não há restrições rígidas em que conexões HTTP/S diferentes precisem usar os mesmos servidores. |
| Suporte a plataformas | Em qual plataforma a proteção de IP será compatível? | A Proteção de IP estará disponível inicialmente no Chrome para Android e computadores. Continuamos avaliando como expandir a proteção para outras plataformas. |
| Recusar | Os usuários poderão desativar a Proteção de IP? | Planejamos oferecer aos usuários a opção de usar a proteção IP ou não. |
| Anonimização | Quais tipos de solicitações ficarão anônimos de acordo com a Proteção de IP? | As solicitações HTTP/S e DNS para domínios de terceiros qualificados são anonimizadas por meio dos proxies de privacidade. Forneceremos mais detalhes em uma próxima explicação sobre como determinaremos quais domínios serão incluídos. O restante do tráfego (por exemplo, o restante das solicitações de DNS ou outro tráfego HTTP/S) não é afetado. |
| Visibilidade dos dados | Os endereços de rede podem ser acessados durante o primeiro salto na proteção de IP. | No modelo de proxy de dois saltos, o primeiro salto (controlado pelo Google) só vê o IP do cliente de origem e uma solicitação de conexão ao segundo salto, enquanto o segundo salto (controlado por uma CDN externa) vê apenas uma tupla no primeiro salto (IP do proxy + porta) e no IP de destino. Para a resposta de volta da origem, o segundo salto pode encaminhar a resposta para o proxy + porta do primeiro salto associado à solicitação e não precisa saber nada sobre o IP do cliente original, e o primeiro salto apenas retorna a resposta para o cliente, sem aprender nada sobre o IP de destino. Dessa forma, o primeiro salto aprende apenas o IP do cliente e o segundo salto, enquanto o segundo salto aprende apenas o IP de destino. |
| WebView | A Proteção de IP estará disponível para o Android WebView no futuro? | Não temos planos para compartilhar no momento, mas nossa visão é oferecer essa proteção o mais amplamente possível. |
Mitigação de rastreio por redirecionamento
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Rastreamento de interação | Como as interações do usuário são acompanhadas? | As mitigações de rastreio por redirecionamento rastreiam dois tipos de interações do
usuário:
Essas interações são associadas ao site de nível superior, nas páginas em que ocorrem. Por exemplo, se um usuário clicar em um iframe incorporado, a interação será associada ao site de nível superior, e não ao site incorporado. As interações são armazenadas em um banco de dados que contém a segmentação sem esquema+1 e o horário da interação. As interações protegem o domínio associado contra a exclusão do estado de mitigação do rastreamento de rejeição por 45 dias. |
| Isenções da lista de permissões | Os domínios podem ser isentos? | Estamos considerando essa solicitação e esperamos receber mais feedback do ecossistema. |
Orçamento de privacidade
Nenhum feedback foi recebido neste trimestre.
Fortaleça os limites de privacidade entre sites
Conjuntos de sites relacionados (antigos conjuntos primários)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Abordagem centralizada | Preocupação com a abordagem de repositório centralizado para gerenciar conjuntos de sites relacionados. | Um repositório público e de fácil acesso é fundamental para o design do RWS, porque ele fornece responsabilização pelos envios. A funcionalidade de cookies de terceiros é fornecida pelo uso da API Storage Access ou da API rSAFor, com a associação do RWS fornecendo acesso concedido automaticamente (em vez de solicitações com a API Storage Access). Acreditamos que uma abordagem como o processo de envio de RWS é um requisito apropriado para a concessão automática de acesso a cookies de terceiros. |
| Renomeando o arquivo JSON | Com a mudança no nome da API, o nome do arquivo JSON hospedado precisa ser alterado? | Sim, as diretrizes de envio foram alteradas, e o domínio
principal precisa disponibilizar um arquivo JSON em
/.well-known/related-website-set.json. Os conjuntos existentes na lista do RWS não precisam ser modificados, mas, se houver modificações enviadas aos conjuntos atuais, o arquivo JSON precisará ser modificado. |
| Limite de domínio (informado também nos trimestres anteriores) | Solicitação para expandir o número de domínios associados | Como anunciamos em uma postagem do blog em 31 de agosto, aumentamos o limite de domínios associados para cinco domínios após o feedback do ecossistema. Decidimos aumentar o limite de domínios associados para cinco domínios (mais um domínio principal) que corresponde melhor à implementação mais comparável oferecida por outro navegador grande. |
| Cookies de terceiros | Os conjuntos de sites relacionados só vão funcionar com cookies de terceiros desativados? | Os conjuntos de sites relacionados vão funcionar mesmo quando um usuário não tiver bloqueado cookies de terceiros. No entanto, não haverá efeito observável, já que os cookies relevantes estão disponíveis sem a necessidade de conjuntos de sites relacionados e a API Storage Access. |
| Edições legítimas | Como o repositório de conjuntos de sites relacionados impede que não proprietários modifiquem conjuntos? | De acordo com os guias
de envio, qualquer pessoa pode enviar um PR no GitHub para editar o
arquivo first_party_sets.JSON. No entanto, se o PR for aprovado (aprovar
validações técnicas e assim por diante), ele será mesclado manualmente em lotes
à lista de QPS canônicos uma vez por semana (terças-feiras às 12h do horário
do leste dos EUA) pelo Google.Se um usuário de má-fé tentar modificar um conjunto que não é seu, não haverá problema, já que ele não poderá modificar os arquivos .well-known
e, portanto, as validações falharão. |
| Sequestro de domínio | A invasão de domínio pode expor dados de domínio relacionados a partes não autorizadas. | Isso não é possível, conforme discutido neste problema da API Protected Audience no GitHub (em inglês). |
API Fenced Frames
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Violação de conteúdo | Permitir que os usuários denunciem anúncios suspeitos. | Não é possível denunciar anúncios suspeitos por Fenced Frames. Os usuários ainda podem interagir com o anúncio e denunciar anúncios suspeitos à adtech da maneira habitual. |
| Interação com locais próximos | Permita a interação com o site ao redor ou de nível superior. | Queremos entender por que essa solicitação é necessária e receber mais feedback do ecossistema. |
| Publicidade nativa | Suporte a frame isolado para publicidade nativa. | Estamos pensando em oferecer suporte ao caso de uso e estamos discutindo possíveis soluções alternativas e soluções. |
API Shared Storage
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Vários domínios | Permita a comunicação entre domínios para armazenamento local. | No momento, esse caso de uso não está de acordo com os portões de saída que preservam a privacidade do Shared Storage, mas aceitamos contexto adicional à medida que evoluímos as propostas para armazenamento não particionado. |
| URL do blob | Solicitação para compatibilidade com Blob Url no armazenamento compartilhado. | O suporte para URL do blob foi adicionado no Chrome M116. |
ÍCONES
Nenhum feedback foi recebido neste trimestre.
FedCM
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Cookies de terceiros | O FedCM está desativado se os usuários ativarem a opção "Bloquear cookies de terceiros" nas configurações do Chrome? | Sim, o FedCM está desativado no momento. Para testar, recomendamos que você
também ative
chrome://flags/#fedcm-.Procuramos oferecer suporte à FedCM sem cookies de terceiros no futuro. |
Combater spam e fraudes
API Private State Token (e outras APIs)
| Tema do feedback | Resumo | Resposta do Chrome |
|---|---|---|
| Expiração do token | Depois que o Google Chrome for desinstalado, o token será perdido ou armazenado em cache? | O token será perdido se o usuário desinstalar o Google Chrome. |
| Informações do token | Como os emissores podem manter particulares as informações emitidas no token de estado privado? | As informações sempre são mantidas privadas no token e não podem ser descriptografadas por partes externas que não têm as chaves. |
| Erro na demonstração | Erro ao tentar executar a demonstração do token de estado particular. | Atualizamos a demonstração, e ela deve estar funcionando corretamente. |