Sandbox de privacidade para Web: o cenário de privacidade em mudança e o impacto em seus sites

O Chrome fará alterações de privacidade por meio da iniciativa Privacy Sandbox ao longo de 2023, enquanto cria novas tecnologias para manter as informações do usuário privadas. Simultaneamente, os editores da web e as marcas estão mudando sua estratégia digital para ajudar a preservar a receita de anúncios e valiosas análises de marketing que dependem de cookies de terceiros.

Esse impulso em direção à privacidade expandida do navegador está gerando mais demanda por personalização de sites.

Nesta sessão, Sam Dutton, advogado do desenvolvedor do Google, analisa as mudanças que estão por vir, compartilha as metas da iniciativa Sandbox de privacidade e ajuda você a entender melhor como girar para garantir que tenha os dados necessários para ajudar a manter seus negócios e sites seguindo em frente.

Diapositivos da Sessão:

Transcrição:

SAM DUTTON: Olá, sou Sam Dutton. Sou um Developer Advocate da equipe Chrome baseada aqui em Londres. Muito obrigado por se juntar a mim hoje. Três coisas que farei nos próximos 25 minutos. Apresentarei uma visão geral das APIs do Privacy Sandbox. Explicarei o que você precisa fazer agora e mostrarei como você pode se tornar um testador e participar da discussão das APIs e fornecer feedback.

Deixe-me começar explicando por que precisamos do Privacy Sandbox. Muitos de vocês conhecem muito bem a história por trás, mas vale a pena reiterar rapidamente por que precisamos disso e como chegamos onde estamos hoje. Assim, o Privacy Sandbox é uma iniciativa para ajudar a construir um conjunto de APIs de preservação da privacidade para dar suporte a modelos de negócios que financiem a web aberta para um futuro sem mecanismos de rastreamento como cookies de terceiros.

Agora você deve ter visto este exemplo do Google I/O. É um site típico com componentes de diferentes origens. E, claro, a capacidade de composição é um dos superpoderes da web. Você tem um mapa de uma origem, algum roteiro de outra e assim por diante e, claro, publicidade e, gostemos ou não, e o que quer que o futuro reserve, a publicidade tornou-se uma fonte crucial de receita e um impulsionador de negócios no rede.

Agora, neste ponto da história, acho que navegadores e CMSs precisam oferecer suporte a casos de uso de publicidade. Então qual é o problema? Bem, seleção de anúncios, medição de conversão, detecção de fraude, personalização de dispositivos, muitos outros casos de uso dependem da identidade entre sites usando mecanismos que simplesmente não foram criados com a privacidade em mente.

Agora, não apenas cookies de terceiros, mas impressões digitais são usadas para rastrear o comportamento do usuário em sites ou outros sites solicitam informações pessoais, como endereços de e-mail e, além disso, os ecossistemas de terceiros são realmente complexos, especialmente para publicidade. Nem mesmo desenvolvedores, anunciantes ou editores entendem a cadeia de suprimentos de serviços de terceiros.

Certamente, quando visito um site, não estou ciente de todos os terceiros envolvidos e do que eles estão fazendo com meus dados e não sou apenas eu, a pesquisa mostra que as pessoas realmente se preocupam em controlar seus dados. As preocupações com a privacidade impulsionam cada vez mais as escolhas sobre o que as pessoas fazem online e os reguladores em todo o mundo estão intensificando os requisitos de privacidade, e isso está acontecendo muito rapidamente.

Portanto, considerando quantas empresas dependem de publicidade on-line eficaz e quantos editores dependem de publicidade para monetizar seus sites e vários outros casos de uso, esse é um problema para todo o ecossistema da Web e não apenas para empresas de tecnologia e plataformas de anúncios. Mas é claro que, como a web é uma plataforma aberta, as propostas de mudança precisam de aceitação e feedback, e navegadores como o Chrome não podem e não querem agir unilateralmente.

Os navegadores não são produtos para os quais os fornecedores de navegadores podem tomar decisões isoladamente e a realidade é que a web não foi projetada para muitos dos requisitos que são essenciais para a plataforma hoje para detecção de fraude publicitária, gerenciamento de identidade e todos esses outros requisitos, casos de uso e breve. Então, o que precisamos é de tecnologias criadas especificamente para esta web focada em privacidade, e é aí que entra o Privacy Sandbox.

