Terceiros

É bem raro que um site seja totalmente independente. O HTTP Web Almanac mostra que a maioria dos sites (cerca de 95%) tem conteúdo de terceiros.

O Almanaque define conteúdo de terceiros como algo hospedado em uma origem pública e compartilhada que é amplamente usada por diversas de sites e não são influenciados por um proprietário individual do site. Podem ser imagens ou outras mídias, como vídeos, fontes ou scripts. Imagens e scripts representam mais do que tudo o que é somado. Conteúdo de terceiros não é essencial para desenvolver um site, mas também poderia ser. você certamente usará algo carregado de um servidor público compartilhado, sejam fontes da Web, iframes incorporados de vídeos, anúncios ou bibliotecas JavaScript. Por exemplo, você pode estar usando fontes da Web do Google Fonts, ou medir análises com o Google Analytics; você pode ter adicionado botões "Curtir" ou "Fazer login com" de redes sociais; você incorporar mapas ou vídeos ou processar compras por meio de serviços de terceiros; você pode estar acompanhando erros e geração de registros para suas próprias equipes de desenvolvimento com ferramentas de monitoramento de terceiros.

Para fins de privacidade, é útil considerar uma definição ligeiramente diferente e menos ampla: um recurso de terceiros, e, em específico de um script de terceiros, é veiculado a partir de uma origem compartilhada e pública e amplamente utilizado conforme ilustrado, mas também é de autoria por alguém que não seja o proprietário do site. O aspecto da autoria de terceiros é o principal ao considerar como proteger seus dos usuários privacidade das outras pessoas. Isso o levará a considerar quais riscos estão presentes e, em seguida, decidirá como ou se deve usar um recursos de terceiros com base nesses riscos. Como já foi discutido, essas coisas o ajudarão a entender o contexto e para entender quais compensações você precisa fazer e o que elas significam.

Não é bem isso o que significa quando se trata de "recursos de terceiros". em geral: a distinção entre primário e O termo "terceiro" se refere ao contexto em que algo é usado. Um script carregado de outro site é um script recurso, e a solicitação HTTP que carrega o script pode incluir cookies, mas esses cookies não são realmente "cookies de terceiros". eles são apenas cookies e se são de terceiros, ou "própria" depende do carregamento do script em seu site ou uma página no site do proprietário do script.

Por que usamos recursos de terceiros?

Terceiros são uma ótima maneira de adicionar funcionalidade ao seu site. Podem ser recursos expostos aos usuários ou invisíveis funções de desenvolvedor como rastreamento de erros, mas elas reduzem a carga de desenvolvimento e os próprios scripts são mantidos por outra pessoa: a equipe de desenvolvimento do serviço que você está incluindo. Tudo isso funciona devido à composição da Web: ser capaz de unir as partes para formar um todo que seja maior que a soma delas.

O Almanaque da Web do Arquivo HTTP tem uma boa descrição:

Terceiros fornecem um conjunto infinito de imagens, vídeos, fontes, ferramentas, bibliotecas, widgets, rastreadores, anúncios e tudo mais que você imaginar incorporado em nossas páginas da Web. Isso permite até mesmo os mais leigos sejam capazes de criar e publicar conteúdo na web. Sem terceiros, a Web provavelmente ser um meio acadêmico muito chato, baseado em texto, em vez de uma plataforma rica, imersiva e complexa que é tão essencial para a vida das pessoas. de muitos de nós hoje.

O que os recursos de terceiros podem fazer?

Acesso a algumas informações

Quando você usa um recurso de terceiros no seu site, independentemente do que seja, algumas informações são passadas para ele. Por exemplo, se você incluir uma imagem de outro site, a solicitação HTTP feita pelo navegador do usuário transmitirá um Referer cabeçalho com o URL da sua página e o endereço IP do usuário.

Rastreamento entre sites

Continuando com esse mesmo exemplo, quando a imagem é carregada em um site de terceiros, ela pode incluir um cookie, e esse cookie serão enviadas ao terceiro na próxima vez que o usuário solicitar essa imagem. Isso significa que o terceiro pode saber está sendo usado em seu site e pode retornar um cookie, potencialmente com um ID exclusivo para esse usuário. Isso significa que na próxima vez que o usuário acessar seu site ou qualquer outro site que inclua um recurso de terceiros, essa seleção do ID do cliente será enviado novamente. Isso permite que o terceiro crie um registro de onde esse usuário visita: seu site, outros sites que usam o mesmo recurso de terceiros em toda a Web.

Trata-se do rastreamento entre sites, ou seja, um terceiro que coleta um registro da atividade de um usuário em diversos sites, desde que sites usam um recurso do mesmo terceiro. Isso pode ser uma fonte, uma imagem ou uma folha de estilo; todos os recursos estáticos. Também pode ser um recurso dinâmico: um script, um botão de mídia social, um anúncio. O script incluído pode reunir ainda mais informações, porque são dinâmicos: ele pode inspecionar o navegador e o ambiente do usuário e passar os dados de volta para a origem. Qualquer script pode fazer isso até certo ponto, assim como os recursos dinâmicos que não são apresentados como um script, como uma incorporação de mídia social ou um anúncio ou um botão de compartilhamento. Observando os detalhes de um banner de cookie em sites conhecidos, você pode ver uma lista das organizações que podem adicionar um cookie de acompanhamento a seus usuários para criar uma imagem de suas atividades e criar um perfil desses usuários. podem ser centenas deles. Se um terceiro oferecer um serviço sem custo financeiro, uma maneira de fazer isso ser economicamente viável para ele fazem é porque coletam e monetizam esses dados.

Um guia útil para os tipos de problemas de privacidade com os quais um navegador deve proteger seus usuários é o Modelo de ameaça à privacidade alvo. Este é um documento ainda em discussão na época em que este artigo foi escrito, mas fornece algumas classificações de alto nível dos tipos de de ameaças de privacidade. Os riscos de recursos de terceiros são principalmente "reconhecimento indesejado entre sites", em que um podem identificar o mesmo usuário em vários sites e a "divulgação de informações sensíveis", onde um site pode coletar informações que o usuário considera sensíveis.

