Os geradores de QR code estão a seguir-lhe o rasto? Como verificar em 30 segundos

Criar um QR code parece inofensivo: preenche um formulário, recebe uma imagem. O que não vê é o que acontece aos dados que escreveu — se ficam no navegador ou viajam para o servidor do fornecedor.

Para WiFi, vCard, pagamentos e quaisquer dados pessoais, essa diferença importa.

Resposta rápida

• Os geradores online de QR podem fazer tracking de duas coisas distintas: os dados que introduz (palavra-passe, contacto, URL) e quem lê o QR a seguir.
• O tracking dos dados introduzidos depende de a geração ser server-side (os dados viajam para um servidor) ou client-side (tudo acontece no navegador).
• O tracking de leituras só é possível com QR dinâmicos: o QR aponta para um URL do fornecedor que regista cada visita.
• Pode verificar em 30 segundos com as DevTools do navegador (separador Network) ao gerar o QR.
• Se introduz dados sensíveis (WiFi, vCard, pagamentos), use geradores client-side, sem registo, idealmente open source.

Que tipos de tracking existem num gerador de QR

Três camadas distintas:

1. Tracking dos dados que introduz

Quando preenche o formulário (SSID, palavra-passe, contacto, URL), essa informação pode:

• Ficar no navegador e nunca ser enviada a lado nenhum (geração client-side).
• Viajar para o servidor do fornecedor para construir a imagem e devolvê-la (geração server-side). Pode depois ficar em logs, analytics ou bases de dados.

A maioria dos geradores online é server-side por defeito, porque é a implementação mais fácil. Isso não quer dizer que o fornecedor seja malicioso, mas significa que os seus dados passam pela infraestrutura dele.

2. Tracking do utilizador que gera o QR

Como qualquer website, o gerador pode ter:

• Analytics (Google Analytics, Plausible, Matomo, etc.).
• Cookies de terceiros e pixels publicitários (Meta, TikTok, Google Ads).
• Fingerprinting do navegador para o identificar sem cookies.
• Conta obrigatória que liga cada QR que gera à sua identidade.

Isto é independente da geração do QR em si, mas faz parte do pacote.

3. Tracking de quem lê o QR

Aplica-se apenas a QR dinâmicos: o código aponta para um URL curto do fornecedor (qr.xx/abc123) que redireciona para o destino real. Cada redirecionamento é registado com:

• Hora exata da leitura.
• IP do utilizador (e portanto localização aproximada).
• Tipo de dispositivo, SO, navegador.
• Referer, se houver.

Num QR dinâmico, o tracking de leituras não é acidental — é a razão de ser do produto.

Como detetar se o seu gerador faz tracking (sem código)

Três minutos com qualquer navegador moderno:

1. Abra o gerador que pretende usar.
2. Carregue em F12 (ou clique com o botão direito → Inspecionar) e vá ao separador Network.
3. Carregue no botão vermelho de gravação / deixe o separador aberto e limpe-o (botão ⌀).
4. Preencha o formulário do QR com dados quaisquer e carregue em "gerar".
5. Observe os pedidos que aparecem na lista.

O que procurar:

• Se não aparecer nenhum pedido novo durante a geração: o QR está a ser construído 100% no navegador. Client-side. ✅
• Se aparecer um pedido POST para um URL do fornecedor logo ao gerar, com os seus campos (SSID, palavra-passe, etc.) no payload: os seus dados estão a viajar para o servidor. Server-side. ❌ para dados sensíveis
• Se a resposta é a imagem do QR (PNG ou SVG) gerada pelo backend: confirma que o servidor está a construir o código.

Verifique também se a página carrega Google Analytics, Meta Pixel ou outros scripts de tracking (verá pedidos para google-analytics.com, googletagmanager.com, connect.facebook.net, etc.).

Sinais de alarme óbvios

Sem DevTools, alguns indicadores rápidos:

• Exige registo ou conta para gerar um QR básico.
• Tem um plano "PRO" com tracking detalhado de leituras: se esse é o modelo de negócio, o tracking está no ADN do produto.
• O QR descarregado tem o URL deles em vez do seu (qr.xx/abc123 em vez de seudominio.pt): é um QR dinâmico, automaticamente rastreado.
• A política de privacidade menciona partilhar dados com terceiros, parceiros de marketing ou uso publicitário.
• Não publicam o código-fonte e a ferramenta é grátis sem modelo de negócio claro: alguém está a pagar por ela, normalmente com os seus dados.

Como verificar se um gerador é client-side

Checklist rápido:

• Funciona offline: desligue o WiFi, recarregue a página e tente gerar. Se funciona, é client-side. Se não carrega ou não permite gerar, depende do servidor.
• Sem pedidos de rede ao gerar (verificável nas DevTools como em cima).
• Sem conta exigida, sem email.
• Código-fonte inspecionável (open source ou JavaScript não minificado).
• O destino do QR é exatamente o que escreve, não um URL encurtado do fornecedor.

Se os cinco se verificarem, o gerador não o pode seguir, nem a si nem a quem lê o código.

Porque isto importa mais para WiFi, vCard e pagamentos

Para um URL público (o website do seu negócio, um PDF público), o gerador "ver" o seu URL não adiciona risco: ia ser público de qualquer forma.

Mas há três tipos de QR onde o tracking é crítico:

• WiFi: a palavra-passe da sua rede. Se viajar para o servidor do fornecedor, está fora do seu controlo.
• vCard: telefone pessoal, email, morada. Dados pessoais cobertos pelo RGPD.
• Pagamentos / Bitcoin: carteira, IBAN, dados bancários. Nível máximo de sensibilidade.

Para estes casos, usar um gerador client-side não é paranoia — é higiene básica.

Open source vs proprietário

Um gerador ser open source não garante por si só mais privacidade, mas permite-lhe:

• Auditar o código e verificar que não há tracking escondido.
• Confirmar a lógica client-side sem acreditar no fornecedor pela palavra.
• Alojá-lo por si se quiser controlo total.

Um gerador proprietário pode ser igualmente privado, mas exige confiar no que o fornecedor afirma. Sem código auditável, não há forma de verificar.

Na prática: open source + sem conta + sem rede durante a geração = o padrão de privacidade razoável mais alto.

Conclusão

Quase todos os geradores online de QR processam os seus dados no servidor. Tudo bem para um URL público, mas arriscado para WiFi, vCard ou pagamentos. Para verificar em 30 segundos, abra as DevTools, vá a Network e veja se o navegador envia algum pedido quando gera o QR. Se não enviar, é client-side e o conteúdo nunca sai do dispositivo.

QRcito gera todos os QR inteiramente no seu navegador, sem conta, sem rede durante a geração e sem trackers de terceiros. Pode verificar abrindo as DevTools antes de gerar.

FAQ

O que significa "client-side" num gerador de QR? Que o JavaScript que constrói a imagem do QR corre dentro do seu navegador. Os dados que introduz nunca são enviados para qualquer servidor. A geração é local, instantânea e funciona offline.

É legal um gerador de QR guardar os meus dados? Se a política de privacidade o declarar e aceitar, sim. O problema é que muitas políticas são vagas ou não cobrem dados específicos de QR. Na dúvida, assuma que guardam algo e escolha outra ferramenta se os seus dados forem sensíveis.

Um QR estático pode seguir quem o lê? Não. Um QR estático não passa por qualquer servidor: a informação vai diretamente do código para o leitor. Apenas os QR dinâmicos (com URL intermediário de redirecionamento) podem registar leituras.

Como se aplica o RGPD aos geradores de QR? Se introduzir dados pessoais (nome, email, telefone numa vCard) numa ferramenta server-side sediada na UE ou que serve utilizadores europeus, o fornecedor é responsável pelo tratamento ao abrigo do RGPD. Para minimizar risco e obrigações, o caminho simples é usar geradores client-side.

Porque é que o QRcito pode oferecer tudo grátis e sem tracking? Porque gerar QR codes é um processo leve que não exige infraestrutura cara. Ser client-side significa zero custos de servidor por utilizador; sem tracking nem contas, não há produto para vender. O site corre a custo muito baixo, sem necessidade de monetizar utilizadores.