Portanto, o Chrome tem trabalhado com a comunidade da web junto com as partes interessadas e reguladores do setor para desenvolver novas tecnologias de preservação da privacidade que possam oferecer suporte a um ecossistema saudável e sustentável. Agora, uma vez que essas novas APIs criadas especificamente estejam disponíveis, precisamos garantir que as empresas tenham tempo para adotá-las para que possamos eliminar com segurança o suporte para cookies de terceiros no Chrome e continuar nosso trabalho para mitigar outros tipos de rastreamento.

Agora, o conjunto básico de princípios para esta iniciativa é o modelo de privacidade potencial para a web, e isso foi desenvolvido por especialistas em privacidade e cientistas da computação do Google. Esse modelo de privacidade estabelece um conjunto de regras básicas para projetar tecnologias que atendam aos casos de uso da plataforma da Web sobre os quais falei, ao mesmo tempo em que atendem às nossas necessidades de privacidade em constante mudança.

Em particular, a proposta aborda a difícil questão de como permitir conexões entre sites sem comprometer a privacidade. Agora, uma das principais inovações das APIs do Privacy Sandbox é permitir que o navegador atue em nome do usuário, de certa forma voltando ao papel principal do navegador como o que chamamos de agente do usuário.

Com as tecnologias atuais, os dados são coletados, agregados e compartilhados por terceiros para rastrear a navegação do usuário nos sites. As APIs Sandbox de privacidade podem permitir que a medição de conversão de leilões de anúncios e essas outras tarefas sejam realizadas pelo navegador do usuário no dispositivo do usuário.

Portanto, precisamos reconstruir as plataformas de anúncios e a Web com a colaboração de fornecedores de navegadores, plataformas, anunciantes, editores adtech, usuários, reguladores e a comunidade de privacidade, além de desenvolvedores como você que trabalham com plataformas CMS.

Então, com tudo isso em mente, eu só quero dar a você um tour pelas próprias APIs do Privacy Sandbox. Portanto, no Google, essa é uma iniciativa compartilhada na Web e no Android. O Privacy Sandbox no Android está focado na introdução de novas soluções de publicidade mais privadas sem identificadores entre aplicativos.

A web e o Android, é claro, compartilham os mesmos princípios e várias das propostas da web estão sendo desenvolvidas também para Android. No entanto, é claro, as plataformas móveis da Web e do Android dependem de tecnologias fundamentalmente diferentes.

Portanto, esta é uma iniciativa distinta no Android, mas é algo que aqueles de vocês que criam aplicativos para Android e também trabalham na Web devem ficar de olho nisso. Portanto, o Google está testando as novas APIs em colaboração com vários parceiros em todo o mundo.

Centenas de empresas participando de fóruns públicos, seja o W3C, explicam os problemas no GitHub e assim por diante, publicando perspectivas e análises e participando de mesas redondas do setor, compartilhando feedback com Chrome e Android e, claro, participando de testes.

Agora não se engane, o Privacy Sandbox tem muitos requisitos para cobrir e vai ser difícil ao longo do caminho. Quer dizer, acho que a boa notícia é que no final de tudo isso teremos plataformas mais seguras e privadas para os usuários e melhores para anunciantes, editores, desenvolvedores e claro, para plataformas como o WordPress.

Portanto, não vou descrever todas as APIs do Privacy Sandbox. Em vez disso, gostaria de focar nas três principais APIs de publicidade no Privacy Sandbox. São Tópicos, FLEDGE e Relatórios de Atribuição. Nossos Tópicos e FLEDGE são conhecidos como APIs de relevância.

O Now Topics fornece sinais de alto nível do interesse de um usuário com base em seu histórico de navegação recente. E os tópicos podem ser combinados com sinais contextuais e dados próprios para selecionar anúncios relevantes.

E o FLEDGE oferece suporte a casos de uso de remarketing e público personalizado mais granulares em que os profissionais de marketing desejam alcançar públicos que demonstraram interesse em sites ou produtos específicos, mas é claro, para tornar isso possível preservando a privacidade.

Por fim, o Attribution Reporting é a proposta do Chrome para a medição de campanha com preservação da privacidade, fornecendo relatórios de desempenho anônimos e quando as pessoas visualizam ou clicam em um anúncio e, posteriormente, concluem uma compra ou algum outro tipo de conversão.