Esta é uma distinção principal: o reconhecimento indesejado entre sites é ruim mesmo que terceiros não estejam coletando dados informações deles, porque elas tiram o controle do usuário sobre sua identidade. Como acessar o referenciador e o endereço IP de um usuário e cookies é uma divulgação indesejada por si só. O uso de recursos de terceiros acompanha um componente de planejamento de como você usará sem comprometer a privacidade. Como desenvolvedor do site, parte desse trabalho é de sua responsabilidade, enquanto outra é feita pelo navegador na função de user agent, ou seja, o agente que trabalha em nome do usuário para evitar a divulgação de informações sensíveis e o reconhecimento indesejado entre sites, quando possível. A seguir, analisaremos com mais detalhes as mitigações e abordagens em um navegador e um nível de desenvolvimento de site.

Código de terceiros do lado do servidor

Nossa definição anterior de um terceiro alterou deliberadamente a abordagem do lado do cliente do Almanaque HTTP (conforme apropriado para o relatório), incluir a autoria de terceiros, porque do ponto de vista da privacidade, um terceiro é qualquer pessoa que saiba de alguma coisa sobre seus usuários, ou seja, quem não é você.

Isso inclui terceiros que prestam serviços no servidor e o cliente. De um documento de vista, também é importante entender uma biblioteca de terceiros (como algo incluído no NPM, Composer ou NuGet). Suas dependências transmitem dados para fora das suas fronteiras? Se você passar dados para um serviço de geração de registros ou um banco de dados hospedado remotamente, se as bibliotecas que você incluir também "telefone residencial" para os autores, elas poderão violar as políticas privacidade e, portanto, precisam ser auditados. Geralmente, um terceiro baseado em servidor precisa receber os dados do usuário por você, ou seja, que os dados aos quais ele é exposto estejam mais sob seu controle. Já um terceiro baseado em cliente, como um script ou recurso HTTP, incluídos em seu site e buscados pelo navegador do usuário, podem coletar alguns dados diretamente do usuário sem esse processo de coleta mediadas por você. A maior parte deste módulo abordará como identificar esses terceiros do lado do cliente você optou por incluir e expor seus usuários, exatamente porque tem menos mediação possível da sua parte. Mas vale a pena considere proteger seu código do lado do servidor para que você entenda as comunicações de saída dele e possa registrar ou bloquear qualquer sejam inesperados. Os detalhes sobre como fazer isso estão fora de nosso escopo aqui (e dependem muito da configuração de seu servidor), mas essa é outra parte da sua postura de segurança e privacidade.

Por que você precisa ter cuidado com terceiros?

Scripts e recursos de terceiros são muito importantes, e nosso objetivo como desenvolvedores Web deveria ser integrar tudo isso, para não se afastar deles! Mas existem problemas em potencial. O conteúdo de terceiros pode criar problemas de desempenho e pode isso também pode causar problemas de segurança, porque você está trazendo um serviço externo dentro do seu limite de confiança. No entanto, terceiros conteúdo também pode causar problemas de privacidade.

Quando se trata de recursos de terceiros na Web, é útil pensar nos problemas de segurança como (entre outras coisas) em que terceiros podem roubar dados da sua empresa, e para comparar isso com problemas de privacidade, que são (entre outras coisas) em que um terceiro que você incluiu rouba ou obtém acesso aos recursos dados sem o consentimento de você (ou eles).

Um exemplo de problema de segurança é quando os "skimmers da Web" roubar informações de cartões de crédito, um recurso de terceiros incluído em uma página na qual o usuário insere informações do cartão de crédito, pode roubar essas informações e enviá-las para o terceiro malicioso. Quem cria esses scripts de chumbo são muito criativos para ocultá-los. Um resumo descreve como os scripts skimmer foram ocultadas em conteúdo de terceiros, como imagens usadas em logotipos de sites, favicons e redes sociais; bibliotecas populares como jQuery, Modernizr e Gerenciador de tags do Google, widgets de site (como janelas de bate-papo ao vivo) e arquivos CSS.

Os problemas de privacidade são um pouco diferentes. esses terceiros fazem parte da sua oferta; para manter as informações dos usuários em você, precisa ter certeza de que os usuários podem confiar nele. Se um terceiro que você usa coletar dados sobre seus usuários e, em seguida, faz uso indevido deles, dificulta a exclusão e a descoberta deles, sofre uma violação de dados ou viola as políticas as expectativas, é provável que os usuários percebam que isso é um detalhamento na confiança que eles têm no seu serviço, não simplesmente nos por terceiros. É sua reputação e seu relacionamento na linha. Por isso, é importante se perguntar: você confia os terceiros que usa no seu site?

Quais são alguns exemplos de terceiros?

Estamos falando de "terceiros" mas eles têm acesso a diferentes quantidades de dados do usuário. Por exemplo, adicionar um elemento <img> ao HTML carregado de um servidor diferente fornecerá a esse servidor informações diferentes sobre seus usuários do que adicionar um <iframe> ou um elemento <script>. Esses são exemplos em vez de uma lista abrangente, mas é útil para entender as diferenças entre os diferentes tipos de itens de terceiros que seu site pode empregar.

Como solicitar um recurso entre sites

Um recurso entre sites é qualquer item no seu site carregado de um site diferente e não é um <iframe> nem um <script>. Exemplos incluem <img>, <audio>, <video>, fontes da Web carregadas por CSS e texturas WebGL. Todos eles são carregados por meio de uma solicitação HTTP, descritos anteriormente, essas solicitações HTTP incluirão todos os cookies definidos anteriormente pelo outro site, o endereço IP do usuário solicitante, e o URL da página atual como referenciador. Historicamente, todas as solicitações de terceiros incluíram esses dados por padrão, mas há esforços para reduzir ou isolar os dados transmitidos a terceiros por vários navegadores, conforme descrito em "Compreensão Proteções do navegador de terceiros" mais adiante.

Incorporação de um iframe entre sites

Um documento completo incorporado nas suas páginas usando um <iframe> pode solicitar acesso adicional às APIs do navegador, além do trifecta de cookies, endereço IP e referenciador. As APIs que estão disponíveis para páginas com <iframe> dias e como elas solicitam acesso são específicas do navegador. e está passando por alterações no momento: consulte "Política de permissões" abaixo para saber os esforços atuais para limitar ou monitorar o acesso a APIs em ambientes documentos.

