Esta página foi traduzida pela API Cloud Translation.

Relatório de feedback – 3o trimestre de 2023
bookmark_border Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Relatório trimestral do terceiro trimestre de 2023 que resume o feedback do ecossistema recebido sobre as propostas do Sandbox de privacidade e a resposta do Chrome.

Como parte dos compromissos com o CMA, o Google concordou em apresentar publicamente relatórios trimestrais sobre o processo de engajamento das partes interessadas nas propostas do Sandbox de privacidade (consulte os parágrafos 12 e 17(c)(ii) dos compromissos). Esses relatórios de resumo de feedback do Sandbox de privacidade são gerados pela agregação do feedback recebido pelo Chrome de várias fontes, conforme listado na visão geral do feedback, incluindo, entre outros: problemas do GitHub, o formulário de feedback disponibilizado em privacysandbox.com, reuniões com as partes interessadas do setor e fóruns de padrões da Web. O Chrome recebe com prazer o feedback recebido do ecossistema e está procurando ativamente maneiras de integrar as lições a decisões de design.

Os temas de feedback são classificados pela prevalência em cada API. Isso é feito com uma agregação da quantidade de feedback que a equipe do Chrome recebeu sobre um tema específico e organizado em ordem decrescente de quantidade. Os temas comuns de feedback foram identificados analisando os tópicos de discussão de reuniões públicas (W3C, PatCG, IETF), feedback direto, GitHub e perguntas frequentes que aparecem nas equipes internas e nos formulários públicos do Google.

Mais especificamente, as atas das reuniões dos órgãos de padrões da Web foram analisadas e, para feedback direto, os registros do Google de reuniões individuais com as partes interessadas, e-mails recebidos por engenheiros individuais, a lista de e-mails da API e o formulário de feedback público foram considerados. O Google então coordenou as equipes envolvidas nessas várias atividades de divulgação para determinar a prevalência relativa dos temas emergentes em relação a cada API.

As explicações das respostas do Chrome ao feedback foram desenvolvidas com base nas perguntas frequentes publicadas, nas respostas reais feitas a problemas levantados por partes interessadas e na determinação de uma posição especificamente para os fins deste exercício de relatórios públicos. Refletindo o foco atual de desenvolvimento e teste, foram recebidas perguntas e feedback 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

CHIPS: Cookies com estado particionado independente
DSP: Plataforma de demanda
FedCM: Gerenciamento de credenciais federadas
QPS: Conjuntos próprios
IAB: Interactive Advertising Bureau
IDP: Provedor de identidade
IETF: Internet Engineering Task Force
IP: Endereço de Protocolo de Internet
openRTB: Lances em tempo real
Prorrogação: Teste da Origin
PatCG: Grupo da comunidade de tecnologias de publicidade privada
RP: Entidade confiável
SSP: Plataforma de fornecimento
TEE: Ambiente de execução confiável
UA: String do user agent
UA-CH: Dicas de cliente HTTP do user agent
W3C: World Wide Web Consortium
WIPB: IP Blindness proposital

Feedback geral, sem API ou tecnologia específica

Tema do feedback	Resumo	Resposta do Chrome
Prontidão do ecossistema	As SSPs destacaram uma preocupação com os publishers que não estavam prontos e não realizavam a implantação necessária.	O Sandbox de privacidade tem uma divulgação focada especificamente em educar os editores, o que inclui webinars e reuniões dedicados com editores e SSPs presentes para impulsionar o trabalho de implantação.
Descontinuação de cookies de terceiros	As preocupações com a descontinuação de cookies de terceiros (3PCD, na sigla em inglês) aumentam no 4º trimestre de 2023 devido ao blackout tecnológico do setor.	O cronograma do Sandbox de privacidade foi discutido com a CMA, com uma sequência que leva à preparação para o segundo semestre de 2024. O Sandbox de privacidade vai publicar informações mais detalhadas sobre a sequência de aumento da 3PCD. De acordo com os Compromissos, a 3PCD está sujeita às preocupações com a concorrência da CMA.
Google Ad Manager	O Google Ad Manager se recusa a expor a plataforma da API, o que dificulta o teste.	Resposta do Google Ad Manager:pelos motivos explicados nesta resposta do Google Ad Manager, os planos do Google Ad Manager para a integração com a 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 só é exposto a SSPs do AdX ou do Open Bidding.	A documentação pública do Google Ad Manager (link em inglês) afirma 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, a documentação menciona a lógica de pontuação de nível superior: "O Ad Manager vai comparar o lance vencedor de cada leilão de componente, incluindo o próprio leilão de componente do Ad Manager para lances de grupo de interesse dos compradores, além do melhor anúncio contextual (selecionado pela alocação dinâmica) e vai veicular o anúncio com o lance mais alto".
Google Ad Manager	Os produtos de anúncios do Google Ads precisam estar sujeitos às mesmas regras que os produtos de anúncios de terceiros.	Os produtos do Google Ads já estão sujeitos às mesmas regras das terceiros.
Testes facilitados pelo Chrome	Adicione rótulos para navegadores que não estão em A ou B.	Não estamos considerando fazer isso no momento, porque nossa investigação concluiu que adicionar rótulos que não são de experimentos pode complicar as preocupações de privacidade em relação ao tráfego no modo de navegação anônima.
Agência 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 quiser criar tecnologias diretamente nas APIs, poderá fazer isso. As APIs do lado do cliente precisam ser integradas ao cliente, assim como os cookies. Muitas das APIs, como cookies, também têm uma interface de cabeçalho HTTP. Já vimos um framework do setor de publicidade, o Prebid, criar integrações do lado do cliente com as APIs. Outras organizações poderiam 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á havia expressado preocupação com a escalabilidade dessas soluções em 2012?	A tecnologia de aprimoramento da privacidade (PET, na sigla em inglês) como campo de estudo evoluiu significativamente desde 2012 e, com ela, aplicações comercialmente viáveis. O Sandbox de privacidade tem como base combinações de PETs que não seriam viáveis há mais de uma década. Além disso, o poder de computação pessoal aumentou, assim como as expectativas dos consumidores em relação aos navegadores e as expectativas regulatórias de privacidade.
Machine learning	Qual é o uso planejado do Sandbox de privacidade do Google para fins de aprendizado de máquina?	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 empresas de adtech ou qualquer outra pessoa continuem a usar o aprendizado de máquina. O Sandbox de privacidade também não exige que as empresas que se integram às APIs usem o aprendizado de máquina. É razoável esperar que as empresas continuem criando produtos e serviços de maneiras que atendam às necessidades dos clientes, incluindo ou não o aprendizado de máquina. Qualquer aprendizado de máquina que os integradores do Sandbox de privacidade criem será conhecido por eles e, portanto, não será obscurecido.
Verificação de dados	Como as empresas podem verificar se os dados que recebem ao usar 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 a serem executadas em ambientes de execução confiáveis também são de código aberto e auditáveis. Qualquer pessoa pode inspecionar o código, incluindo o MRC.
(Também informado nos trimestres anteriores) Suporte à produção	Qual é o processo em vigor para que o Chrome ofereça suporte a problemas técnicos e encaminhamentos do Sandbox de privacidade que afetam o ecossistema?	O Google oferece vários canais para que as adtechs possam informar problemas técnicos e permitir que os encaminhamentos necessários sejam feitos para resolver esses problemas. Além disso, o Chrome espera criar e dimensionar ainda mais um processo para resolver problemas técnicos e encaminhamentos que afetam a saúde do ecossistema. O Chrome está comprometido em garantir recursos para esse esforço. Consulte nossos fóruns públicos e privados para feedback e encaminhamento.
Modos de teste facilitados pelo Chrome	Mais informações sobre os cronogramas e as implementações exatas dos modos de teste facilitados pelo Chrome.	Compartilhamos uma postagem do blog sobre os modos de teste e estamos trabalhando para compartilhar mais informações em breve. Estamos aceitando 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 ao TCF v2 ou ao modo de consentimento. No entanto, empresas e grupos comerciais do setor podem adaptar os produtos e frameworks para funcionar 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 recebido e nas políticas associadas. Esperamos que as empresas determinem quando e como usar várias funcionalidades oferecidas pelos blocos de construção do Sandbox de privacidade.