Portanto, essas APIs passaram por um período de teste no Android e no Chrome no desktop e no celular. Se você estiver trabalhando com plataformas de tecnologia de anúncios, precisará entender os planos dessas plataformas para abordar esses casos de uso e os casos de uso que estão sendo atendidos por essas APIs para este futuro sem cookies de terceiros ou outros mecanismos de rastreamento.

Então, agora tivemos um período de testes técnicos com as APIs ativadas usando sinalizadores do Chrome e agora no teste de origem inicialmente ativado apenas para uma pequena porcentagem de usuários do Chrome inicialmente. Portanto, agora que estamos neste estágio de teste de utilidade, 50% dos usuários beta e desenvolvedores do Chrome Canary têm as APIs de teste de origem de anúncios ativadas em páginas que fornecem um token válido e 5% dos usuários estáveis.

Agora, essa é uma pequena porcentagem do tráfego geral do Chrome, é claro, mas é suficiente para testes limitados das APIs com usuários reais. E agora estamos avançando para o lançamento no Chrome Stable, onde as APIs estarão disponíveis para todos os usuários por padrão. Voltarei aos cronogramas para isso mais tarde.

Então, só para reiterar, para um único usuário, você pode ativar as APIs usando sinalizadores do Chrome, mas para testes em escala, você precisa participar do teste de origem do Privacy Sandbox e compartilharei os links mais tarde para orientação sobre como fazer tudo isso .

A propósito, o Chrome também está atualizando os controles de privacidade do usuário, como a interface do usuário para isso. E os controles do Sandbox de privacidade estão realmente disponíveis como parte do teste de origem das APIs de anúncios. As pessoas poderão ver e gerenciar os interesses associados à sua navegação ou desativar totalmente as APIs.

Portanto, na verdade, existem três outras tecnologias de Sandbox de privacidade que eu acho que você também pode querer testar ou certamente sinalizar para qualquer um de seus provedores terceirizados. Em primeiro lugar, CHIPS. Isso é cookies com estado de partição independente permite que os desenvolvedores optem por um cookie para armazenamento particionado com um jarro de cookies separado por site de nível superior.

Conjuntos de primeira parte permitem que nomes de domínio relacionados pertencentes e operados pela mesma entidade se declarem como pertencentes à mesma primeira parte e tokens de estado privado. Você pode ter ouvido falar desse nome inicial como Trust Tokens. Esta é uma API para transmitir uma quantidade limitada de informações de um contexto de navegação para outro, por exemplo, entre sites para ajudar a combater fraudes, mas sem usar técnicas de rastreamento passivo.

Então, primeiro, vamos dar uma olhada mais profunda na API Topics. A API de tópicos fornece um mecanismo para habilitar a publicidade baseada em interesses, mas sem permitir que terceiros rastreiem a atividade de navegação do usuário. Portanto, a API tem três componentes principais e, primeiro, a publicidade baseada em interesses precisa de uma taxonomia de tópicos de interesse.

A taxonomia da API de tópicos tem esta aparência. É uma lista de tópicos legível por humanos, mantida publicamente, que evita tópicos delicados. E agora é provável que isso mude e se desenvolva ao longo do tempo em consulta com o ecossistema da web e isso significa que pessoas como você, precisamos do seu feedback sobre isso e tudo mais.

Portanto, a API de tópicos precisa inferir os interesses de um usuário com base em sua atividade de navegação, mas, como eu disse, fazer isso de maneira a preservar sua privacidade. Portanto, os principais tópicos de interesse são registrados para um usuário em seu navegador em seu dispositivo com base em sua atividade de navegação recente novamente, pelo navegador em seu dispositivo.

Atualmente, o Topics faz isso usando o aprendizado de máquina para mapear os nomes de host das páginas que o usuário visita para o Topics da taxonomia. Agora, como acontece com a própria taxonomia de Tópicos, essa abordagem se desenvolverá com o tempo. Mas inferir interesses da atividade de navegação precisa acertar o equilíbrio.

Se você tiver muitos detalhes sobre a navegação do usuário, isso é ruim para a privacidade, mas pouca granularidade significa que a API não é útil. Acho que, de certa forma, o principal a entender aqui é que os tópicos de interesse são apenas um sinal para encontrar o que é relevante para os usuários.