Executar JavaScript entre sites

A inclusão de um elemento <script> carrega e executa o JavaScript entre sites no contexto de nível superior da página. Isso significa que executado tem acesso total a tudo o que seus próprios scripts próprios fazem. As permissões do navegador ainda gerenciam esses dados, Assim, solicitar o local do usuário (por exemplo) ainda exigirá o consentimento do usuário. Mas qualquer informação presente na página ou disponíveis, pois as variáveis JavaScript podem ser lidas por esse script, e isso inclui não apenas os cookies que são passados ao terceiro como parte da solicitação, mas também cookies que se destinam apenas ao seu site. Da mesma forma, um script de terceiros carregado pode fazer as mesmas solicitações HTTP que seu código, o que significa que ela pode fazer solicitações fetch() às suas APIs de back-end para receber dados.

Como incluir bibliotecas de terceiros nas suas dependências

Conforme descrito anteriormente, seu código do lado do servidor provavelmente também vai incluir dependências de terceiros, que são indistinguíveis das suas próprias códigos em seu poder; o código incluído de um repositório do GitHub ou da biblioteca da sua linguagem de programação (npm, PyPI, composer etc.); pode ler os mesmos dados que seu outro código.

Conhecer seus terceiros

Portanto, é necessário entender a lista de fornecedores terceirizados e quais informações de privacidade, coleta de dados e usuários as atitudes e políticas de experiência do usuário. Esse entendimento então se torna parte de sua série de compensações: quão útil e importante é o serviço, equilibrado em relação ao quanto as demandas são intrusivas, inconvenientes ou perturbadoras para os usuários. Terceiros o conteúdo agrega valor tirando o trabalho pesado de você, como proprietário do site, e permite que você se concentre em suas competências básicas; Por isso, vale a pena trocar um pouco de conforto e privacidade para melhorar a experiência do usuário. No entanto, é importante não confundir a experiência do usuário com a experiência do desenvolvedor: "é mais fácil para nossa equipe de desenvolvimento criar o serviço" não é uma história convincente para os usuários.

O processo de auditoria consiste em entender isso.

Auditar seus terceiros

Entender o que um terceiro faz é o processo de auditoria. Você pode fazer isso tecnicamente e não tecnicamente, e para um terceiro específico e para toda a sua coleção.

Executar uma auditoria não técnica

A primeira etapa não é técnica: leia as políticas de privacidade dos seus fornecedores. Se você incluir recursos de terceiros, consulte as políticas de privacidade. Eles serão longos e repletos de texto jurídico, e alguns documentos podem usar algumas das abordagens alerta especificamente contra nos módulos anteriores, como declarações excessivamente genéricas e sem qualquer indicação de como ou quando os dados coletados serão removidos. É importante perceber que, do ponto de vista do usuário, todos os dados é coletado em seu site, incluindo por terceiros, será regido por estas políticas de privacidade. Mesmo se você tudo corretamente, quando você é transparente sobre suas metas e supera as expectativas de privacidade de dados e sensibilidade, os usuários também podem responsabilizar você por qualquer ação de terceiros que você escolher. Se houver algo suas políticas de privacidade, o que não seria indicado em suas políticas, pois isso diminuiria o confiança, considere se há um fornecedor alternativo.

Isso é algo que pode andar de mãos dadas com a auditoria técnica discutida mais adiante, pois informam uma outra. Você precisa conhecer os recursos de terceiros que está incorporando por motivos comerciais (como redes de anúncios) ou conteúdo incorporado), porque haverá uma relação comercial em vigor. Esse é um bom ponto de partida para um estudo não técnico auditoria. É provável que a auditoria técnica também identifique terceiros, especialmente aqueles incluídos para fins técnicos, que por motivos comerciais (componentes externos, análises, bibliotecas de utilitários) e essa lista pode ser mesclada terceiros focados nos negócios. O objetivo aqui é que você, como proprietário do site, sinta que entende o que outras partes que está adicionando ao seu site estão fazendo e, para você, como empresa, poder apresentar seu advogado esse inventário de terceiros para garantir que você está cumprindo todas as obrigações necessárias.

Realizar uma auditoria técnica

Para uma auditoria técnica, é importante usar os recursos in situ como parte do site. ou seja, não carregar uma dependência em um arnês de teste e inspecioná-lo dessa maneira. Verifique se você está vendo como as dependências atuam como parte do seu site real. implantados na Internet pública, e não no modo de teste ou desenvolvimento. É muito instrutivo ver seu próprio site como um novo usuário. Abra um navegador em um perfil novo e limpo, de modo que você não esteja conectado e não tenha nenhum contrato armazenado, e tente visitar seu site.

Inscrever-se no seu próprio site para criar uma nova conta, caso você forneça contas de usuário. Sua equipe de design terá orquestrado esse novo usuário o processo de aquisição de usuários do ponto de vista de UX, mas pode ser ilustrativo do ponto de vista da privacidade. Não basta clicar "Aceitar" nos termos e condições, no aviso de cookie ou na política de privacidade; defina a tarefa de usar seu próprio serviço sem revelar informações pessoais ou ter cookies de rastreamento e veja se você consegue e qual é a dificuldade. Também pode ser útil olhar as ferramentas para desenvolvedores do navegador para ver quais sites estão sendo acessados e quais dados são transmitidos para nesses sites. As ferramentas para desenvolvedores fornecem uma lista de solicitações HTTP separadas (normalmente em uma seção chamada "Rede") e a partir daqui, solicitações agrupadas por tipo (HTML, CSS, imagens, fontes, JavaScript, solicitações iniciadas pelo JavaScript). Também é possível adicionar uma nova coluna para mostrar o domínio de cada solicitação, que demonstrará quantos locais diferentes estão sendo contatados, e pode haver "solicitações de terceiros" caixa de seleção para mostrar apenas terceiros. Também pode ser útil usar Content-Security-Policy para realizar uma auditoria contínua. Para saber mais, leia este documento.

A ferramenta "Request Map Generator" também pode dar uma visão geral útil de todas as subsolicitações feitas por uma página disponível publicamente.