Inscrição e atestado

Tema do feedback	Resumo	Resposta do Chrome
Restrição	O processo de inscrição significa que o Google pode decidir qual empresa no ecossistema tem permissão para usar as APIs do Sandbox de privacidade.	O processo de inscrição e atestado envolve, essencialmente, a verificação da entidade (por exemplo, a entidade tem um número DUNS, pode fornecer um link para uma política de privacidade e assim por diante) e torna o atestado público um requisito para chamar as APIs. As entidades que atenderem aos requisitos de inscrição serão validadas. Para empresas que não têm um DUN, oferecemos um processo rápido e sem custo financeiro com a Dun & Bradstreet para adquirir um. O objetivo é melhorar as proteções de privacidade das APIs (com as medidas mencionadas) e também adicionar um nível de transparência às APIs do Sandbox de privacidade para que as partes interessadas entendam melhor quem está usando qual API e quais declarações estão sendo feitas. Estamos abertos a mais feedback do setor sobre esse problema, que já foi usado para moldar o processo.
Overhead de novo registro	O arquivo de atestado expira a cada 12 meses e exige que os sites se inscrevam novamente.	Ouvimos o feedback do ecossistema e mudamos nossa abordagem de acordo. Isso significa que os arquivos não vão mais expirar após 12 meses ou qualquer período definido. Estamos atualizando o guia para desenvolvedores de inscrição com mais contexto.
Arquivo de atestado	Como o arquivo de atestado é usado?	Todas as empresas que chamam APIs de relevância e medição vão precisar fazer upload do arquivo de atestado no site até o prazo de implementação e mantê-lo disponível para visualização pública enquanto quiserem 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 pelo próprio mecanismo do sistema de inscrição para consultar os servidores das entidades registradas e garantir que o arquivo de atestado seja válido. As declarações serão incluídas nos Relatórios de transparência e poderão ser visualizadas pelo público em geral. Esperamos que as empresas ajam de acordo com as declarações de atestado, assim como o restante do ecossistema e os órgãos reguladores relevantes.
Registro	A inscrição é por site ou por origem?	A inscrição é feita no nível do site.

Mostrar conteúdo e anúncios relevantes

Tópicos