Portanto, agora que os tópicos de interesse foram inferidos pelo navegador para um usuário, Tópicos precisa fornecer aos chamadores da API acesso aos tópicos de interesse que eles observaram para o usuário.

Assim, conforme o usuário navega na Web, há dois estágios na API. Um chamador de API, pode ser uma plataforma adtech, por exemplo, chama a API em uma página para sinalizar que deseja observar os tópicos da página atual e do usuário atual.

Agora, posteriormente, o chamador da API pode acessar os tópicos que observou para o usuário. Agora tudo isso deve ser feito sem revelar nada mais sobre a atividade de navegação do usuário além dos tópicos de interesse que foram observados.

Portanto, a API Topics fornece duas maneiras de observar tópicos de interesse de um usuário e, em seguida, obter acesso a esses tópicos observados, primeiro com uma API JavaScript ou usando os cabeçalhos de solicitação e resposta em uma solicitação de busca.

A primeira maneira de um chamador da API de tópicos sinalizar ao navegador que observou tópicos para um usuário é chamar document.browsingTopics de um iframe incorporado nos sites que o usuário visita.

Agora, posteriormente, o chamador da API pode chamar o mesmo método document.browsingTopics para acessar os tópicos que observou para o usuário atual. A propósito, a razão pela qual esse método precisa de um iframe é que o contexto para observar os tópicos deve ser o mesmo que o contexto para acessar os tópicos.

A outra maneira de observar e acessar os tópicos é usar cabeçalhos de busca, solicitação e resposta. Primeiro, o chamador da API precisa fazer uma solicitação de busca para uma URL em sua origem, incluindo o objeto true de tópicos de navegação no parâmetro de opções.

E se a resposta à solicitação de busca incluir um cabeçalho Observe-Browsing-Topics ?1, bem, isso indica ao navegador que o chamador deseja que o navegador registre que o chamador observou os tópicos de interesse do usuário atual para o página. Espero que faça sentido.

Agora, os tópicos observados para um usuário podem ser recuperados da solicitação de busca de um chamador, acessando o cabeçalho da solicitação sec-browsing-topics. Então aqui está todo o processo do início ao fim. Estou ciente do tempo, então não vou passar por isso agora, mas compartilharemos isso mais tarde para que você possa ver como isso funciona, todo o processo e teremos isso para cada uma das APIs.

E você pode experimentar a demonstração Topics que usa o método JavaScript iframe para observar e acessar tópicos ou pode experimentar nossa demonstração que usa a abordagem de cabeçalho de solicitação de busca. chrome://topics-internals exibe tópicos para o usuário atual, tópicos conferidos para nomes de host e informações técnicas sobre a implementação da API.

Você também pode executar o co-laboratório de tópicos para testar a inferência de tópicos usando o modelo classificador de tópicos. Agora, três grandes questões em aberto para você antes de deixar Tópicos, como poderíamos fazer um trabalho melhor de inferir tópicos de interesse para um usuário com base em sua atividade de navegação? Como podemos melhorar o conteúdo e a estrutura da taxonomia para torná-la mais útil e, ao mesmo tempo, preservar a privacidade do usuário? E como podemos melhorar a arquitetura geral da API?

Acho que uma coisa a ter em mente aqui é se temos Tópicos ou algo diferente, ainda precisamos atender a seus casos de uso. Em seguida, FLEDGE. Portanto, esta é uma API para opções de anúncios no dispositivo para atender casos de uso de remarketing e público personalizado sem a necessidade de rastreamento de terceiros entre sites.

Acho que há um pouquinho mais de detalhes de código com o FLEDGE porque ele tem um trabalho mais complicado do que o Topics. Portanto, há três partes no processo FLEDGE. Primeiro, o comprador do anúncio adiciona usuários ou navegadores individuais aos chamados grupos de interesse. Eles são como públicos personalizados, mas a participação no grupo de interesse é armazenada no navegador do dispositivo do usuário.

Agora, em algum momento, quando um usuário visita um site que exibe anúncios, como o site de um editor, um vendedor de anúncios pode iniciar um leilão de anúncios para selecionar um anúncio para eles e, com o FLEDGE, esse leilão pode ser executado no dispositivo do usuário.