Também é nesse ponto que você pode incluir os terceiros com foco nos negócios identificados como parte da auditoria não técnica (ou seja, a lista de empresas com as quais você tem um relacionamento financeiro para usar os recursos delas). O objetivo aqui é para corresponder à lista de terceiros que você acredita estar usando (de registros financeiros e jurídicos) com a lista que você realmente usando (analisando quais solicitações HTTP de terceiros seu site faz). Você deve ser capaz de identificar para cada terceiro de negócios quais solicitações técnicas de saída são feitas. Se não for possível identificar as solicitações de terceiros na auditoria técnica identificados pela relação comercial, é importante descobrir o porquê e usar isso para orientar seus testes. Talvez essa terceira é carregado apenas em um determinado país, tipo de dispositivo ou usuários conectados. Isso vai aumentar lista de áreas de site para auditar e garantir que você veja todos os acessos de saída. (Ou possivelmente identificará um terceiro que você está pagando e pelo qual não está usando, o que sempre anima o departamento financeiro.)

Depois de restringir a lista de solicitações a terceiros dos quais você gostaria de fazer parte da auditoria, clique em um solicitação individual mostrará todos os detalhes dela e, especificamente, quais dados foram passados para essa solicitação. Também é muito comum que uma solicitação de terceiros iniciada pelo seu código inicie muitas outras solicitações de terceiros. Esses terceiros adicionais também são "importados" na sua própria política de privacidade. Essa tarefa é trabalhosa, mas valiosa, e muitas vezes pode ser inserido em análises existentes, sua equipe de desenvolvimento front-end já deve estar auditando solicitações motivos de desempenho (talvez com a ajuda de ferramentas existentes como WebPageTest ou Lighthouse) e a incorporação de um conjunto de e auditoria de privacidade nesse processo pode facilitar.

O mapa de solicitações do web.dev.
Um mapa de solicitação (muito simplificado) para web.dev, mostrando sites de terceiros que solicitam outros sites de terceiros e assim por diante.

O que fazer

Abra um navegador com um perfil de usuário novo e limpo, de modo que você não esteja conectado e não tenha nenhum contrato armazenado; e abra o navegador ferramentas de desenvolvimento no painel Rede para ver todas as solicitações enviadas. Adicione uma nova coluna para mostrar o domínio de cada solicitação e verifique os "solicitações de terceiros" caixa de seleção para mostrar apenas terceiros, se estiverem presentes. Em seguida:

  • Acesse seu site.
  • Criar uma nova conta, caso você forneça contas de usuário.
  • Tente excluir a conta que você criou.
  • Realize uma ou duas ações normais no site (o que exatamente depende do que seu site faz, mas escolha ações comuns que a maioria dos usuários realiza).
  • Realize uma ou duas ações que envolvem dependências de terceiros em particular. Isso pode incluir o compartilhamento de conteúdo com mídia social, início de um fluxo de finalização de compra ou incorporação de conteúdo de outro site.

Ao executar cada uma dessas tarefas, faça um registro dos recursos solicitados de domínios que não são seus. Para isso, consulte o painel Rede conforme descrito. Estes são alguns dos seus terceiros. Uma boa maneira de fazer isso é usar as ferramentas de rede do navegador para capturar a rede solicitar registros em um arquivo HAR.

HAR e capturar

Um arquivo HAR é um formato JSON padronizado de todas as solicitações de rede feitas por uma página. Para gerar um arquivo HAR de uma página específica, faça o seguinte:

Chrome

Abra as DevTools do navegador (Menu > Mais ferramentas > Ferramentas para desenvolvedores), acesse o painel "Rede", carregue (ou atualize) a página e escolha o símbolo de salvar a seta para baixo no canto superior direito próximo ao menu suspenso Sem limitação.

O painel de rede do Chrome DevTools com o símbolo &quot;Download HAR&quot; destacado.
Firefox

Abra as ferramentas para desenvolvedores do navegador (Menu > Mais ferramentas > Ferramentas para desenvolvedores da Web), acesse o painel "Rede", carregue (ou atualize) a página e escolha o símbolo de engrenagem no canto superior direito ao lado do menu suspenso de limitação. No menu, escolha Salvar tudo como HAR**.

O painel de rede de ferramentas para desenvolvedores do Firefox com a opção &quot;Salvar tudo como D&quot; em destaque.
Safari

Abra as ferramentas para desenvolvedores do navegador (Menu > Desenvolver > Mostrar Web Inspector. Se você não tiver um menu de desenvolvimento, ative-o em Menu > Safari > Preferências > Avançado > mostrar o menu "Desenvolvedor" na barra de menus), acesse o painel "Rede", carregue (ou atualize) a página. e escolha Exportar no canto superior direito (à direita de "Preservar registro". Talvez seja necessário ampliar a janela).

Painel de rede do Safari Web Inspector com a opção de exportação HAR destacada.

Para mais detalhes, também é possível registrar o que é repassado a terceiros (na seção "Solicitação"), embora esses dados geralmente sejam são ofuscadas e não são facilmente interpretáveis.

Práticas recomendadas ao integrar terceiros

Você pode definir suas próprias políticas com base nos terceiros que seu site usa: alterar o provedor de anúncios usado com base nas práticas deles, se o pop-up de consentimento de cookies é irritante ou intrusivo, ou se você quer usar botões de mídias sociais no site; links de acompanhamento em seus e-mails ou links utm_campaign para rastrear no Google Analytics em seus tweets. Um aspecto a considerar ao desenvolver um site é a postura de privacidade e segurança do seu serviço de análise. Alguns serviços de análise negociam explicitamente proteger a privacidade. Muitas vezes, também há maneiras de usar um script de terceiros que adiciona proteção de privacidade: você não é a primeira equipe que busca melhorar os recursos privacidade e protegê-los da coleta de dados de terceiros, e há já podem ser soluções. Finalmente, muitos provedores de terceiros são mais sensíveis a problemas de coleta de dados agora do que no passado, e muitas vezes há recursos ou parâmetros que permitem um modo mais seguro do usuário. Veja alguns exemplos.

Ao adicionar um botão de compartilhamento em mídias sociais