Tema do feedback	Resumo	Resposta do Chrome
Desempenho	Problemas de desempenho no impacto da taxa de ativação de tópicos no Espaço Econômico Europeu.	Sugerimos que as partes interessadas entrem em contato com a autoridade de proteção de dados relevante sobre esse problema. Eles estão em melhor posição para resolver essas preocupações e influenciar se as aplicações de tecnologias que melhoram a privacidade são incentivadas por leis ou tratadas como rastreamento, exigindo as mesmas abordagens de consentimento. O último pode fazer com que APIs como as do Sandbox de privacidade não fiquem disponíveis com frequência.
Registro	Os bidders downstream precisam se inscrever na API Topics para usar os indicadores de Topics de SSPs upstream?	Os receptores downstream de tópicos além do autor da chamada inicial da API Topics não precisam ser registrados, mas muitos provavelmente serão registrados para outros usos da API. Uma lista de inscritos no Sandbox de privacidade será fornecida de forma programática como parte dos esforços de transparência do programa, o que permitiria que um autor da chamada interessado da API Topics verificasse se o destinatário para o qual um tópico está sendo enviado está inscrito, se o autor da chamada quiser.
Filtragem de temas	Solicitação para aplicar a filtragem de outro autor da chamada aos tópicos que ele recupera na página para compartilhar apenas o que os compradores estão qualificados para recuperar.	Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema.
Exclusão de sites	Excluir sites que contribuem para os temas de um usuário.	Os tópicos não são chamados por padrão. É importante observar que nenhum conteúdo da página é levado em conta quando os tópicos são selecionados, e todos os tópicos são selecionados para garantir que não sejam sensíveis. Um site também pode restringir a inclusão dele no cálculo de temas usando o cabeçalho de política de permissão a seguir: `Permissions-Policy: browsing-topics=()`
Observação de tópicos	Permitir que os editores deem permissões para que o Chrome classifique temas com base no conteúdo da página (por exemplo, cabeçalho ou corpo).	Anteriormente, consideramos oferecer uma funcionalidade para classificar sites em tópicos com base no conteúdo da página e decidimos não seguir em frente devido a questões de privacidade e segurança. Essa proposta pode mitigar algumas dessas preocupações, mas não está claro até que ponto. Devido ao próximo período de teste do CMA, não esperamos que essa mudança ocorra antes do 3PCD. Envie seu feedback.
Observação de tópicos	Oferecer políticas de permissão mais detalhadas para editores.	Fornecer políticas de permissão mais detalhadas para editores permitiria que os sites de editores afetassem negativamente 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 o problema do GitHub Atualizar a política de permissões para oferecer suporte a permissões separadas para extrair e observar para uma discussão mais detalhada sobre o assunto.
Tópicos médicos e de saúde	Por que a hierarquia de tópicos não inclui tópicos nas categorias de saúde ou medicina?	As categorias de saúde e médicas são consideradas sensíveis e, portanto, excluídas da taxonomia de tópicos.
Recuperação de tópicos	Uma maneira mais rápida de as DSPs receberem tópicos sem buscar usando cabeçalhos.	Os métodos de cabeçalho são mais eficientes e menos custosos do que criar um iframe de origem cruzada e fazer 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 tópicos são acessados. Isso foi discutido em detalhes aqui.
Recuperação de tópicos	Solicitações para oferecer suporte à transmissão de tópicos por cabeçalhos em solicitações de tag de script entre origens.	Do ponto de vista da segurança, isso não é possível. Cada documento e o ambiente de execução dele sã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 não consentidos de uma origem para outra. Uma alternativa é fornecer um atributo `browsingTopics` em tags `<script>`. Isso precisa ser limpo do ponto de vista da segurança e não adicionar mais latência. Estamos abertos a feedback de partes interessadas.
Reconhecimento	Aumentar o conhecimento público da API Topics e como ela será usada.	Entramos em contato com a parte interessada que forneceu esse feedback, e o problema foi resolvido no GitHub. Vamos continuar apoiando o entendimento do ecossistema sobre a API e esperamos ouvir 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 no guia para desenvolvedores do Chrome.
Notificação	Notificação para alertar o usuário quando os tópicos dele estiverem sendo observados por um site.	Abordamos este feedback no GitHub. Os usuários podem saber mais sobre os controles de tópicos na Central de Ajuda do Chrome.
Machine learning	Como a ML pode ser usada para inferir os temas do usuário?	Estamos discutindo esse problema e agradecemos seu feedback.
Utilidade para diferentes tipos de partes interessadas	Empresas de adtech menores podem não conseguir observar os temas devido à maneira como os navegadores os calculam.	Somente as adtechs que observaram o usuário visitar uma página sobre o tema em questão nas últimas três semanas vão receber um tema. Se a tecnologia de publicidade não tiver chamado 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 cujos serviços são usados por um número maior de proprietários de sites e, portanto, têm mais oportunidades de observar uma visita ao site por um determinado usuário, 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 para as partes que já podem observar as mesmas informações (atualmente por cookies de terceiros).
Solicitação XHR	Quando a inclusão de tópicos em solicitações `XMLHttpRequest` (XHR) será descontinuada?	Conforme anunciado em agosto de 2023, o Chrome começou a descontinuar o suporte a XHR ao fazer a transição do teste de origem para a disponibilidade geral. À medida que o Topics avançava, o suporte a XHR era incluído apenas para usuários com os recursos de OT ativados e foi totalmente descontinuado quando os grupos experimentais de OT individuais foram mesclados. Se você estava usando o Topics com XHR, seus sites não vão ser interrompidos. Os tópicos não serão adicionados aos cabeçalhos de solicitação XHR. Recomendamos que você faça a transição para `fetch` para sua solicitação, use o atributo iframe ou a API JavaScript para recuperar tópicos. O fetch é compatível com todos os navegadores modernos, mas não com o Internet Explorer ou o Opera Mini.
Processo de atualização da taxonomia e do classificador	Mais informações sobre a taxonomia de tópicos e a cadência de lançamento do classificador e como as empresas podem se preparar para essas atualizações.	Nossa resposta permanece a mesma do segundo trimestre: Como informado na postagem recente do blog, esperamos que a taxonomia evolua com o tempo e que a governança da taxonomia seja transferida para uma parte externa que represente as partes interessadas de todo o setor. Também compartilhamos o plano de aumento no grupo topics-announce.
Abuso	Possível ataque por cadeia de redirecionamento.	Estamos considerando esse problema e agradecemos mais feedback.
Tipos de inventário do editor	Para quais tipos de inventário do editor a API Protected Audience e os testes de tópicos vão oferecer suporte?	Nem a Protected Audience nem os tópicos são inerentemente restritivos em termos dos tipos de inventário em que podem ser usados.
Tempo de otimização	Não recomendamos um tempo de aceleração para que as novas taxonomias cheguem a 100%.	Após este pedido de feedback do ecossistema e da discussão durante as reuniões do PATCG, anunciamos nosso plano para o lançamento da nova taxonomia.

API Protected Audience (antes conhecida como FLEDGE)