Para selecionar um anúncio, o código do leilão executa a lógica de lances dos compradores e a lógica do leilão do vendedor. E, por último, o navegador publica relatórios de leilão para pontos finais fornecidos pelos vendedores e compradores.

Então, passo rapidamente pelo FLEDGE passo a passo. Em primeiro lugar, imagine que um usuário visita uma loja de calçados on-line, faz alguma navegação. Uma plataforma adtech ou talvez o próprio anunciante faz uma chamada JavaScript para dizer ao navegador para ingressar em um grupo de interesse. E esse grupo pode ser nomeado algo como Trail Running Shoes.

O objeto de configuração para um grupo de interesse pode ter esta aparência. Neste exemplo, o técnico de anúncios da loja de calçados pode ter um grupo de interesse para remarketing ao qual gostaria de adicionar o usuário, e eles chamaram esse grupo de Trail Running Shoes. E a plataforma adtech da loja de calçados chama o grupo de interesse do anúncio para solicitar que o navegador do usuário participe do grupo de interesse Trail Running Shoes usando a configuração que acabei de mostrar.

E o segundo parâmetro especifica a duração do grupo de interesse que é limitado a 30 dias. Agora o usuário visita um site que publica anúncios. Neste exemplo, um site de notícias. Um leilão para selecionar um anúncio a ser exibido para o usuário é executado em JavaScript no dispositivo do usuário pelo vendedor usando executar leilão de anúncios, e o vendedor provavelmente é uma plataforma de tecnologia de anúncios, mas talvez o próprio editor, neste caso, o site de notícias.

Agora, este leilão seleciona os lances de anúncio mais adequados para cada um dos grupos de interesse ao qual o navegador do usuário pertence, juntamente com outros fatores do vendedor e do próprio navegador.

Agora, olhando para o código, o editor ou uma plataforma que vende espaço de anúncio no site do editor cria dados de configuração para o leilão de anúncios. O vendedor então pede ao navegador para executar um leilão de anúncio para selecionar um anúncio no navegador, e o valor retornado pelo leilão de anúncio executado é passado para um elemento chamado frame cercado para que o site possa exibir o anúncio vencedor.

Agora, um frame cercado pode ser usado para exibir um anúncio, mas não pode interagir com a página ao seu redor. E, então, o vendedor e o comprador vencedor têm a oportunidade de realizar registros e relatórios, e isso é feito chamando navigator.reportresult.

Por fim, o usuário, se tudo correr bem, toca ou clica no anúncio e agora a API de relatórios de atribuição assume o controle. E, novamente, temos um diagrama mostrando todo o processo do início ao fim, que compartilharemos com você após a palestra.

Agora, por último, gostaria de falar um pouco sobre a API Privacy Sandbox para medição de anúncios, que é o Relatório de atribuição. O Relatório de Atribuição é usado para medir quando um clique ou uma impressão de anúncio leva a uma conversão. Por exemplo, quando a visualização de um anúncio em um site de notícias leva a uma compra em uma loja de calçados online.

Agora, assim como no Topics e no FLEDGE, essa API foi projetada para evitar o rastreamento entre sites. Portanto, a API permite dois tipos de resultados de medição, relatórios de nível de evento e relatórios resumidos. Então, deixe-me descrever brevemente como isso funciona.

Primeiro, vamos dar uma olhada nos relatórios de nível de evento. Portanto, os links de anúncios podem ser configurados com atributos específicos da API de relatórios de atribuição e isso possibilita contabilizar visualizações e cliques com uma solicitação no lado da conversão.

Agora, quando um usuário clica em um anúncio ou vê um anúncio e converte, o navegador gera um relatório e, nesse relatório, a empresa de publicidade ou a tecnologia de anúncios inclui dois dados. Primeiro, quaisquer dados que eles desejem sobre o clique ou impressão do anúncio e isso pode ser muito detalhado, por exemplo, um ID de criativo, informações sobre o editor, o registro de data e hora e assim por diante. E segundo, um pequeno dado sobre a conversão do anúncio.

Agora, para proteger a privacidade do usuário, isso não pode ser muito detalhado. Mais tarde, o navegador envia esse relatório sobre– Bem, esse relatório com os dados que acabei de explicar ao técnico de anúncios ou ao anunciante, e isso inclui um atraso para ajudar a evitar o rastreamento do usuário.