Incorpore botões HTML diretamente: o site https://sharingbuttons.io/ tem alguns exemplos bem projetados. Você também pode adicionar links HTML simples. A desvantagem disso é que você perde a "contagem de compartilhamentos" estatística e sua capacidade de classificar seus clientes nas estatísticas do Facebook. Esse é um exemplo de compensação entre usar um provedor terceirizado e receber menos dados de análise.

De modo mais geral, quando você incorpora algum tipo de widget interativo de terceiros, geralmente é possível fornecer um um link para ele. Isso significa que seu site não oferece a experiência inline, mas isso muda a decisão de compartilhamento seus dados com o terceiro para seu usuário, que pode optar por interagir ou não como preferir.

Por exemplo, você pode adicionar links para o Twitter e o Facebook compartilharem seu serviço em meusite.exemplo.com da seguinte forma:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Observe que o Facebook permite especificar um URL a ser compartilhado e o Twitter permite especificar um URL e algum texto.

Ao incorporar um vídeo

Ao incorporar vídeos de sites de hospedagem, procure opções de preservação de privacidade no código de incorporação. Por exemplo, para o YouTube, substitua youtube.com no URL incorporado por www.youtube-nocookie.com para evitar os cookies de rastreamento são colocados nos usuários que visualizam a página de incorporação. Você também pode marcar "Ativar modo de privacidade aprimorada" ao gerar Compartilhar/incorporar um link do próprio YouTube. Esse é um bom exemplo de como usar um modo mais seguro do usuário fornecido por terceiros. https://support.google.com/youtube/answer/171780 descreve isso em mais detalhes. e outras opções de incorporação especificamente para o YouTube).

Outros sites de vídeos têm menos opções nesse sentido: o TikTok, por exemplo, não tem uma maneira de incorporar vídeos sem rastreamento. no momento em que este artigo foi escrito. É possível hospedar os vídeos você mesmo (isso é uma alternativa), mas também pode ser muito mais trabalhoso, especialmente para compatibilidade com muitos dispositivos.