Tema do feedback	Resumo	Resposta do Chrome
Leilões de nível superior	Capacidade de usar o servidor de anúncios do editor do Google sem dar controle do Google Ad Manager ao leilão da API Protected Audience de nível superior.	Resposta do 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 Protected Audience de nível superior, por estes motivos: Para veicular corretamente os anúncios dos 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 Protected Audience de nível superior. Como servidor de anúncios do editor, nosso papel é fornecer previsões para que os editores possam negociar campanhas vendidas diretamente sem superreserva e para controlar e entregar as reservas diretas da melhor forma possível. Para fazer isso, é necessário executar o leilão final para comparar toda a demanda direta e indireta qualificada. A previsão e o ritmo são as principais funcionalidades que os editores esperam de um servidor de anúncios. Sem uma previsão precisa, os editores podem acabar vendendo mais do que o inventário, o que coloca a reputação do negócio em risco. O ritmo também é fundamental, já que não cumprir contratos de reserva com os anunciantes também pode prejudicar a relação direta entre editor e anunciante, o que pode resultar em um impacto significativo para os negócios de um editor. Em resumo, não consideramos a atividade de um servidor de anúncios do editor que realiza o leilão de Protected Audience de nível superior como distinta das outras atividades do servidor de anúncios do editor.
`directFrom SellerSignals`	`directFrom SellerSignals` permite que o Google Ad Manager impeça que o editor veja o preço do leilão contextual.	Resposta do Chrome: Não é possível saber se as informações transmitidas para `runAdAuction()` vêm do vendedor, a menos que ele chame `runAdAuction()` do próprio iframe. Em um leilão de vários vendedores, fica impossível fazer com que todos os vendedores criem o frame chamando `runAdAuction()`. `directFromSellerSignals` resolveu esse problema carregando conteúdo de um pacote de subrecursos carregado da origem de um vendedor. Isso garante que a autenticidade e a integridade das informações transmitidas para um leilão das configurações de leilões do vendedor não possam ser manipuladas. Se os editores quiserem usar a API Protected Audience para entender qualquer uma das informações que os provedores de tecnologia estão transmitindo para os leilões da Protected Audience, eles poderão solicitar essa funcionalidade aos provedores de tecnologia. Resposta do Google Ad Manager: Há anos, temos um forte foco na justiça dos leilões, 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ê lances no leilão, o que reafirmamos mais tarde nos nossos compromissos com a Autoridade de Concorrência Francesa. Para leilões com Protected Audience, pretendemos manter nossa promessa usando `directFromSellerSignals` e não compartilhar o lance de nenhum participante do leilão com outro participante antes do fim 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 nosso próprio leilão de componentes, conforme explicado na atualização Mais esclarecimentos sobre a dinâmica do leilão de nível superior.
Exposição de informações	A lógica de negócios e os detalhes contratuais sensíveis 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, é possível que a pessoa que está usando o navegador possa acompanhar o leilão, incluindo o número de lances de diferentes partes. Como o navegador é o agente do usuário, não achamos possível ou desejável tentar mudar isso. No entanto, apenas a pessoa que usa o navegador tem visibilidade dessas operações. Uma execução de leilão no dispositivo usando a API Protected Audience não é detectável por nenhum servidor, incluindo o do Google.
`PerBuyerExperiment GroupId`	O intervalo de valores atual de `PerBuyerExperiment GroupId` pode permitir 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 a declaração obrigatória do Sandbox de privacidade de que os usuários da API não vão tentar 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, na sigla em inglês) vai oferecer proteção técnica contra esse ataque.
Política de mesma origem	Relaxe a política de mesma origem para permitir subdomínios.	Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema.
Criação do número de versão da API	Solicitação de controle de versões e notas da versão para mudanças na API Protected Audience.	Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema.
Leilões de vários SSPs	Permitir que indicadores de leilão de nível superior realizem mesclagens JSON com o indicador de componente `auctionSignals`.	Estamos considerando essa solicitação e aceitamos mais feedback do ecossistema.
Limite de lance	Aumente o limite do número de componentes do anúncio que entram no lance de 20 para 40.	Estamos considerando essa solicitação e gostaríamos de receber mais feedback do ecossistema sobre por que isso seria útil.
(Também informado nos trimestres anteriores) Performance dos leilões da API Protected Audience	Relatório de testadores de que os leilões da API Protected Audience têm alta latência.	Em relação a questões de latência, a API Protected Audience geralmente seguiu o paradigma padrão de criação de controles que permitem aos vendedores decidir quanto tempo e recursos os licitantes podem consumir e ferramentas de criação que permitem que os compradores decidam como usar melhor os recursos disponíveis. Esses controles e ferramentas geralmente estão disponíveis hoje, mas os benefícios completos só serão percebidos após a adoção por compradores e vendedores. Além disso, o Chrome continua trabalhando em várias melhorias de infraestrutura para aumentar a velocidade do leilão (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Envie seu feedback sobre as duas metades desse esforço de latência: novas ferramentas que compradores e vendedores achariam úteis e relatórios de gargalos observados que os engenheiros do Chrome precisam investigar.
Filtragem de compra	Adicionamos suporte à filtragem do lado da compra com base em grupos de interesse.	Sugerimos várias maneiras de mudar os designs de SSPs e DSPs para lidar com isso: Transferência de parte do trabalho para o servidor de chave-valor do DSP. SSPs criando alguns indicadores de contexto e os transmitindo para DSPs. SSPs armazenando em cache indicadores contextuais para DSPs.
Controle de grupo de interesse do editor	Suporte para editores que buscam delegar o uso de grupos de interesse criados por editores.	Tivemos discussões com muitas partes sobre a solicitação. Acreditamos que todos os casos de uso envolvidos na "delegação" dos grupos de interesse criados pelo editor podem ser acomodados agora. Além disso, precisamos criar mais suporte para que alguns casos de uso fluam melhor no futuro.
(Também informado no segundo trimestre) Ambientes de execução confiáveis	Suporte a ambientes de execução confiável (TEE) em ambientes de nuvem não públicos.	Nossa resposta é semelhante à dos trimestres anteriores: Continuamos a oferecer suporte a opções além das soluções públicas baseadas em nuvem, mas não temos planos atuais para oferecer suporte a TEEs local. 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 na nuvem (por exemplo, com suporte ao Google Cloud, além da AWS) é o mais vantajoso 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.
Ambiente de execução confiável	Os componentes no caminho de veiculaçã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.	Atualmente, o endereço IP é transmitido como um metadado nos cabeçalhos de 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 de público-alvo protegido no dispositivo. Consulte Encaminhamento de metadados para mais informações. A longo prazo, planejamos usar um proxy para a tecnologia de anúncio e o tráfego do rastreador por um proxy 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 será definido ou será flexível (ou dinâmico)?	O TTL geralmente é estático. Atualmente, o TTL para o público é de 8 dias, e a rotação acontece a cada 7 dias. O TTL também é o mesmo para chaves privadas no caso do serviço de agregação. No caso de serviços de lances e leilões, as chaves públicas e privadas são buscadas a cada N horas no caminho sem solicitação e armazenadas em cache na memória, para que não haja um atraso de mais de N horas entre a rotação das chaves e a coleta delas pelos servidores. O buffer de um dia entre a rotação e o vencimento de chaves é para garantir que, mesmo que a geração de chaves falhe, os serviços possam continuar funcionando. Estamos considerando estender o TTL para ser mais resistente a interrupções. Em caso de vazamento de chaves, planejamos forçar manualmente a geração de chaves e invalidar as chaves mais cedo. As chaves públicas são armazenadas em cache nos clientes, atualmente por 24 horas, para garantir que, em caso de falha do coordenador, os serviços ainda possam operar.
Ajuste da programação	Suporte para a modelagem de tráfego para serviços de lances e leilões.	Com base nos dados próprios ou contextuais do editor, os compradores podem indicar a demanda para leilões de público-alvo protegido. Os vendedores também podem fazer determinações semelhantes no servidor de anúncios ou no servidor do Ad Exchange. Os modelos podem ser treinados com dados próprios e qualquer relatório agregado dos 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 há demanda para leilões de Protected Audience. Acreditamos que essa pode ser uma maneira eficaz de moldar o tráfego.
Leilão de componentes	Quais auctionSignals de nível superior são compartilhados com os vendedores de componentes?	Os compradores em um leilão de componentes só recebem sinais 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 leilão de audiência protegida.
Renderização de vídeo	Suporte para renderização de vídeo usando Protected Audience e Fenced Frames.	A API Protected Audience oferece suporte à renderização de vídeo usando um mecanismo que depende de iframes. No entanto, ainda não projetamos uma solução compatível com os frames cercados, e essa é uma das razões pelas quais decidimos adiar a aplicação dos frames cercados para 2026. Isso significa que, se um parceiro decidir aplicar os frames restritos agora, o suporte para vídeo não estará disponível para ele.
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 branding. O armazenamento compartilhado e os limites de frequência específicos do site também podem ser usados para outros controles de limite de frequência.
Preferências de anúncios	A API Protected Audience oferece uma maneira de desativar ou bloquear por sites de anunciantes ou uma maneira de sair de todos os grupos de interesse do mesmo proprietário?	Os usuários podem bloquear o acesso à API Protected Audience e a outros recursos do Sandbox de privacidade de várias maneiras.
Política de mesma origem para o URL de origem de scripts de lances e leilões	A exigência de que todos os campos que especificam URLs para carregar scripts ou JSON precisam ter a mesma origem do proprietário foi relaxada.	Estamos considerando essa solicitação e agradecemos mais feedback do ecossistema.
`forDebuggingOnly`	Possibilidade de uso indevido de `forDebuggingOnly .reportAdAuctionWin` se ele permanecer após o 3PCD.	Nos últimos anos, recebemos feedback do ecossistema sobre lacunas de funcionalidade na API Protected Audience depois que os cookies de terceiros foram descontinuados. Estamos trabalhando para formular um plano de suporte a ela após a 3PCD sem comprometer as metas do Sandbox de privacidade. Aceitamos sugestões e feedback sobre funcionalidades que o ecossistema gostaria de ver.
Vários grupos de interesse	Use vários grupos de interesse no mesmo lance.	Isso não é compatível com a API Protected Audience no momento, porque resultaria em uma mudança no modelo de privacidade. Outras discussões são bem-vindas.
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 têm suporte no Chrome para Android.
(Relatórios do 2º trimestre de 2023) Dados relacionados a cliques	Adicione dados relacionados a cliques às informações do navegador.	Continuamos avaliando esse pedido de recurso e agradecemos mais feedback sobre por que ele deve ser priorizado.
Provedores de ambiente de execução confiável	Existem diferenças significativas nas ofertas do ambiente de execução confiável de diferentes provedores de nuvem?	Não temos conhecimento de diferenças significativas, mas recomendamos que o sistema de ecossistema analise os guias de implantação pública para saber qual solução é mais adequada às necessidades. Google Cloud. AWS.
(Reported in previous quarters ) Suporte para segmentação por grupo de interesse negativa	Uma API para oferecer suporte à segmentação por grupo de interesses negativa: exibir anúncios somente se o usuário não pertencer a um grupo de interesses.	Estamos analisando a implementação desse recurso e discutindo a solicitação.
Violação de conteúdo	Oferecer suporte a recursos que permitem que os usuários denunciem anúncios inválidos veiculados pela API Protected Audience em frames restritos.	Acreditamos que o mecanismo de relatórios de anúncios de moldura restrita oferece boas opções para tecnologias de publicidade que querem um fluxo de relatórios de "Anúncios indesejados" gerado pelo usuário. Isso permitiria que os anúncios inadequados fossem informados de uma forma essencialmente inalterada em relação ao padrão atual do setor. Aceitamos outras solicitações de recursos se ainda houver lacunas, inclusive durante o período após a remoção de cookies de terceiros, mas antes que a renderização do frame limitado se torne mais comum.
Relatórios da API Private Aggregation	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 a recência conforme definido em pull/639.
Servidor de k-anonimato	Mais informações sobre o servidor de k-anonimato.	Compartilhamos mais informações sobre servidores de k-anonimato aqui e agradecemos mais feedback.
URLs de criativos dinâmicos	Compatibilidade com URLs de criativos sem pré-declaração, mas respeitando o k-anonimato.	Estamos discutindo esse pedido de recurso e agradecemos mais feedback sobre por que ele deve ser priorizado.
Requisito de k-anonimato	O requisito de k-anonimato nas atualizações do grupo de interesse será reintroduzido?	Não esperamos mudanças na posição indicada nesta postagem do GitHub. Como anunciado nessa postagem, decidimos remover a regra de k-anonimato nas atualizações de grupo de interesse da API Protected Audience, que não tem um impacto significativo nas proteções de privacidade geral da API. Planejamos considerar outras proteções mais diretas (como a privacidade do endereço IP ou um servidor de atualização confiável) em uma data posterior, quando as tecnologias relacionadas forem mais desenvolvidas, implantadas e adotadas.
Teste Beta dos serviços de lances e leilões	Quando o teste Beta dos serviços de lances e leilões vai começar?	Conforme informado na linha do tempo e cronograma, a primeira fase dos testes de serviços de lances e leilões começa em novembro de 2023.
Roadblocking	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 este caso de uso e queremos entender se mais adtechs têm interesse em oferecer suporte a ele. Agradecemos seu feedback.
Publicidade nativa	Suporte a frame restrito para publicidade nativa.	Estamos considerando oferecer suporte ao caso de uso e discutindo possíveis soluções e alternativas.
K-anonimato	Como posso maximizar os anúncios de grupo de interesses que atendem aos limites de k-anon?	Compartilhamos algumas orientações práticas sobre esse assunto.
Suporte a POST	Suporte para envio de dados de leilão por solicitações POST.	Estamos avaliando esse pedido de recurso e aceitamos envios de problemas do GitHub sobre por que ele deve ser priorizado.
Granularidade dos relatórios	Qual é a granularidade dos relatórios de anúncios com moldura cercada e anúncios compostos por várias partes?	O design atual não permite capturar o ID ou a posição do produto, pois isso pode comprometer a privacidade do usuário. Somente o `reserved.top_navigation` pode ser invocado, o que seria enviado quando houver uma ativação do usuário (como um clique) no frame cercado do componente do anúncio, o que resulta em uma navegação de nível superior.
Leilão de anúncios	Um SSP que participa de um leilão de componente pode acionar outro leilão de componente?	Um `componentSeller` não pode incluir `componentAuctions`. O leilão de vários vendedores tem apenas dois níveis: 1. O componente é leiloado em paralelo. 2. O leilão de nível superior (em que o anúncio vencedor de cada `componentAuction` compete).
Disponibilidade dos serviços de lances e leilões	Os lances e o leilão vão estar disponíveis durante a fase de teste facilitada pelo 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 lance.	Estamos discutindo essa solicitação e agradecemos mais feedback sobre por que ela deve ser priorizada.
`generateBid()`	Capacidade de atualizar o `userBiddingSignals` do interestGroup usando `updateURL`.	Estamos considerando essa proposta e agradecemos mais feedback e discussão.
Tipos de inventário do editor	Quais tipos de inventário do editor vão ter suporte para os testes do Protected Audience e do TOPICS?	Nem a Protected Audience nem os tópicos são inerentemente restritivos 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 o SSP e o DSP não é necessária se o DSP não precisa processar indicadores contextuais no próprio servidor para transmitir essas informações processadas para a função de lances no dispositivo.
Um campo `bid_currency` em B&A	Suporte ao campo `bid_currency` no serviço de lances e leilões.	O B&A ainda não oferece suporte a `bid_currency`, mas planejamos oferecer esse suporte até o final de janeiro de 2024. Consulte o cronograma aqui.
`perBuyerSignals`	Há um limite de tamanho para `perBuyerSignals`?	Não há limite para o número de indicadores por comprador, mas o envio de muitos dados pode ter efeitos prejudiciais no desempenho do navegador.
Casos de uso entre sites	É possível 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 considerando essa solicitação e agradecemos mais feedback sobre ela.
Controle de qualidade do anúncio	Perda do controle de qualidade do anúncio relacionada a informações entre sites.	Estamos considerando esse feedback e agradecemos outros comentários.
Chrome DevTools	As solicitações de rede da API Protected Audience devem aparecer na guia "Rede" das Ferramentas para desenvolvedores do Chrome.	Estamos trabalhando para ativar essa funcionalidade na guia de rede e aguardamos seu feedback sobre por que isso deve ser priorizado.
Ambiente de execução confiável	Quando os detalhes sobre quais métricas afetam a privacidade (e o grau de impacto) serão adicionados à explicação sobre o monitoramento do ambiente de execução confiável?	Estamos atualizando o texto explicativo com essas informações. A explicação atualizada vai estar disponível em novembro de 2023.
`directFrom SellerSignals`	Por que `directFrom SellerSignals` não é empacotado como um pacote da Web?	Confira o motivo dessa decisão.
Delegação de impressões	Existe alguma maneira viável de fazer a delegação de impressões em que o resultado de um grupo de interesse selecionado é 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 frame restrito, nossas metas de privacidade para a API Protected Audience incluem a renderização do criativo resultante sem conhecimento do contexto: o URL da página ao redor ou o cookie próprio são uma violação de privacidade. Nesse ambiente, um leilão aninhado não é viável. Em segundo lugar, o modelo de público-alvo protegido diz que o vencedor de cada leilão precisa ser baseado nos dados de apenas um site adicional. Os leilões aninhados seriam uma forma de aumentar isso, resultando na possibilidade de escolher anúncios com base em um perfil de vários sites.
Critério de dados em repouso	Explique melhor o critério de dados em repouso no modelo de confiança de serviço chave-valor.	Os dados no serviço de chave-valor são carregados na memória e veiculados a partir dela, em vez de fazer armazenamento em cache de leitura.
Indicador de dados do comprador	Há um limite de tamanho definido para os sinais `buyer_data` recebidos dos DSPs?	No momento, não há limites impostos pelo navegador para os sinais `buyer_data` recebidos dos 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.	A interoperabilidade entre dispositivos apresenta novos desafios de privacidade além do 3PC e também adiciona desafios de distribuição de tecnologia devido à variedade de dispositivos e plataformas que um usuário pode usar. Estamos analisando possíveis soluções, mas estamos focados nos casos de uso essenciais atualmente aceitos pelos Relatórios de atribuição e não temos planos de introduzir o suporte entre dispositivos antes da remoção de cookies de terceiros.
(Também informado em trimestres anteriores) Tamanho dos dados do acionador	Por que o tamanho dos dados do acionador é limitado a três bits?	O tamanho é limitado a 3 bits e 8 valores distintos para garantir que a quantidade de informações 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	Informe vários domínios que foram usados na conversão.	Esse caso de uso é possível desde a adição de vários destinos. Agradecemos mais feedback.
Suporte ao mesmo domínio em diferentes países	Os relatórios de atribuição funcionam 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 questão. Se uma adtech precisar usar vários TLDs de país, ela vai precisar ter várias inscrições, com uma para cada TLD de país.
Relatórios de público-alvo protegido e atribuição	As adtechs podem acessar as conversões de visualização dos leilões da Protected Audience e as conversões de clique do Relatório de atribuição?	Sim, o Sandbox de privacidade precisa oferecer suporte a VTCs e CTCs na API Protected Audience.
Atrasos nos relatórios agregáveis	Reduzimos ainda mais os atrasos nos relatórios agregáveis.	Recebemos feedback recente sobre isso e compartilhamos ideias aqui. Queremos receber mais feedback do ecossistema.
Atrasos nos relatórios agregáveis	Redução de atrasos com a introdução da mediação do servidor.	Estamos considerando essa proposta e agradecemos o feedback .
Atrasos nos relatórios de eventos	Reduza os atrasos nos relatórios de eventos.	A proposta flexível completa no nível do evento, descrita em Configurações flexíveis no nível do evento, pode reduzir os atrasos nos relatórios no nível do evento para até uma hora com um ruído.
Origem de relatórios de origem por origem	A limitação do número máximo de origens de relatórios por site de origem impede que as adtechs registrem fontes de diferentes origens de relatórios para uma única origem do editor.	Isso foi discutido com a parte interessada que levantou o problema, e uma possível solução de usar uma origem de relatório por site de origem de relatório está sendo testada antes de tentar outras soluções potenciais que envolvam redirecionamentos. Também estamos abertos a qualquer outro feedback do ecossistema sobre esse limite.
Relatórios de problemas	Como podemos informar erros ou problemas com a API Attribution Reporting para o Chrome?	No momento, recomendamos que as adtechs relatem qualquer erro da API Attribution Reporting como um problema no GitHub. Se o problema for relacionado ao Chrome, recomendamos criar um bug do Chromium. Os links de como e onde sinalizar problemas podem ser encontrados em Interagir e compartilhar feedback.
Desduplicação	Como podemos eliminar a duplicação de conversões em diferentes pipelines e dispositivos?	A eliminação de redundância em dispositivos e pipelines de medição é um desafio conhecido e atual que as adtechs enfrentam hoje com 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 elas usaram para rastrear as conversões (ou seja, parte da chave de agregação), que podem ser comparadas com outros pipelines de medição. Estamos abertos a qualquer outro feedback sobre o ecossistema.
Eliminação de duplicação e prioridade	Solicite prioridade antes da eliminação de duplicação.	Estamos considerando essa solicitação e agradecemos o feedback.
Antifraude	Risco de usuários mal-intencionados adulterarem os dados do evento.	A verificação de relatórios não funciona para relatórios de eventos pelos motivos descritos em Por que isso não oferece suporte a relatórios de eventos?.
Tipo de conversão	Como podemos diferenciar visualização com clique e navegação nos relatórios de atribuição?	Temos a seguinte opção de filtragem integrada: `source_type`. Confira mais detalhes 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 em casos de falhas, erros ou exclusões.	A equipe está buscando maneiras de resolver esse problema sem comprometer a privacidade.
Registro do site	Várias adtechs solicitaram suporte para processar várias origens na mesma conta para casos de uso, como dividir dados por geografia ou anunciante. Esse comportamento também é esperado pelas adtechs, já que a inscrição na API do cliente agora é baseada no site (e não na origem). A migração da origem para a inscrição no site simplifica a integração de tecnologias de publicidade com a consistência do processo de inscrição do cliente.	Em breve, vamos lançar a migração da inscrição de origem para a inscrição de site para o serviço de agregação. Aguardamos o feedback do ecossistema.
Plano de lançamento e descontinuação	Cronograma de lançamento e descontinuação de recursos e patches do serviço de agregação publicados. O objetivo do plano é dar às adtechs visibilidade sobre nossas políticas de lançamento para que elas possam se preparar para os próximos lançamentos e descontinuações e 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. Aguardamos seu feedback.
Coordenadores	O que acontece se os coordenadores forem desativados no 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 qualquer um dos dois coordenadores fará com que os jobs de agregação falhem. Os jobs podem ser executados novamente se o orçamento de privacidade ainda não tiver sido consumido. No caso de falhas no serviço que resultem no consumo do orçamento sem um relatório de resumo gravado no armazenamento de adtechs, recomendamos que você use relatórios de depuração para recuperar resultados usando a ferramenta de testes locais. Também estamos trabalhando em recursos para permitir a recuperação do orçamento em caso de falhas, para que as adtechs possam executar os jobs novamente.

API Private Aggregation

Tema do feedback	Resumo	Resposta do Chrome
Url do blob	Solicitação de suporte a URL de blob no armazenamento compartilhado.	O suporte a Blob Url foi adicionado no Chrome M116.

Limitar o rastreamento oculto

Redução de user agent e dicas de cliente HTTP do user agent

Tema do feedback	Resumo	Resposta do Chrome
JavaScript API	Disponibilidade da API JavaScript User Agent Client Hints.	Não há planos para remover essa funcionalidade, já que ela é a 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 sobre o dispositivo e o formato	Capacidade de sites entenderem entradas, saídas e outras informações que o dispositivo que visita o site pode oferecer.	Adicionamos suporte a essa solicitação após recebermos feedback do ecossistema.

Proteção de IP (anteriormente Gnatcatcher)

Tema do feedback	Resumo	Resposta do Chrome
Tráfego de terceiros qualificado	A que se refere "tráfego de terceiros qualificado" na explicação?	Entendemos a importância dessa pergunta e estamos trabalhando ativamente para identificar qual tráfego de terceiros será qualificado e qual não será. Queremos saber sua opinião sobre esse assunto.
Auditorias de tráfego de rede	Suporte para que as empresas realizem auditorias de tráfego de rede nas redes delas.	Somente o tráfego de terceiros incorporado em sites próprios será afetado, o que deve limitar a quantidade de tráfego que exige filtragem. Além disso, planejamos dar aos usuários a opção de usar ou não a Proteção de IP. Para o Chrome controlado pela empresa, haverá políticas corporativas para desativar a Proteção de IP. Por fim, estamos analisando quais controles (se houver) serão fornecidos aos operadores de rede para desativar a Proteção de IP. Queremos saber sua opinião sobre esse assunto.
Controle de acesso	A Proteção de IP pode afetar os 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. Estamos buscando feedback do ecossistema sobre como oferecer melhor suporte a casos de uso de proteção contra fraudes que geralmente dependem de endereços IP.
Comunicação entre os proxies de dois saltos	Como garantir que não haja informações entre os proxies.	Estamos projetando as interações de proxy. Nosso objetivo é minimizar as chances de compartilhamento de informações por meios comerciais, processuais e técnicos.
Autenticações de terceiros	Suporte para autenticações que não são do Google.	Planejamos publicar mais detalhes sobre a autenticação de contas no futuro, mas já compartilhamos algumas considerações iniciais.
Classificação do rastreador	Como a Proteção de IP vai determinar o que constitui um rastreador e suas variantes?	Entendemos a importância dessa pergunta e estamos trabalhando ativamente para identificar qual tráfego de terceiros será qualificado e qual não será. Queremos saber sua opinião sobre esse assunto.
Analytics	A proteção de IP pode afetar a precisão dos serviços de análise.	Queremos entender melhor o impacto da proteção de IP e agradecemos mais feedback e exemplos do ecossistema.
Proxy	Se um usuário estiver usando um proxy ou tiver definido um manualmente, como a máscara de IP vai funcionar nesse caso?	Estamos tentando entender o impacto que a Proteção de IP pode ter em outros proxies. Não temos planos para compartilhar no momento. Agradecemos seu feedback sobre esse tema.
Oferta premium	A proteção de IP será um recurso pago?	A Proteção de IP vai estar disponível para os usuários do Chrome como parte da experiência principal do navegador. Ele não será um recurso pago.
Servidor proxy	Os mesmos servidores de proxy serão usados durante as sessões do usuário?	Uma conexão HTTP/S vai 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 diferentes conexões HTTP/S que precisam usar os mesmos servidores.
Suporte a plataformas	Em qual plataforma a Proteção de IP será compatível?	A Proteção de IP vai estar disponível inicialmente no Chrome para Android e computador. Continuamos avaliando como expandir a proteção para outras plataformas.
Desativar	Os usuários poderão desativar a Proteção de IP?	Planejamos dar aos usuários a opção de usar ou não a Proteção de IP.
Anonimização	Quais tipos de solicitações serão anonimizados na Proteção de IP?	As solicitações HTTP/S e DNS para domínios de terceiros qualificados são anônimas pelos proxies de privacidade. Vamos dar mais detalhes em um próximo artigo explicativo sobre como vamos determinar 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 de dados	Os endereços de rede podem ser acessados durante o primeiro salto na proteção IP.	No modelo de proxy de dois saltos, o primeiro salto (controlado pelo Google) só encontra o IP do cliente de origem e uma solicitação para se conectar ao segundo salto, enquanto o segundo salto (controlado por um CDN externo) só encontra uma tupla no primeiro salto (IP do proxy + porta) e o 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. O primeiro salto apenas retorna a resposta ao cliente, sem saber nada sobre o IP de destino. Dessa forma, o primeiro salto só aprende o IP do cliente e o segundo salto, enquanto o segundo salto só aprende o IP de destino.
WebView	A Proteção de IP vai estar disponível para o WebView do Android no futuro?	No momento, não temos planos para compartilhar, 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 rastreadas?	As mitigações de rastreio por redirecionamento rastreiam dois tipos de interações do usuário: Ativações do usuário, conforme definidas pela especificação de HTML. São basicamente cliques, pressionamentos de tecla, toques na tela touchscreen etc. Afirmações webauth bem-sucedidas. São casos em que um usuário toca em uma chave de segurança ou usa uma chave de acesso como forma de autenticação. 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 o etld+1 sem esquema e o horário da interação. As interações protegem o domínio associado da exclusão do estado de mitigação do rastreamento de rejeição por 45 dias.
Isenções na lista de permissões	É possível isentar domínios?	Estamos considerando essa solicitação e agradecemos o feedback do ecossistema.

proposta de orçamento de privacidade

Nenhum feedback recebido neste trimestre.

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
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 de RWS, porque ele oferece responsabilidade 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 adequado para o acesso automático a cookies de terceiros.
Renomear 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 servir um arquivo JSON em `/.well-known/related-website-set.json`. Não é necessário mudar os conjuntos na lista de RWS, mas, se houver modificações enviadas para conjuntos atuais, o arquivo JSON precisará ser alterado.
(Também informado nos trimestres anteriores) Limite de domínio	Pedido para expandir o número de domínios associados	Como anunciado em uma postagem do blog em 31 de agosto, aumentamos o limite de domínios associados para cinco após recebermos 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 importante.
Cookies de terceiros	Os conjuntos de sites relacionados vão funcionar apenas com cookies de terceiros desativados?	Os conjuntos de sites relacionados funcionam mesmo quando um usuário não bloqueou cookies de terceiros. No entanto, não há efeito observável, já que os cookies relevantes estão disponíveis sem a necessidade de conjuntos de sites relacionados e da API Storage Access.
Edições legítimas	Como o repositório de conjuntos de sites relacionados impede que pessoas que não são proprietárias 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 (passar validações técnicas e assim por diante), ele será mesclado manualmente em lotes à lista canônica de FPS uma vez por semana (às terças-feiras às 12h, horário oriental) pelo Google. Se um invasor tentar modificar um conjunto que não é dele, não haverá problema, já que ele não poderá modificar os arquivos `.well-known` e, portanto, as validações vão falhar.
Domínio invadido	O sequestro de domínio pode expor dados relacionados a domínios a partes não autorizadas.	Isso não é possível, conforme discutido neste problema do GitHub da Protected Audience.

API Fenced Frames

Tema do feedback	Resumo	Resposta do Chrome
Violação de conteúdo	Permitir que os usuários denunciem anúncios suspeitos.	Os frames restritos não impedem a denúncia de anúncios suspeitos. Os usuários ainda podem interagir com o anúncio e denunciar anúncios suspeitos para a adtech da maneira usual.
Interação com sites próximos	Permitir a interação com o site de nível superior ou ao redor.	Estamos tentando entender por que esse pedido é necessário e agradecemos o feedback do ecossistema.
Publicidade nativa	Suporte a frame restrito para publicidade nativa.	Estamos considerando oferecer suporte ao caso de uso e discutindo possíveis soluções e alternativas.

API Shared Storage

Tema do feedback	Resumo	Resposta do Chrome
Entre domínios	Permitir a comunicação entre domínios para armazenamento local.	No momento, esse caso de uso não está alinhado com os gates de saída que preservam a privacidade do Shared Storage, mas aceitamos mais contexto conforme desenvolvemos propostas para armazenamento não particionado.
Url do blob	Solicitação de suporte a URL de blob no armazenamento compartilhado.	O suporte a Blob Url foi adicionado no Chrome M116.

CHIPs