Fingerprinting de navegador

O que esta verificação faz

Analisa os scripts carregados e o comportamento em tempo de execução à procura de técnicas conhecidas de fingerprinting:

• SDKs comerciais — FingerprintJS Pro (fpjs.io, api.fpjs.io, CNAMEs metrics.<o-teu-dominio>), ThreatMetrix, IPQS, SEON.
• Abuso da API Canvas — chamadas a canvas.toDataURL() ou getImageData() em elementos ocultos, fora do ecrã ou OffscreenCanvas logo após renderizar uma string fixa.
• Sondas WebGL — leitura de WEBGL_debug_renderer_info (strings de fornecedor/renderer da GPU) sem um contexto 3D visível.
• Fingerprinting via AudioContext — instanciação de um OfflineAudioContext, execução de um oscilador e hash do buffer.
• Enumeração de fontes — medição da largura de strings de teste em centenas de famílias de tipos de letra para detetar quais estão instaladas.

O MetricSpot mantém uma allow-list para SDKs de analytics comuns (GA4, Plausible, Fathom) que tocam algumas destas APIs de forma benigna, pelo que a verificação só dispara quando o padrão corresponde a fingerprinting ativo.

Porque é importante

Os reguladores fecharam a brecha do “não é um cookie, logo o consentimento não se aplica”. As diretrizes 2023 do EDPB sobre o art. 5(3) ePrivacy tratam qualquer técnica do lado do cliente que leia ou escreva informação no dispositivo do utilizador — incluindo fingerprinting — como exigindo o mesmo consentimento prévio, informado e opt-in que os cookies. A CNIL, ICO e DPC seguiram a mesma linha.

Isto significa que um script de fingerprinting a disparar antes de o visitante aceitar o teu banner de consentimento de cookies é a mesma violação de conformidade que definir um cookie _ga antes do consentimento — e a fiscalização está ativa. A CNIL multou a Criteo em 40M€ em 2023 parcialmente com esta base.

Além do ângulo legal: o fingerprinting identifica utilizadores entre sessões e através da rede. Se um SDK de terceiros vazar a impressão digital, ajudaste a construir um perfil sombra de cada visitante.

Como corrigir

Esta é uma regra de deteção, não uma flag de configuração. A correção é auditar o que está a correr e gating atrás do consentimento.

1. Inventário. Abre DevTools → Network → filtra por Initiator e procura os scripts que o MetricSpot assinalou. Segue cada um até uma regra do gestor de tags ou um <script> no template. Se não sabes porque está lá, não devia estar.

2. Decide se precisas dele. Deteção de fraude numa página de checkout pode justificar o FingerprintJS Pro. Uma landing page de marketing quase nunca o faz. A exceção do EDPB para “estritamente necessário” é restrita — segurança e prevenção de fraude podem qualificar, enriquecimento de analytics não.

3. Gating atrás do consentimento. Se mantiveres o script, carrega-o apenas depois de o utilizador dar opt-in. Com uma CMP (OneTrust, Cookiebot, Iubenda, Klaro):

<!-- Não carregar diretamente -->
<script src="https://fpjs.io/web/v3/<key>/loader.js"></script>

<!-- Gating via CMP - exemplo: Klaro -->
<script type="text/plain" data-name="fingerprintjs"
        src="https://fpjs.io/web/v3/<key>/loader.js"></script>

Depois no teu klaro-config.js:

services: [{
  name: "fingerprintjs",
  purposes: ["security"],
  required: false,
  default: false,
}]

4. Deteção do lado do servidor. Se o fornecedor oferecer um SDK server-side (a serverApi do FingerprintJS Pro), prefere-o em rotas autenticadas — permanece dentro da tua fronteira de confiança de primeira parte e é mais fácil de auditar.

5. Documenta-o. Atualiza a tua política de privacidade para nomear o fornecedor, o propósito (“prevenção de fraude em pagamentos”), os dados recolhidos e o período de retenção. Boilerplate genérico não chega.

Combina esta regra com a verificação de rastreadores de terceiros — ambas examinam o mesmo inventário de scripts de ângulos diferentes.

Perguntas frequentes

O “rastreio sem cookies” é legal na UE?

Não, não sem consentimento. O pitch de marketing de que cookieless = sem consentimento está errado segundo a interpretação atual do EDPB. O gatilho para o consentimento é ler ou escrever no dispositivo, independentemente do mecanismo.

E analytics server-side como o Plausible ou Fathom?

Esses estão bem. Derivam um hash diário-rotativo do IP + user-agent no servidor, nunca o armazenam, e não sondam APIs do lado do cliente. A allow-list do MetricSpot exclui-os.

A minha equipa de fraude precisa do FingerprintJS no checkout. Posso mantê-lo?

Provavelmente sim, com âmbito restrito: carrega-o apenas em /checkout e /login, documenta o propósito de segurança na tua política de privacidade, e apoia-te na exceção do EDPB “estritamente necessário para um serviço explicitamente pedido pelo utilizador”. Obtém aprovação do jurídico — a fronteira é específica de cada jurisdição.