Assim como nos widgets interativos discutidos anteriormente, com frequência é possível substituir um vídeo incorporado por um link para o site que fornece o material. Essa opção é menos interativa, porque o vídeo não será reproduzido inline, mas deixa a escolha de assistir com o usuário. Isso pode ser usado como exemplo do "padrão de fachada", o nome para substituição dinâmica do conteúdo interativo por algo que exige um usuário para acioná-lo. Um vídeo incorporado do TikTok pode ser substituído por um link simples para a página de vídeo do TikTok, mas com um pouco mais funciona, é possível recuperar e exibir uma miniatura para o vídeo e transformá-lo em um link. Mesmo que o provedor de vídeo escolhido não oferecem suporte a uma maneira fácil de incorporar vídeos sem rastreamento. Muitos hosts de vídeo são compatíveis com o oEmbed, uma API que, quando fornecida, um link para um vídeo ou conteúdo incorporado, retornará detalhes programáticos para ele, incluindo uma miniatura e um título. O TikTok oferece suporte ao oEmbed (consulte https://developers.tiktok.com/doc/embed-videos para mais detalhes), o que significa que você pode (de forma manual ou programática) transformar um link para um vídeo do TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 em metadados JSON sobre esse vídeo usando https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 e, portanto, recuperam uma miniatura exibir. O WordPress geralmente usa isso para solicitar o oEmbed informações para conteúdo incorporado, por exemplo. Você pode usar esse recurso de forma programática para mostrar uma "fachada" que parece interativo e alterna para incorporação ou link para um vídeo interativo quando o usuário clica nele.

Ao incorporar scripts de análise

O Google Analytics foi projetado para coletar informações sobre seus usuários para que possam ser analisadas: é para isso que serve. Os sistemas de análise são essencialmente serviços para coletar e exibir dados sobre acessos e usuários, o que é feito em um servidor de terceiros, como o Google Analytics, para facilitar de implementação. Também existem sistemas de análise auto-hospedados, como https://matomo.org/ (em inglês), embora isso seja mais trabalhoso do que usar um uma solução de terceiros para isso. No entanto, executar esse sistema na sua própria infraestrutura ajuda a reduzir a coleta de dados, porque ele não sai do seu próprio ecossistema. Por outro lado, gerenciar, remover e definir políticas para os dados passa a ser sua responsabilidade. Grande parte da preocupação com o rastreamento entre sites ocorre quando isso é feito clandestinamente e secretamente ou como efeito colateral do uso de um serviço que não precisa conter nenhuma coleta de dados. o software de análise de dados projetada para coletar dados com o objetivo de informar os proprietários dos sites sobre os usuários.

Historicamente, há uma abordagem de coleta de todos os dados possíveis sobre tudo, como uma rede de pesca gigante, e e analisá-lo posteriormente para identificar padrões interessantes. Em grande parte, essa mentalidade criou a sensação de desconforto e inquietação sobre a coleta de dados, que foi abordada na parte 1 deste curso. Agora, muitos sites primeiro definem quais perguntas fazer e e coletar dados específicos e limitados para responder a essas perguntas.

Se algum serviço de terceiros for usado pelo seu site e por outros, e funcionar se você incluir o JavaScript deles no seu site, e ele define cookies para cada usuário, é importante considerar que eles podem estar fazendo reconhecimento indesejado entre sites. ou seja, rastrear os usuários em vários sites. Algumas podem e outras não, mas a postura de proteção da privacidade aqui é presumir que tal serviço de terceiros faz, de fato, rastreamento entre sites, a menos que você tenha um bom motivo para pensar ou saber o contrário. Isso não é, por si só, um motivo para evitar esses serviços, mas é algo a considerar na sua avaliação das compensações. de usá-las.

No passado, a análise de dados só tinha a questão de decidir usar ou não: coletar todos os dados e comprometer a privacidade em troca. para insights e planejamento ou abrir mão totalmente de insights. No entanto, esse não é mais o caso e muitas vezes há meio termo seja encontrado entre esses dois extremos. Verifique seu provedor de análise para saber quais são as opções de configuração para limitar os dados coletados e reduzir a quantidade e a duração do armazenamento. Como você tem os registros da auditoria técnica descrito anteriormente, é possível executar novamente as seções relevantes dessa auditoria para confirmar se a mudança dessas configurações realmente reduzem a quantidade de dados coletados. Se você estiver fazendo essa transição em um site existente, isso poderá lhe dar uma medida quantificável que possa ser escrita para seus usuários. Por exemplo, o Google Analytics tem várias opções de permissão (que, portanto, ficam desativadas por padrão) recursos de privacidade, muitos dos quais podem ser úteis para cumprir as leis locais de proteção de dados. Algumas opções a serem consideradas ao configurar o Google O Google Analytics inclui definir o período de retenção dos dados coletados (Administrador > Informações de acompanhamento > Retenção de dados) menor que o padrão de 26 meses. e ativar algumas soluções mais técnicas, como a anonimização de IP parcial. Saiba mais em https://support.google.com/analytics/answer/9019185.

Uso de terceiros para preservar a privacidade

Até agora, discutimos como proteger os usuários de terceiros durante a fase de design do aplicativo e, ao mesmo tempo, você está planejando o que o aplicativo vai fazer. A decisão de não usar um terceiro específico faz parte desse planejamento, e a auditoria dos seus usos também se encaixa nessa categoria: trata-se de tomar decisões sobre a postura de privacidade. No entanto, as decisões são naturalmente não muito granulares; escolher ou não usar um terceiro específico não é uma decisão sutil. É muito mais provável que você queira algo no meio: precisar ou planejar usar uma oferta específica de terceiros, mas mitigar quaisquer tendências que violem a privacidade (seja deliberada ou acidental). Essa é a tarefa de proteger os usuários no "tempo de build": adicionar salvaguardas para reduzir os danos que você não previu. Todos esses são cabeçalhos HTTP novos que você pode fornecer ao exibir páginas e que sugerem ou comandam o user agent a assumir determinadas posturas de privacidade ou segurança.

Política do referenciador

O que fazer

Defina uma política de strict-origin-when-cross-origin ou noreferrer para evitar que outros sites recebam um cabeçalho Referer. quando você os vincula ou quando são carregados como sub-recursos por uma página:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Ou no lado do servidor, por exemplo, no Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Se necessário, defina uma política laxer em solicitações ou elementos específicos.

Por que isso protege a privacidade do usuário

Por padrão, cada solicitação HTTP que o navegador faz transmite um cabeçalho Referer, que contém o URL da página que inicia a solicitação. seja um link, uma imagem incorporada ou um script. Isso pode ser um problema de privacidade, porque os URLs podem conter informações particulares a disponibilização a terceiros transmite essas informações particulares a eles. O Web.dev lista alguns exemplos de URLs contendo dados privados. Saber que um usuário chegou ao seu site a partir de https://social.example.com/user/me@example.com informa quem ele é, o que é um vazamento definido. Mas mesmo um URL que não expõe informações particulares mostra que esse usuário específico (que você pode conhecer, se ele tiver feito login) veio de outro site. Isso mostra que o usuário visitou esse outro site. Isso, por si só, é uma exposição informações que talvez você não deva saber sobre o histórico de navegação do seu usuário.

Fornecer um cabeçalho Referrer-Policy (com ortografia correta) permite que você o altere para que alguns ou nenhum dos URLs de referência sejam transmitidos. O MDN lista os detalhes completos, mas a maioria dos navegadores adotou o valor strict-origin-when-cross-origin por padrão, o que significa que o URL referenciador agora é transmitido para o terceiro partes somente como origem (https://web.dev em vez de https://web.dev/learn/privacy). Essa é uma proteção de privacidade útil fazer qualquer coisa. Mas você pode reforçar ainda mais especificando Referrer-Policy: same-origin para evitar a transmissão de informações de referência a terceiros (ou Referrer-Policy: no-referrer para evitar a transmissão a qualquer pessoa, incluindo sua própria origem). Esse é um bom exemplo do equilíbrio entre privacidade e serviços. O novo padrão preserva muito mais a privacidade do que antes, mas ainda fornecem informações de alto nível a terceiros de sua escolha, como seu provedor de análises.

Também é útil especificar explicitamente esse cabeçalho. Assim, você saberá exatamente qual é a política em vez de depender dos padrões do navegador. Se não for possível definir cabeçalhos, defina uma política de referenciador para uma página HTML inteira usando um elemento meta no <head>: <meta name="referrer" content="same-origin"> Se estiver preocupado com terceiros específicos, também é possível definir um referrerpolicy em elementos individuais, como <script>, <a> ou <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

O cabeçalho Content-Security-Policy, geralmente conhecido como "CSP", determina de onde os recursos externos podem ser carregados. Ele é usado principalmente para fins de segurança, evitando ataques de scripting em vários sites e injeção de script, mas quando usado junto com as auditorias regulares, ela também pode limitar para onde os terceiros escolhidos podem transmitir dados.

Essa pode ser uma experiência do usuário menos do que excelente; se um dos seus scripts de terceiros começar a carregar uma dependência de um origem não estiver na lista, essa solicitação será bloqueada, o script falhará e seu aplicativo poderá falhar com ele (ou ao menos ser reduzido à versão substituta com falha de JavaScript). Isso é útil quando o CSP é implementado para segurança, que é sua finalidade normal: proteger contra problemas de scripting em vários sites (e, para isso, use uma CSP rigorosa). Depois de conhecer todos os scripts in-line usados pela sua página, é possível fazer uma lista deles, calcular um valor de hash ou adicionar um valor aleatório (chamado de "valor de uso único") para cada um e, em seguida, adicione a lista de hashes à sua Política de Segurança de Conteúdo. Isso impedirá que qualquer script que não está na lista para que ela seja carregada. Isso precisa ser incorporado ao processo de produção do site: os scripts nas páginas precisam para incluir o valor de uso único ou ter um hash calculado como parte do build. Consulte o artigo sobre strict-csp (link em inglês) para ver todos os detalhes.

Felizmente, os navegadores aceitam um cabeçalho relacionado, Content-Security-Policy-Report-Only. Se esse cabeçalho for fornecido, as solicitações que violarem a política fornecida não serão bloqueados, mas um relatório JSON será enviado a um URL fornecido. Esse cabeçalho pode fica assim: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, e, se o navegador carregar um script de qualquer lugar diferente de 3p.example.com, a solicitação será realizada, mas o relatório ser enviada para o report-uri fornecido. Normalmente, isso é usado para testar uma política antes de implementá-la, mas uma boa forma de ideia aqui é usar isso como uma forma de conduzir uma "auditoria contínua". Além da auditoria regular descrita anteriormente, você pode ativar os relatórios da CSP para conferir se algum domínio inesperado aparece, o que pode significar que seus recursos de terceiros estão sendo carregados. recursos de terceiros próprios e que você precisa considerar e avaliar. (Também pode ser um sinal da existência de tráfego entre sites explorações de scripting têm ultrapassado seu limite de segurança, é claro, algo que também é importante conhecer!)

A Content-Security-Policy é uma API complexa e trabalhosa de usar. Isso é conhecido, e ainda há trabalho para construir a "próxima geração" da CSP que atingirão os mesmos objetivos, mas não serão tão complicados de usar.Ele ainda não está pronto, mas se você quiser saber para onde ele está indo (ou para participar e ajudar no design), acesse https://github.com/WICG/csp-next (link em inglês) para ver mais detalhes.

O que fazer

Adicione este cabeçalho HTTP às páginas exibidas: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Armazene o JSON quando ele for postado nesse URL. Analise os dados armazenados para ter um conjunto dos domínios de terceiros solicitados por seu site quando acessado por outras pessoas. Atualize o cabeçalho Content-Security-Policy-Report-Only para listar os domínios esperados e ver quando essa lista muda:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Por quê?

Isso faz parte da sua auditoria técnica de maneira contínua. A auditoria técnica inicial que você realizou dará a você lista de terceiros com quem seu site compartilha ou transmite dados do usuário. Esse cabeçalho fará com que as solicitações de página informem quais terceiros estão sendo contatados, e você pode acompanhar as alterações ao longo do tempo. Isso não apenas alerta você sobre alterações feitas pelos seus terceiros, mas também sinalizarão terceiros recém-adicionados que não foram incluídos na auditoria técnica. É importante atualizar o cabeçalho para deixar de gerar relatórios sobre os domínios esperados, mas também é possível repetir o procedimento auditorias técnicas de vez em quando, porque a abordagem Content-Security-Policy não sinaliza quais dados são transmitidos, de que uma solicitação foi feita.

Ele não precisa ser adicionado às páginas exibidas todas as vezes ou a todas as páginas. Reduzir quantas respostas de página recebem no cabeçalho para receber uma amostra representativa de relatórios que não sejam excessivos em quantidade.

Política de permissões

O cabeçalho Permissions-Policy, introduzido com o nome Feature-Policy, tem um conceito semelhante ao da Content-Security-Policy, mas restringe o acesso a recursos avançados do navegador. Por exemplo, é possível restringir o uso de hardware do dispositivo, como o acelerômetro, câmera ou dispositivos USB, ou para restringir recursos que não são de hardware, como permissão para entrar em tela cheia ou usar XMLHTTPRequest síncrono. Essas restrições podem ser aplicadas a uma página de nível superior (para evitar que os scripts carregados tentem usar esses recursos) ou para páginas com subframes carregadas por meio de um iframe. Essa restrição de uso da API não está relacionada à impressão digital do navegador. serve para impedir que terceiros realizem ações invasivas, como o uso de APIs avançadas, janelas de permissões etc.). Isso é definido pelo Modelo de ameaças à privacidade de destino como "intrusão".

Um cabeçalho Permissions-Policy é especificado como uma lista de pares (recurso, origens permitidas), assim:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Este exemplo permite que esta página ("self") e <iframe>s da origem example.com usem as APIs navigator.geolocation de JavaScript. ela permite que esta página e todos os subframes usem a API de tela cheia e proíbe qualquer página, incluindo esta página, de usar uma câmera para ler informações de vídeo. Veja mais detalhes e uma lista de possíveis exemplos aqui.

A lista de recursos gerenciados pelo cabeçalho Permissions-Policy é grande e pode estar em fluxo. Atualmente, a lista é mantida em https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

O que fazer

Navegadores compatíveis com Permissions-Policy não permitem recursos avançados em subframes por padrão, e você precisa ativá-los. Essa abordagem é particular por padrão. Se você achar que os subframes no seu site exigem essas permissões, é possível adicioná-los seletivamente. No entanto, não há uma política de permissões aplicada à página principal por padrão. Por isso, os scripts (incluindo scripts de terceiros) que são carregados pela página principal não têm restrições quanto ao uso desses recursos. Por esse motivo, é útil aplicar uma restrição Permissions-Policy a todas as páginas por padrão e, em seguida, adicione gradualmente os recursos necessários.

Exemplos de recursos avançados afetados pelo Permissions-Policy incluem solicitar a localização do usuário, acesso a sensores (incluindo acelerômetro, giroscópio e magnetômetro), permissão para entrar em tela cheia e solicitar acesso à câmera e ao microfone do usuário. A lista completa de recursos (que pode mudar) está no link acima.

Infelizmente, para bloquear todos os recursos por padrão e reativá-los seletivamente, é necessário listar todos os recursos no cabeçalho, o que pode parecer um pouco deselegante. No entanto, esse cabeçalho Permissions-Policy é um bom ponto de partida. permissionspolicy.com/ tem um gerador conveniente que pode ser clicado para criar esse cabeçalho: usá-lo para criar um cabeçalho que desativa todos os recursos resulta neste resultado:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Entender os recursos de privacidade integrados em navegadores da Web

Além do "tempo de build", e "tempo de design" também as proteções de privacidade, que ocorrem no "tempo de execução", ou seja, a privacidade recursos implementados nos próprios navegadores para proteger os usuários. Esses não são recursos que você pode controlar ou usar diretamente como um site. desenvolvedor, pois são recursos de produto, mas são recursos que você deve conhecer, porque seus sites podem ser afetados por essas decisões sobre o produto. em navegadores. Para dar um exemplo de como essas proteções do navegador podem afetar seu site, se você tiver JavaScript do lado do cliente que aguarda uma dependência de terceiros seja carregada antes de continuar com a configuração da página e que ela nunca seja carregada. Então, sua página deverá configurar sua página pode nunca terminar. Assim, o usuário vê uma página meio carregada.

Eles incluem o Intelligent Tracking Prevention no Safari (e o mecanismo WebKit subjacente) e a Proteção antirrastreamento aprimorada no Firefox (e no mecanismo Gecko). Todas essas opções dificultam a criação de perfis detalhados dos seus usuários por terceiros.

As abordagens dos navegadores sobre recursos de privacidade mudam com frequência, e é importante se manter atualizado; a seguinte lista de proteções estão corretas no momento em que este artigo foi escrito. Os navegadores também podem implementar outras proteções. essas listas não são exaustivas. Consulte o módulo sobre práticas recomendadas. para acompanhar as mudanças, e não deixe de testar nas próximas versões do navegador as mudanças que podem afetar seus projetos. Lembre-se de que os modos de navegação anônima/privada às vezes implementam configurações diferentes do padrão do navegador (cookies de terceiros podem ser bloqueados) por padrão nesses modos, por exemplo). Portanto, o teste no modo de navegação anônima nem sempre reflete a experiência de navegação típica da maioria dos usuários se não estejam usando a navegação privada. Além disso, bloquear cookies em várias situações pode significar que outras soluções de armazenamento, como window.localStorage, são bloqueados, não apenas cookies.