O relatório contém dois dados, dados detalhados sobre o clique ou impressão no anúncio, o evento e dados de alto nível sobre a conversão. Portanto, este é um relatório de nível de evento. Agora vamos dar uma olhada nos relatórios de resumo.

Agora, a API do navegador para gerar um relatório resumido é semelhante, mas os resultados e o mecanismo são um pouco diferentes. Então, novamente, quando um usuário clica em um anúncio ou vê um anúncio e depois converte, o navegador gera um relatório e, nesse relatório, a empresa de publicidade ou a tecnologia de anúncios pode incluir quaisquer dados que desejar sobre o clique ou impressão do anúncio e quaisquer dados que eles deseja sobre a conversão do anúncio, mas esse relatório é criptografado.

E esta é uma proteção de privacidade porque este relatório contém dados detalhados sobre a conversão e a impressão. Portanto, o relatório pode ser usado para rastreamento entre sites se não estiver criptografado. Mais tarde, o navegador enviará esse relatório criptografado novamente, com um pequeno atraso.

E, dessa forma, uma plataforma adtech coletará muitos relatórios de muitos usuários e enviará todos os relatórios para um serviço de agregação, como é chamado, e esse serviço agregará todos esses relatórios, descriptografá-los, adicionará algum ruído para proteger a privacidade do usuário e, em seguida, retorna o resultado final e o resultado final é chamado de relatório resumido. Ele contém dados de medição para muitos usuários.

Essa é a medição de atribuição. Espero que faça sentido. Vou criar links para muitos outros recursos para ajudá-lo a entender e testar as APIs do Privacy Sandbox com mais detalhes. Mas uma última coisa que gostaria de mencionar, Privacy Sandcastle.

Esta é uma demonstração que combina todas as principais APIs do Privacy Sandbox. Foi construído por nossa equipe em Tóquio. Ainda é muito novo. Mas você pode obter o código do GitHub e executá-lo localmente, e ele foi projetado para ajudá-lo a entender como todas essas APIs se encaixam.

Antes de terminar, gostaria de fazer uma recapitulação e observar a linha do tempo do Privacy Sandbox. Como você pode ver, estamos nos aproximando do trimestre em que começaremos a enviar as APIs, o que significa que elas estarão disponíveis por padrão no Chrome Stable e prontas para testes em escala de produção. Agora é apenas um curto espaço de tempo no calendário, e eu posso me ver. Estou perto do tempo aqui.

Então, algumas coisas que eu acho que você precisa fazer agora. Em primeiro lugar, entenda os cronogramas para web e Android. Certifique-se de que você e seus provedores terceirizados estejam preparados para as mudanças que agora são iminentes. Em segundo lugar, audite seus sites para entender onde eles dependem de cookies de terceiros e outros mecanismos que estão sendo obsoletos. Compartilharemos links para ferramentas e instruções sobre como fazer isso após o evento de hoje.

Em seguida, pergunte a seus provedores terceirizados, como plataformas adtech e assim por diante, como eles estão se preparando para atender a seus principais casos de uso na ausência de cookies de terceiros ou outros mecanismos de rastreamento entre sites e, por último, teste as APIs do Privacy Sandbox e forneça feedback e peça a seus provedores terceirizados que façam o mesmo.

E se eles não estiverem bem, pergunte-lhes por que não e deixe-nos saber qual é a resposta para essa pergunta. Portanto, o privacysandbox.com fornece cronogramas, perguntas frequentes e mais informações sobre os esforços de plataforma cruzada. Compartilharei URLs após este evento, mas você pode encontrar muito do conteúdo a que me referi aqui na seção Sandbox de privacidade em developer.chrome.com.

Em particular, ele tem recursos que explicam como fazer perguntas para nós e fornecer feedback, e você pode descobrir mais sobre testes de origem em developer.chrome.com. Também criamos uma série de vídeos e artigos curtos para ajudar a explicar os conceitos do Chrome, como testes de origem, sinalizadores do Chrome, conteúdo intermitente e tudo mais.

Obrigado por ouvir. É isso de mim. Como eu disse, se você precisar de suporte, acesse esses recursos ou envie uma mensagem direta para SW12 no Twitter. Muito obrigado.