Terceiros

O que é um terceiro?

É bem raro um site ser totalmente autossuficiente. O HTTP Web Almanac mostra que a maioria dos sites (cerca de 95%) contém conteúdo de terceiros.

O Almanac define conteúdo de terceiros como algo hospedado em uma origem compartilhada e pública, que é amplamente usado por vários sites e não tem influência de um proprietário de site individual. Eles podem ser imagens ou outras mídias, como vídeos, fontes ou scripts. Imagens e scripts representam mais do que tudo o que é somado. O conteúdo de terceiros não é essencial para o desenvolvimento de um site, mas poderia ser. Você provavelmente usará algo carregado de um servidor público compartilhado, seja fontes da Web, iframes incorporados de vídeos, anúncios ou bibliotecas JavaScript. Por exemplo, talvez você esteja usando fontes da Web exibidas pelo Google Fonts ou medindo análises com o Google Analytics, tenha adicionado botões "Gostei" ou botões "Fazer login com" de redes sociais, incorpore mapas ou vídeos ou processe compras de compras por serviços de terceiros. Talvez você esteja acompanhando erros e fazendo registros das suas próprias equipes de desenvolvimento com ferramentas de monitoramento de terceiros.

Por motivos de privacidade, é útil considerar uma definição um pouco diferente e menos ampla: um recurso de terceiros e, em particular, um script de terceiros é exibido de uma origem compartilhada e pública e amplamente usado, conforme ilustrado, mas também é de autoria de alguém que não é o proprietário do site. O aspecto da autoria de terceiros é fundamental ao considerar como proteger a privacidade dos seus usuários contra outras pessoas. Isso o levará a considerar quais riscos estão presentes e, em seguida, decidir como ou se usar um recurso de terceiros com base nesses riscos. Como já discutido, essas coisas ajudarão você a entender o contexto e, portanto, entender quais compensações você precisa fazer e o que elas significam.

Isso não é exatamente o que queremos dizer quando se trata de "recursos de terceiros" em geral: a distinção entre primários e terceiros está na verdade sobre o contexto em que algo é usado. Um script carregado de outro site é um recurso de terceiros, e a solicitação HTTP que carrega o script pode incluir cookies, mas esses cookies não são, na verdade, "cookies de terceiros". São apenas cookies. Se o script está sendo carregado em uma página do seu site ou do proprietário do script.

Por que usamos recursos de terceiros?

Terceiros são uma ótima maneira de incluir funcionalidades no site. Podem ser recursos expostos aos usuários ou funções invisíveis do desenvolvedor, como rastreamento de erros, mas que 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 por causa da composição da Web: ser capaz de juntar partes para formar um todo que é maior do que a soma delas.

O Web Almanac do HTTP Archive oferece uma boa descrição:

Os terceiros fornecem uma coleção interminável de imagens, vídeos, fontes, ferramentas, bibliotecas, widgets, rastreadores, anúncios e qualquer outra coisa que você possa imaginar incorporada às nossas páginas da Web. Isso permite que até mesmo os mais não técnicos possam criar e publicar conteúdo na Web. Sem terceiros, a Web provavelmente seria um meio acadêmico muito chato, baseado em texto e complexo, em vez da plataforma rica, imersiva e complexa, que é tão essencial para a vida de muitos de nós hoje.

O que 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 transmitidas a ele. Por exemplo, se você incluir uma imagem de outro site, a solicitação HTTP feita pelo navegador do usuário transmitirá um cabeçalho Referer 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 do site de terceiros, é possível incluir um cookie, que será enviado de volta ao terceiro na próxima vez que o usuário solicitar essa imagem. Isso significa que os terceiros podem saber que o serviço está sendo usado no seu site e podem retornar um cookie, possivelmente 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 desse terceiro, o cookie de ID único será enviado novamente. Isso permite que o terceiro crie um registro das visitas dele: seu site e outros sites que usam o mesmo recurso de terceiros em toda a Web.

Isso é o rastreamento entre sites: permitir que terceiros coletem um registro da atividade do usuário em vários sites, desde que todos usem um recurso do mesmo terceiro. Eles podem ser uma fonte, uma imagem ou uma folha de estilo, ou seja, 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 coletar ainda mais informações por ser dinâmico: ele pode inspecionar o navegador e o ambiente do usuário e transmitir esses dados de volta ao criador. Qualquer script pode fazer isso até certo ponto, assim como recursos dinâmicos que não são apresentados como um script, como uma incorporação de mídia social, um anúncio ou um botão de compartilhamento. Se você observar os detalhes de um banner de cookie em sites conhecidos, poderá ver uma lista de organizações que podem adicionar um cookie de acompanhamento aos usuários. Assim, é possível ter uma imagem das atividades deles e criar um perfil do usuário. Pode haver centenas deles. Se um terceiro oferece um serviço sem custo financeiro, uma maneira de fazer isso é economicamente viável para que ele faça isso é porque eles coletam e geram receita com esses dados.