Chrome

  • Cookies de terceiros pretendem ser bloqueados no futuro. No momento, eles não estão bloqueados por padrão. (mas pode ser ativado por um usuário): https://support.google.com/chrome/answer/95647 explica os detalhes.
  • os recursos de privacidade do Chrome, e, em especial, os recursos do Chrome que se comunicam com serviços do Google e de terceiros; estão descritos em privacysandbox.com/.

Edge

  • Os cookies de terceiros não são bloqueados por padrão (mas isso pode ser ativado por um usuário).
  • Blocos de recursos da Prevenção de rastreamento do Edge rastreadores de sites não visitados e rastreadores nocivos conhecidos são bloqueados por padrão.

Firefox

Para saber o que pode estar bloqueado e ajudar a depurar problemas, clique no ícone de escudo na barra de endereço ou acesse about:protections no Firefox (no computador).

Safari

  • Cookies de terceiros são bloqueados por padrão.
  • Como parte do recurso Prevenção de rastreamento inteligente, O Safari reduz o referenciador transmitido a outras páginas para que se torne um site de nível superior em vez de uma página específica: (https://something.example.com, em vez de https://something.example.com/this/specific/page).
  • Os dados do navegador localStorage são excluídos após sete dias.

https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ (link em inglês) resume esses recursos.

Para receber insights sobre o que pode estar bloqueado e ajudar a depurar problemas, ative o "Modo de depuração da Prevenção inteligente de rastreamento" nos navegadores menu do desenvolvedor (no computador). Consulte https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ (link em inglês) para ver mais detalhes.

Propostas de API

Por que precisamos de novas APIs?

Embora os novos recursos e políticas de preservação da privacidade nos produtos de navegador ajudem a preservar a privacidade do usuário, eles também apresentam desafios. Muitas tecnologias da web são utilizáveis para rastreamento entre sites, apesar de terem sido criadas e usadas para outros fins. Por exemplo: muitos sistemas de federação de identidade que usamos diariamente dependem de cookies de terceiros. Diversas soluções de publicidade que os editores para a receita são criados com base em cookies de terceiros. Muitas soluções de detecção de fraudes dependem de técnicas de impressão digital. O quê? acontece com esses casos de uso quando cookies de terceiros e técnicas de impressão digital desaparecem?

Seria difícil e sujeito a erros para os navegadores diferenciar casos de uso e distinguir de maneira confiável os usos que violam a privacidade. dos outros. É por isso que a maioria dos principais navegadores bloqueou cookies de terceiros e técnicas de impressão digital ou pretende fazer isso para proteger o usuário privacidade.

Uma nova abordagem é necessária: à medida que os cookies de terceiros são desativados e as técnicas de impressão digital reduzidas, os desenvolvedores precisam de APIs criadas especificamente para isso. que atendam aos casos de uso (que não foram descontinuados), mas são projetados de maneira a preservar a privacidade. O objetivo é projetar e criar APIs que não podem ser usadas para rastreamento entre sites. Diferentemente dos recursos de navegador descritos na seção anterior, essas tecnologias querem se tornar APIs para vários navegadores.

Exemplos de propostas de API

A lista a seguir não é abrangente, apenas mostra o que está sendo discutido.

Exemplos de propostas de API para substituir tecnologias criadas com cookies de terceiros:

Exemplos de propostas de API para substituir tecnologias criadas com base no rastreamento passivo:

Exemplos de outras propostas que poderão ser desenvolvidas por outras APIs no futuro sem cookies de terceiros:

Além disso, outro tipo de proposta de API está surgindo para tentar mitigar rastreamentos ocultos específicos do navegador até agora. Um exemplo é o Orçamento de privacidade. Em todas essas várias de uso geral, as APIs propostas inicialmente pelo Chrome funcionam sob o termo geral Sandbox de privacidade.

Global-Privacy-Control é um cabeçalho que pretende comunicar a um site que o usuário gostaria que os dados pessoais coletados não fossem compartilhados com outros sites. A intenção é semelhante à do recurso "Do Not Track", que foi descontinuada.

Status das propostas de API

A maioria dessas propostas de API ainda não foi implantada ou foi implantada apenas com flags ou em ambientes limitados para experimentação.

Essa fase de incubação pública é importante: os fornecedores e desenvolvedores de navegadores coletam discussões e experiências sobre se essas APIs são útil e se elas realmente fazem para o que foram criadas. Desenvolvedores, fornecedores de navegadores e outros agentes do ecossistema usam essa fase para iterar o design da API.

O melhor lugar para ficar por dentro das novas APIs propostas é a lista de propostas do Privacy Group no GitHub (em inglês).

Você precisa usar essas APIs?

Caso seu produto tenha sido desenvolvido diretamente com cookies ou técnicas de terceiros, como técnicas de impressão digital, você deve conhecer essas novas APIs, testá-las e contribuir com suas próprias experiências nas discussões e no design da API. Em todos os outros casos, você não precisa necessariamente saber todos os detalhes sobre essas novas APIs no momento da gravação, mas é bom estar ciente do que está por vir.