O Target Privacy Threat Model é um guia útil sobre os tipos de problemas de privacidade que um navegador deve usar para proteger os usuários. Esse documento ainda estava em discussão no momento em que foi escrito, mas oferece algumas classificações de alto nível dos tipos de ameaças de privacidade existentes. Os riscos dos recursos de terceiros são principalmente "reconhecimento indesejado entre sites", em que um site pode identificar o mesmo usuário em vários sites, e "divulgação de informações confidenciais", em que um site pode coletar informações que o usuário considera sensíveis.

Essa é uma distinção principal: o reconhecimento indesejado entre sites é ruim, mesmo que o terceiro não esteja coletando informações sensíveis extras, porque isso tira o controle do usuário sobre a própria identidade. Ter acesso ao referenciador, ao endereço IP e aos cookies de um usuário é, por si só, uma declaração indesejada. O uso de recursos de terceiros acompanha um componente de planejamento sobre como eles serão usados para preservar a privacidade. Parte desse trabalho é da sua responsabilidade como desenvolvedor do site e outra é feita pelo navegador no papel 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 sempre que possível. Confira abaixo em mais detalhes as mitigações e abordagens no nível do navegador e de desenvolvimento de sites.

Código de terceiros do lado do servidor

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

Isso inclui o cliente e os terceiros que prestam os serviços usados no servidor. Do ponto de vista da privacidade, também é importante entender uma biblioteca de terceiros (como algo incluído no NPM, no Composer ou no NuGet). As dependências transmitem dados para fora das bordas? Se você transmitir dados para um serviço de geração de registros ou um banco de dados hospedado remotamente, se as bibliotecas também incluírem "telefone residencial" para os autores, elas poderão estar em posição de violar a privacidade dos seus usuários e, portanto, precisarão ser auditadas. Um terceiro baseado em servidor geralmente precisa fornecer os dados do usuário por você, o que significa que os dados a que ele é exposto estão mais sob seu controle. Por outro lado, um terceiro baseado em cliente (um script ou recurso HTTP incluído no seu site e buscado pelo navegador do usuário) pode coletar alguns dados diretamente do usuário sem que esse processo de coleta seja mediado por você. A maior parte deste módulo vai abordar como identificar os terceiros do lado do cliente que você optou por incluir e expor seus usuários, exatamente porque você não consegue fazer a mediação. Mas vale a pena proteger o código do lado do servidor para entender as comunicações de saída a partir dele e registrar ou bloquear qualquer algo inesperado. Os detalhes sobre como fazer isso exatamente estão fora do nosso escopo (e dependem muito da configuração do 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 da Web deve ser integrar esses recursos, não o deixar de lado! Mas há possíveis problemas. O conteúdo de terceiros pode gerar problemas de desempenho e de segurança porque você está trazendo um serviço externo dentro do seu limite de confiança. Mas o conteúdo de terceiros também pode criar problemas de privacidade.

Quando falamos sobre recursos de terceiros na Web, é útil pensar que problemas de segurança são (entre outras coisas) em que um terceiro pode roubar dados da sua empresa. Já com os problemas de privacidade, que são, entre outras coisas, em que um terceiro que você incluiu rouba ou consegue acesso aos dados dos seus usuários sem seu consentimento.

Um exemplo de problema de segurança é quando "skimmers da Web" roubam informações de cartão de crédito, um recurso de terceiros incluído em uma página em que um usuário digita detalhes de cartão de crédito e pode roubar esses detalhes e enviá-los para terceiros mal-intencionados. Aqueles que criam esses scripts skimmer são muito criativos ao descobrir onde escondê-los. Um resumo descreve como scripts skimmer foram ocultados em conteúdo de terceiros, como as imagens usadas para logotipos de sites, favicons e redes de mídias sociais, bibliotecas conhecidas (como jQuery, Modernizr e Gerenciador de tags do Google), widgets de sites, como janelas de chat ao vivo e arquivos CSS.

Os problemas de privacidade são um pouco diferentes. Esses terceiros fazem parte da sua oferta. Para manter a confiança dos usuários em você, é preciso ter certeza de que eles podem confiar neles. Se um terceiro coletar dados sobre os usuários e depois usá-los de maneira indevida, dificultar a exclusão/descoberta, sofrer uma violação de dados ou violar as expectativas dos usuários, é provável que eles percebam isso como uma queda na confiança do seu serviço, e não apenas do terceiro. É sua reputação e seu relacionamento na linha. Por isso, é importante se perguntar: você confia nos terceiros que está usando no seu site?

Cite alguns exemplos de terceiros.

Estamos falando de "terceiros" em geral, mas na verdade há tipos diferentes e eles têm acesso a volumes distintos de dados do usuário. Por exemplo, adicionar um elemento <img> ao HTML, carregado de um servidor diferente, fornecerá a esse servidor informações sobre seus usuários diferentes da adição de um <iframe> ou de um elemento <script>. Estes são exemplos em vez de uma lista abrangente, mas é útil entender as distinções entre os diferentes tipos de itens de terceiros que seu site pode usar.

Como solicitar um recurso entre sites

Um recurso entre sites é qualquer item do seu site que seja carregado de um site diferente e que não seja <iframe> ou <script>. Os exemplos incluem <img>, <audio>, <video>, fontes da Web carregadas por CSS e texturas WebGL. Elas são carregadas por uma solicitação HTTP e, conforme descrito anteriormente, essas solicitações incluem 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íam esses dados por padrão, embora haja esforços para reduzir ou isolar os dados transmitidos a terceiros por vários navegadores, conforme descrito em "Noções básicas sobre as proteções de navegadores de terceiros".

Como incorporar um iframe entre sites

Um documento completo incorporado às suas páginas por um <iframe> pode solicitar acesso adicional às APIs do navegador, além do triplo de cookies, endereço IP e referenciador. As APIs que estão disponíveis para as páginas do <iframe> e a forma como elas solicitam acesso são específicas do navegador e estão passando por mudanças: consulte a "Política de permissões" abaixo para ver os esforços atuais para limitar ou monitorar o acesso à API em documentos incorporados.

Execução de JavaScript entre sites

Incluir um elemento <script> é carregado e executa o JavaScript entre sites no contexto de nível superior da página. Isso significa que o script em execução tem acesso total a tudo que os scripts próprios fazem. As permissões do navegador ainda gerenciam esses dados. Portanto, para solicitar o local do usuário (por exemplo), ainda será necessário o consentimento do usuário. No entanto, qualquer informação presente na página ou disponível como variável JavaScript pode ser lida por esse script. Isso inclui não apenas os cookies transmitidos a terceiros como parte da solicitação, mas também os cookies destinados somente ao seu site. Da mesma forma, um script de terceiros carregado na sua página pode fazer as mesmas solicitações HTTP que seu próprio código, o que significa que ele pode fazer solicitações fetch() às APIs de back-end para receber dados.

Como incluir bibliotecas de terceiros nas suas dependências

Conforme descrito anteriormente, o código do lado do servidor provavelmente também incluirá dependências de terceiros, que são indistinguíveis do seu próprio código. O código que você inclui de um repositório do GitHub ou da biblioteca da sua linguagem de programação (NPM, PyPI, composer e assim por diante) pode ler os mesmos dados que seu outro código pode ler.

Conhecendo seus terceiros

Para isso, é necessário entender melhor sua lista de fornecedores terceirizados e saber quais são as políticas e posições de privacidade, coleta de dados e experiência do usuário. Esse entendimento se torna parte da sua série de desvantagens: a utilidade e a importância do serviço, equilibrada com a forma como as demandas são invasivas, inconvenientes ou inquietantes para os usuários. O conteúdo de terceiros agrega valor ao fazer o trabalho pesado de você, como proprietário do site, e permite que você se concentre nas suas competências principais. Por isso, vale a pena fazer essa troca e sacrificar um pouco do conforto e da privacidade do usuário por uma melhor experiência do usuário. É importante não confundir a experiência do usuário com a do desenvolvedor. No entanto, "para nossa equipe de desenvolvimento criar o serviço" não é uma história convincente para os usuários.

O processo de auditoria é a forma de conseguir essa compreensão.

Como auditar seus terceiros

Entender o que um terceiro faz é o processo de auditoria. Você pode fazer isso de maneira técnica ou não técnica, para um terceiro individual e para toda 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, verifique as políticas de privacidade. Elas são longas e cheias de texto legal, e alguns documentos podem usar algumas das abordagens especificamente advertidas em 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 coletados no seu site, incluindo por terceiros, serão regidos por estas Políticas de Privacidade. Mesmo que você faça tudo corretamente, quando é transparente sobre suas metas e supera as expectativas dos usuários em relação à privacidade e sensibilidade de dados, os usuários podem considerar você responsável por tudo que os terceiros escolhidos fizerem também. Se houver algo em suas políticas de privacidade que você não queira dizer em suas próprias políticas porque isso diminuiria a confiança dos usuários, então avalie se há outro fornecedor.

Isso é algo que pode andar de mãos dadas com a auditoria técnica discutida mais adiante, uma vez que eles informam uns aos outros. Você precisa conhecer os recursos de terceiros que está incorporando por motivos comerciais, como redes de publicidade ou conteúdo incorporado, porque haverá uma relação comercial em vigor. Esse é um bom lugar para iniciar uma auditoria não técnica. É provável que a auditoria técnica também identifique terceiros, especialmente aqueles incluídos por motivos técnicos e não empresariais (componentes externos, análises, bibliotecas de utilitários), e essa lista pode se juntar à lista de terceiros com foco nos negócios. O objetivo aqui é que você, como proprietário do site, sinta que entende o que os terceiros adicionados a ele estão fazendo e que sua empresa possa apresentar esse inventário de terceiros ao seu consultor jurídico para garantir que está cumprindo todas as obrigações necessárias.

Realizar uma auditoria técnica

Para uma auditoria técnica, é importante usar os recursos locais como parte do site. Ou seja, não carregue uma dependência em um arcabouço de testes e inspecione essa dependência. Verifique se as dependências atuam como parte do seu site real, implantadas na Internet pública, e não em um modo de teste ou desenvolvimento. É muito esclarecedor ver seu próprio site como um novo usuário. Abra um navegador em um novo perfil limpo, para que você não tenha feito login e não tenha um contrato armazenado, e tente visitar seu site.

Inscreva-se em uma nova conta no seu site, se você fornecer contas de usuário. Sua equipe de design vai organizar esse novo processo de aquisição de usuários do ponto de vista da UX, mas abordá-lo do ponto de vista da privacidade é um exemplo ilustrativo. Não basta clicar em "Aceitar" nos Termos e Condições, no aviso de cookie ou na Política de Privacidade; defina a si mesmo a tarefa de usar seu próprio serviço, sem divulgar informações pessoais ou ter cookies de rastreamento, e veja se consegue fazer isso e se é difícil fazer isso. Também pode ser útil consultar as ferramentas para desenvolvedores do navegador para ver quais sites estão sendo acessados e quais dados são transmitidos para esses sites. As Ferramentas para desenvolvedores fornecem uma lista de solicitações HTTP separadas (normalmente em uma seção chamada "Rede"). Você pode conferir aqui as solicitações agrupadas por tipo (HTML, CSS, imagens, fontes, JavaScript, solicitações iniciadas por JavaScript). Também é possível adicionar uma nova coluna para mostrar o domínio de cada solicitação, o que demonstrará quantos locais diferentes estão sendo contatados. Além disso, pode haver uma caixa de seleção "solicitações de terceiros" para exibir apenas terceiros. Também pode ser útil usar os relatórios Content-Security-Policy para realizar uma auditoria contínua. Leia mais sobre isso para saber mais.

A ferramenta Gerador de solicitação de mapa de Simon Hearne (em inglês) também pode ser uma visão geral útil de todas as subsolicitações que uma página disponível publicamente.

Nesse ponto, também é possível 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. O objetivo é comparar a lista de terceiros que você acredita estar usando (de registros financeiros e legais) e a lista que você está usando (analisando quais solicitações HTTP de terceiros são feitas pelo seu site). É possível identificar para cada terceiro empresarial quais solicitações técnicas de saída são feitas. Se não for possível identificar solicitações na auditoria técnica para um terceiro identificado pela relação comercial, é importante entender o motivo e orientar os testes: talvez esse recurso de terceiros seja carregado apenas em um país, em um tipo de dispositivo específico ou para usuários conectados. Isso aumenta sua lista de áreas do site a serem auditadas e garante a visualização de todos os acessos de saída. Ou possivelmente, ele vai identificar um recurso de terceiros pelo qual você está pagando e não usando, o que sempre melhora o departamento financeiro.

Depois de reduzir a lista de solicitações a terceiros que você quer fazer parte da auditoria, clique em uma solicitação individual para exibir todos os detalhes dela e, especificamente, quais dados foram transmitidos 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 também são "importados" para sua própria política de privacidade. Essa tarefa é trabalhosa, mas valiosa e geralmente pode ser inserida em análises existentes. Sua equipe de desenvolvimento de front-end já deve estar auditando as solicitações por motivos de desempenho (talvez com a ajuda de ferramentas existentes, como WebPageTest ou Lighthouse), e incorporar uma auditoria de dados e privacidade nesse processo pode facilitar isso.

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

O que fazer

Abra um navegador com um novo perfil de usuário limpo, para que você não faça login e não tenha um contrato armazenado. Em seguida, abra o painel "Rede" das ferramentas de desenvolvimento do navegador para ver todas as solicitações enviadas. Adicione uma nova coluna para mostrar o domínio de cada solicitação e marque a caixa de seleção "Solicitações de terceiros" para mostrar apenas terceiros, se houver. Então:

  • Acesse seu site.
  • Inscreva-se em uma nova conta, se você informar as contas de usuário.
  • Tente excluir a conta criada.
  • Realize uma ou duas ações normais no site (o que exatamente vai depender do que seu site faz, mas escolha ações comuns que a maioria dos usuários realiza).
  • Realize uma ou duas ações que você sabe que envolvem dependências de terceiros em particular. Isso pode incluir compartilhar conteúdo nas redes sociais, iniciar um fluxo de finalização de compra ou incorporar conteúdo de outro site.

Ao realizar cada uma dessas tarefas, faça um registro dos recursos solicitados de domínios que não são seus, consultando o painel "Rede", conforme descrito. Esses são alguns dos terceiros. Uma boa maneira de fazer isso é usando as ferramentas de rede do navegador para capturar os registros de solicitação de rede em um arquivo HAR.

Arquivos HAR e captura

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, use o seguinte:

Chrome

Abra o DevTools do navegador (Menu > More Tools > Developer Tools), acesse o painel Network, carregue (ou atualize) a página e escolha o símbolo de seta para baixo no canto superior direito, próximo ao menu suspenso "Sem limitaçã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, selecione Salvar tudo como HAR**.

O painel de rede de ferramentas para desenvolvedores do Firefox com a opção &quot;Save All As Har&quot; destacada.
Safari

Abra as ferramentas para desenvolvedores do navegador (Menu > Develop > Show Web Inspector. Se você não tiver um menu Develop, ative em Menu > Safari > Preferences > Advanced > Show Develop menu na barra de menus), acesse o painel Network, carregue (ou atualize) a página e escolha Export no canto superior direito (à direita de Preserve Log). Talvez seja necessário ampliar a janela.

Painel &quot;Network Inspector&quot; do Safari com a opção de exportação HAR destacada.

Para mais detalhes, também é possível registrar o que é transmitido a terceiros na seção "Solicitação", embora esses dados geralmente sejam ofuscados e não sejam interpretáveis de maneira útil.

Práticas recomendadas ao integrar terceiros

Você pode definir suas próprias políticas sobre os terceiros que seu site usa: altere o provedor de anúncios usado com base nas práticas deles, o nível de incômodo ou intrusivo do pop-up de consentimento de cookies ou se você quer usar botões de mídias sociais no seu site, links de rastreamento nos seus e-mails ou links utm_campaign para acompanhar no Google Analytics nos seus tweets. Um aspecto a ser considerado ao desenvolver um site é a postura de privacidade e segurança do seu serviço de análise. Alguns serviços de análise trocam explicitamente a proteção da privacidade. Muitas vezes, também há maneiras de usar um script de terceiros que adiciona proteção de privacidade por si só: você não é a primeira equipe que quer melhorar a privacidade dos usuários e protegê-los da coleta de dados de terceiros, e talvez já haja soluções. Por fim, muitos provedores terceirizados são mais sensíveis aos problemas de coleta de dados agora do que no passado, e geralmente é possível adicionar recursos ou parâmetros que permitem um modo mais de proteção do usuário. Veja alguns exemplos.

Ao adicionar um botão de compartilhamento em mídia social

Considere incorporar botões HTML diretamente: o site https://sharingbuttons.io/ tem alguns exemplos bem elaborados. Ou você pode adicionar links HTML simples. A desvantagem é que você perde a estatística de "contagem de compartilhamento" e sua capacidade de classificar seus clientes no Facebook Analytics. Este é um exemplo de uma compensação entre usar um provedor de terceiros e receber menos dados de análise.

De modo geral, ao incorporar um widget interativo de terceiros, geralmente é possível fornecer um link para esse terceiro. Isso significa que o site não tem a experiência inline, mas muda a decisão de compartilhar dados com o terceiro, de você para o usuário, que pode interagir ou não como preferir.

Por exemplo, é possível adicionar links para o Twitter e 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>

O Facebook permite especificar um URL para compartilhar e o Twitter permite especificar um URL e algum texto.

Ao incorporar um vídeo

Ao incorporar vídeos de sites de hospedagem de vídeo, procure no código de incorporação opções que preservam a privacidade. Por exemplo, para o YouTube, substitua youtube.com no URL incorporado por www.youtube-nocookie.com para evitar que cookies de rastreamento sejam colocados em usuários que visualizam a página de incorporação. Você também pode marcar a opção "Ativar modo de privacidade aprimorada" ao gerar o link "Compartilhar/Incorporar" pelo próprio YouTube. Esse é um bom exemplo de uso de um modo de proteção mais abrangente para o usuário fornecido por terceiros. (https://support.google.com/youtube/answer/171780 isso é descrito em mais detalhes e outras opções de incorporação específicas para o YouTube.)

Outros sites de vídeos têm menos opções nesse sentido: o TikTok, por exemplo, não tem como incorporar vídeos sem rastreamento no momento em que este artigo foi escrito. É possível hospedar os vídeos por conta própria (isso é uma alternativa), mas pode ser muito mais trabalhoso, especialmente para oferecer suporte a vários dispositivos.

Assim como nos widgets interativos discutidos anteriormente, muitas vezes é possível substituir um vídeo incorporado por um link para o site fornecedor. Essa opção é menos interativa porque o vídeo não é reproduzido inline, mas deixa a escolha de assistir ou não com o usuário. Isso pode ser usado como um exemplo do "padrão de fachada", o nome para substituir dinamicamente conteúdo interativo por algo que exige uma ação do 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 de trabalho, é possível recuperar e exibir uma miniatura do vídeo e transformar esse link em um link. Mesmo que o provedor de vídeo escolhido não ofereç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 recebe um link para um vídeo ou conteúdo incorporado, retorna detalhes programáticos, incluindo uma miniatura e um título. O TikTok é compatível com o oEmbed. Consulte https://developers.tiktok.com/doc/embed-videos para mais detalhes. Isso significa que você pode transformar um link de um vídeo do TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 em metadados JSON sobre esse vídeo com https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 e, assim, recuperar uma miniatura para exibir. O WordPress usa esse recurso com frequência para solicitar informações do oEmbed para conteúdo incorporado, por exemplo. Você pode usá-lo de maneira programática para mostrar uma "facha" que parece interativa e alterna para incorporar ou vincular a um vídeo interativo quando o usuário optar por clicar 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. 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 a implementação. Também existem sistemas de análise auto-hospedados, como https://matomo.org/ (link em inglês), embora isso seja mais trabalhoso do que usar uma solução de terceiros. 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, o gerenciamento e a remoção desses dados e a definição de políticas para eles são de sua responsabilidade. Grande parte da preocupação com o rastreamento entre sites surge quando ele é feito de maneira clandestina e secreta ou como um efeito colateral do uso de um serviço que não precisa conter coleta de dados. O software de análise é explicitamente projetado para coletar dados e informar os proprietários do site sobre os usuários.

Historicamente, existe uma abordagem de coletar todos os dados possíveis sobre tudo, como uma rede de pesca gigante, e depois analisá-los em busca de padrões interessantes. Essa mentalidade, em grande parte, criou a sensação de inquietação e desconforto sobre a coleta de dados, que foi discutida na parte 1 deste curso. Agora, muitos sites decidem quais perguntas fazer e depois coletam dados específicos e limitados para responder a essas perguntas.

Se algum serviço de terceiros for usado pelo seu site e por outros sites e funcionar com a inclusão do JavaScript deles no seu site, e definir cookies para cada usuário, é importante considerar que eles podem estar fazendo reconhecimento indesejado entre sites, ou seja, rastreando seus usuários em sites. Algumas podem ou não, mas a postura de proteção de privacidade aqui é presumir que esse serviço de terceiros está, de fato, fazendo rastreamento entre sites, a menos que você tenha um bom motivo para pensar ou saber o contrário. Esse 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á-los.

A troca na análise costumava ser apenas para escolher se você deveria usá-la ou não: coletar todos os dados e comprometer a privacidade em troca de insights e planejamento, ou desistir totalmente de insights. No entanto, esse não é mais o caso, e agora há um meio-termo entre esses dois extremos. Verifique as opções de configuração do seu provedor de análise para limitar os dados coletados e reduzir a quantidade e a duração do armazenamento. Como você tem os registros da auditoria técnica descrita anteriormente, é possível executar de novo as seções relevantes dessa auditoria para confirmar que a mudança dessas configurações reduz a quantidade de dados coletados. Se você estiver fazendo essa transição em um site atual, isso pode fornecer uma medida quantificável que pode ser escrita para seus usuários. Por exemplo, o Google Analytics tem vários recursos de privacidade ativados (por padrão, desativados), muitos dos quais podem ser úteis para obedecer às leis locais de proteção de dados. Algumas opções a serem consideradas ao configurar o Google Analytics incluem definir o período de armazenamento dos dados coletados (Administrador > Informações de acompanhamento > Retenção de dados) menor que o padrão de 26 meses e ativar algumas das soluções mais técnicas, como anonimização parcial de IP (consulte https://support.google.com/analytics/answer/9019185 para mais detalhes).

Usar terceiros preservando a privacidade

Até agora, discutimos como proteger seus usuários de terceiros durante a fase de design do aplicativo enquanto você planeja o que o aplicativo fará. Decidir não usar um terceiro específico faz parte desse planejamento, e a auditoria dos usos também se enquadra nesta categoria: é tomar decisões sobre sua postura de privacidade. No entanto, essas decisões por natureza não são muito detalhadas. Escolher usar ou não um terceiro específico não é uma decisão diferenciada. É muito mais provável que você queira algo no meio: precisar ou planejar usar uma oferta específica de terceiros, mas reduzir tendências que violam a privacidade (deliberadas ou acidentais). Essa é a tarefa de proteger os usuários no "tempo de compilação": adicionar proteções para reduzir danos que você não previu. Todos esses são novos cabeçalhos HTTP que você pode fornecer ao exibir páginas e que vão dar dicas ou comandos ao user agent para assumir determinadas posições de privacidade ou segurança.

Política de referenciador

O que fazer

Defina uma política de strict-origin-when-cross-origin ou noreferrer para impedir que outros sites recebam um cabeçalho Referer ao vinculá-los ou quando forem carregados como sub-recursos por uma página:

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

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 mais flexível para elementos ou solicitações específicas.

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 iniciou 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, e esses URLs disponíveis para terceiros transmitem essas informações particulares a eles. O Web.dev lista alguns exemplos de URLs que contêm dados particulares. saber que um usuário chegou ao seu site pelo https://social.example.com/user/me@example.com informa quem ele é, o que é um vazamento definitivo. No entanto, mesmo um URL que não expõe informações particulares mostra que esse usuário específico (que você pode saber, se ele tiver feito login) veio de outro site e isso revela que ele visitou esse outro site. Isso, por si só, expõe informações que talvez você não deva saber sobre o histórico de navegação do usuário.

Fornecer um cabeçalho Referrer-Policy (com ortografia correta) permite alterar isso, para que parte ou nenhum URL de referência seja transmitido. A MDN lista todos os detalhes, mas a maioria dos navegadores agora adotou o valor presumido de strict-origin-when-cross-origin por padrão, o que significa que o URL do referenciador agora é transmitido a terceiros apenas como uma origem (https://web.dev em vez de https://web.dev/learn/privacy). Essa é uma proteção de privacidade útil sem que você precise fazer nada. No entanto, é possível restringir ainda mais especificando Referrer-Policy: same-origin para evitar a transmissão de qualquer informação de referenciador a terceiros (ou Referrer-Policy: no-referrer para evitar a transmissão a qualquer pessoa que inclua sua própria origem). Esse é um bom exemplo do equilíbrio entre privacidade e utilidade. O novo padrão preserva muito mais a privacidade do que antes, mas ainda fornece informações de alto nível a terceiros de sua escolha, como seu provedor de análise.

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

Política de Segurança de Conteúdo

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

Essa pode ser uma experiência do usuário insatisfatória. Se um dos scripts de terceiros começar a carregar uma dependência de uma origem que não está na sua lista, a solicitação será bloqueada, o script vai falhar e o aplicativo poderá apresentar falha (ou pelo menos ser reduzido à versão substituta com falha de JavaScript). Isso é útil quando a CSP é implementada para fins de segurança, que é a finalidade normal dela: proteger contra problemas de scripting em vários locais. Para fazer isso, use uma CSP rigorosa. Depois de conhecer todos os scripts in-line que sua página usa, é 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 deles e adicionar a lista de hashes à sua Política de Segurança de Conteúdo. Isso evita que qualquer script que não esteja na lista seja carregado. Isso precisa ser incorporado ao processo de produção do site: os scripts nas suas páginas precisam incluir o valor de uso único ou ter um hash calculado como parte da criação. Consulte o artigo sobre strict-csp para saber mais.

Felizmente, os navegadores oferecem suporte ao 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 bloqueadas, mas um relatório JSON será enviado para um URL fornecido. Esse cabeçalho pode ter a seguinte aparência: 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, essa solicitação será bem-sucedida, mas um relatório será enviado para o report-uri fornecido. Normalmente, isso é usado para testar uma política antes da implementação, mas uma ideia útil é usar isso como uma forma de conduzir uma "auditoria contínua". Assim como na auditoria regular descrita anteriormente, é possível ativar os relatórios da CSP para ver se aparecem domínios inesperados, o que pode significar que os recursos de terceiros estão carregando recursos de terceiros e que você precisa considerar e avaliar. Isso também pode ser um sinal de algumas explorações de scripting em vários locais que ultrapassaram seu limite de segurança, o que também é importante saber.

Content-Security-Policy é uma API complexa e complexa para usar. Isso é conhecido, e há trabalho em andamento para criar a "próxima geração" da CSP, que atenderá aos mesmos objetivos, mas não será tão complicado de usar.Isso ainda não está pronto, mas, se você quiser saber para onde isso está indo (ou se envolver e ajudar no design), confira https://github.com/WICG/csp-next para 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 publicado no URL. Revise os dados armazenados para acessar uma coleção dos domínios de terceiros que seu site solicita quando são acessados por outras pessoas. Atualize o cabeçalho Content-Security-Policy-Report-Only para listar os domínios esperados e saber quando essa lista mudar:

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

Por que

Isso faz parte da sua auditoria técnica, de maneira contínua. A auditoria técnica inicial que você realizou fornecerá uma lista de terceiros com quem seu site compartilha ou transmite dados do usuário. Esse cabeçalho faz com que as solicitações de página informem quais terceiros estão sendo contatados, e você pode acompanhar as mudanças ao longo do tempo. Isso não apenas alerta sobre as mudanças feitas por terceiros, mas também sinaliza terceiros recém-adicionados que não foram incluídos na auditoria técnica. É importante atualizar o cabeçalho para interromper a geração de relatórios sobre os domínios esperados, mas também é importante repetir a auditoria técnica manual periodicamente, já que a abordagem Content-Security-Policy não sinaliza quais dados são transmitidos, apenas 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. Ajuste quantas respostas de página recebem o cabeçalho para receber uma amostra representativa de relatórios que não sejam sobrecarregadas em quantidade.

Política de permissões

O cabeçalho Permissions-Policy (apresentado com o nome Feature-Policy) é semelhante em conceito a 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 acelerômetro, câmera ou dispositivos USB, ou 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 a 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. Ela significa impedir que terceiros façam ações invasivas, como usar APIs avançadas, abrir 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 de (recursos, origens permitidas), desta forma:

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

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

A lista de recursos processados 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

Por padrão, os navegadores com suporte a Permissions-Policy não permitem recursos avançados em subframes, e você precisa tomar medidas para ativá-los. Por padrão, essa abordagem é particular. Se você achar que os subframes do seu site precisam dessas permissões, adicione-os seletivamente. No entanto, por padrão não há uma política de permissões aplicada à página principal. Portanto, os scripts (incluindo scripts de terceiros) que são carregados por ela não têm restrições de tentar usar esses recursos. Por isso, é útil aplicar uma Permissions-Policy restritiva a todas as páginas por padrão e adicionar gradualmente os recursos necessários.

Exemplos de recursos avançados que o Permissions-Policy afeta incluem a solicitação da localização do usuário, o acesso a sensores (incluindo acelerômetro, giroscópio e magnetômetro), permissão para ativar a tela cheia e solicitação de acesso à câmera e ao microfone do usuário. O link para a lista completa de recursos (em alteração) está disponível acima.

Infelizmente, bloquear todos os recursos por padrão e depois autorizá-los novamente exige listar todos os recursos no cabeçalho, o que pode parecer bastante descomplicado. No entanto, esse cabeçalho Permissions-Policy é um bom ponto de partida. O permissionspolicy.com/ tem um gerador convenientemente clicável para criar esse cabeçalho: usá-lo para criar um cabeçalho que desativa todos os recursos resulta nisto:

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=()

Entenda os recursos de privacidade integrados nos navegadores da Web

Além das proteções de "tempo de build" e "tempo de design", há também proteções de privacidade que ocorrem no "tempo de execução", ou seja, recursos de privacidade implementados nos próprios navegadores para proteger os usuários. Esses recursos não podem ser controlados diretamente ou acessados por você como desenvolvedor de sites. Eles são recursos de produto, mas são recursos que você precisa conhecer, porque seus sites podem ser afetados por essas decisões de produto em navegadores. Para dar um exemplo de como essas proteções do navegador podem afetar seu site, se você tiver um JavaScript do lado do cliente que aguarda o carregamento de uma dependência de terceiros antes de continuar a configuração da página e essa dependência de terceiros nunca for carregada, talvez a configuração da página nunca seja concluída, e uma página parcialmente carregada será exibida ao usuário.

Elas incluem a Prevenção de Rastreamento Inteligente no Safari e o mecanismo WebKit subjacente) e a Proteção Avançada contra Rastreamento no Firefox (e o mecanismo, o Gecko). Tudo isso dificulta a criação de perfis detalhados dos usuários por terceiros.

As abordagens dos navegadores sobre recursos de privacidade mudam com frequência, e é importante ficar atualizado. A lista de proteções a seguir está correta no momento em que este artigo foi escrito. Os navegadores também podem implementar outras proteções. Essas listas não estão completas. Consulte o módulo sobre práticas recomendadas para saber como acompanhar as mudanças. Além disso, teste as próximas versões dos navegadores para descobrir mudanças que podem afetar seus projetos. Às vezes, os modos de navegação anônima/privada implementam configurações diferentes do padrão do navegador (cookies de terceiros podem ser bloqueados por padrão nesses modos, por exemplo). Portanto, os testes no modo de navegação anônima nem sempre refletem a experiência típica da maioria dos usuários se eles não estiverem usando a navegação anônima. Também tenha em mente que o bloqueio de cookies em várias situações pode significar que outras soluções de armazenamento, como window.localStorage, também serão bloqueadas.

Chrome

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

Edge

  • Cookies de terceiros não são bloqueados por padrão, mas podem ser ativados por um usuário.
  • O recurso Prevenção de rastreamento do Edge bloqueia rastreadores de sites não visitados, e os rastreadores nocivos conhecidos são bloqueados por padrão.

Firefox

Para entender 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 para outras páginas para que ele seja um site de nível superior, e não uma página específica: (https://something.example.com, em vez de https://something.example.com/this/specific/page).
  • Os dados de localStorage do navegador são excluídos após sete dias.

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

Para mais informações sobre o que pode estar bloqueado e ajudar a depurar problemas, ative o "Modo de depuração da Prevenção de Rastreamento Inteligente" no menu do desenvolvedor do Safari (no computador). Consulte https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ (link em inglês) para 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 projetadas e usadas para outros fins. Por exemplo, muitos sistemas de federação de identidade que usamos todos os dias dependem de cookies de terceiros. As várias soluções de publicidade usadas atualmente pelos editores para gerar receita são baseadas em cookies de terceiros. Muitas soluções de detecção de fraudes contam com técnicas de impressão digital. O que acontece com esses casos de uso quando os cookies de terceiros e as técnicas de impressão digital desaparecem?

Seria difícil e propenso a erros para os navegadores diferenciar os casos de uso e distinguir com segurança 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 pretendem fazer isso para proteger a privacidade do usuário.

Uma nova abordagem é necessária: à medida que os cookies de terceiros são descontinuados e as técnicas de impressão digital são mitigadas, os desenvolvedores precisam de APIs específicas que atendam aos casos de uso (que não desapareceram), mas sejam projetadas de maneira a preservar a privacidade. O objetivo é projetar e criar APIs que não possam ser usadas para rastreamento entre sites. Ao contrário dos recursos de navegador descritos na seção anterior, essas tecnologias se tornam APIs para vários navegadores.

Exemplos de propostas de API

A lista a seguir não é completa. Ela é uma amostra do 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 baseadas no rastreamento passivo:

Exemplos de outras propostas que outras APIs podem usar como base para um futuro sem cookies de terceiros:

Além disso, outro tipo de proposta de API está surgindo para tentar ter mitigações de rastreamento oculto específicas para navegadores até agora. Um exemplo é o Orçamento de privacidade. Em todos esses casos de uso, as APIs inicialmente propostas pelo Chrome vivem sob o termo geral do Sandbox de privacidade.

Global-Privacy-Control é um cabeçalho que pretende comunicar a um site que o usuário não quer que os dados pessoais coletados sejam compartilhados com outros sites. A intenção é semelhante ao recurso Do Not Track, que foi desativado.

Status das propostas de API

A maioria dessas propostas de API ainda não foi implantada ou é implantada apenas sob sinalizações ou em ambientes limitados para experimentação.

Essa fase de incubação pública é importante: os fornecedores e desenvolvedores de navegadores podem coletar informações e experiências para saber se essas APIs são úteis e se realmente fazem o que foram projetadas. Desenvolvedores, fornecedores de navegadores e outros agentes do ecossistema usam essa fase para iterar no design da API.

O melhor lugar para se manter atualizado sobre as novas APIs propostas é atualmente a lista de propostas do Privacy Group no GitHub (em inglês).

Você precisa usar essas APIs?

Se o seu produto for criado diretamente com cookies ou técnicas de terceiros, como técnicas de impressão digital, você deve se envolver com essas novas APIs, testá-las e contribuir com suas próprias experiências para as discussões e para o design da API. Em todos os outros casos, você não precisa saber todos os detalhes dessas novas APIs no momento da criação, mas é bom saber o que está por vir.