Sincronização da área de transferência entre redes diferentes
Quase nenhuma ferramenta de área de transferência ou de compartilhamento consegue fazer isso, e o motivo é que elas se encontram gritando na rede local. Um broadcast não sai da sub-rede, então um celular no 4G é invisível para um notebook no Wi-Fi de casa, não importa o que você mude. Para sincronizar entre redes você precisa de uma ferramenta que se encontre no meio do caminho, num endereço conhecido — que é o que uma área de transferência no navegador faz.
De onde vem o limite do mesmo Wi-Fi
AirDrop, LocalSend, KDE Connect e o Snapdrop original funcionam do mesmo jeito por baixo. Quando você os abre, cada dispositivo manda uma mensagem de descoberta para todos os endereços do seu próprio segmento de rede — mDNS, broadcast UDP ou Bluetooth, conforme a ferramenta — e fica ouvindo as respostas. O que responder, aparece na lista.
É esse desenho que dispensa conta e configuração: ninguém precisa ser avisado de onde alguém está. E é exatamente ele que faz tudo parar na borda da rede. Roteadores não encaminham tráfego de broadcast entre sub-redes, então dois dispositivos em redes diferentes nunca ouvem um ao outro. Não há nada para consertar, nenhuma porta para abrir, nenhum ajuste que você tenha deixado passar — é o mecanismo funcionando como foi projetado.
Três situações comuns esbarram nisso, e nenhuma delas é defeito:
- Celular no 4G, notebook no Wi-Fi. Redes diferentes mesmo com os aparelhos encostados um no outro.
- Wi-Fi de escritório ou de campus com isolamento de clientes. Os dispositivos estão numa rede só, mas deliberadamente separados uns dos outros, o que é uma medida de segurança em redes de visitantes e corporativas.
- Realmente distantes — casa e trabalho, ou duas cidades diferentes.
O que funciona no lugar disso
A alternativa é os dois dispositivos se conectarem para fora, ao mesmo endereço conhecido, e serem apresentados ali. Nenhum precisa encontrar o outro, então tanto faz se estão na mesma sala ou em lados opostos do mundo. A troca é que agora existe algo no meio sabendo que os dois estão conversando — e a pergunta que importa passa a ser o que esse meio consegue ver.
| Ferramenta | Entre redes | Como os dispositivos se encontram | Área de transferência do sistema |
|---|---|---|---|
| RealtimeClipboard | Sim | Chave curta digitada nos dois | Sim |
| PairDrop | Sim | Código de pareamento de 6 dígitos | O texto chega como mensagem |
| Sincronização do Windows | Sim | Conta Microsoft | Sim, só de Windows para Windows |
| Área de Transferência Universal da Apple | Não | Bluetooth + Handoff, dentro do alcance | Sim, só entre dispositivos Apple |
| KDE Connect | Não | Descoberta na rede local | Sim |
| LocalSend / Snapdrop | Não | Descoberta na rede local | Não |
| AirDrop | Não | Bluetooth + Wi-Fi ponto a ponto | Não |
As três que atravessam redes cobram algo em troca. A sincronização do Windows quer uma conta Microsoft nas duas máquinas e só conversa com outros PCs com Windows. O PairDrop dispensa conta e é multiplataforma, mas manda o texto como mensagem em vez de colocá-lo na sua área de transferência. O terceiro caminho é uma área de transferência no navegador, que é o que o resto desta página descreve.
Sincronizar sem conta, entre quaisquer duas redes
- Abra a área de transferência no primeiro dispositivo. Ela gera uma chave curta.
- Digite essa chave no segundo dispositivo, ou leia o QR code.
- Copie alguma coisa em qualquer um dos dois.
- Vá para o outro e cole. Já está na área de transferência do sistema.
A chave é o que substitui a descoberta. Os dois dispositivos se conectam para fora, ao mesmo retransmissor, e pedem a sala que pertence àquela chave, então se encontram sem que nenhum precise saber onde o outro está. Wi-Fi de casa para 4G, notebook para celular, trabalho para casa — tudo o mesmo caso.
O que o servidor no meio consegue ver
Esta é a parte que vale detalhar, porque "passa por um servidor" é o custo real de atravessar redes e costuma ficar no vago.
O texto é criptografado no seu navegador com AES-GCM antes de
ser enviado. O retransmissor é endereçado por SHA-256(chave)
e não pela chave, então consegue encaminhar suas mensagens para a sala
certa sem nunca ter a chave necessária para lê-las. Ele não guarda nada em
disco: as mensagens existem só o tempo de serem repassadas. Arquivos
pulam o servidor inteiramente e vão direto entre os dois navegadores por
WebRTC.
O que ele vê é que alguma sala esteve ativa em algum momento, e os endereços IP das duas conexões. Ele nunca recebe sua chave, seu texto, seus nomes de arquivo nem quem você é. Esse identificador de sala passa pelo mesmo alongamento de 250.000 iterações que a chave de criptografia, então não dá para voltar dele até sua chave de forma barata — o modelo de ameaças mostra os números. O código tem licença MIT e o retransmissor é um serviço em Python pequeno o bastante para ler de uma sentada — e, se você prefere não acreditar na palavra de ninguém, pode rodar o seu e apontar o aplicativo para ele.
Vale saber antes de depender disso
- A chave é a senha
- Quem descobrir a chave consegue ler aquela sessão enquanto ela estiver aberta. Trate-a como uma senha.
- A captura automática exige Chromium
- Firefox e Safari enviam e recebem o texto que você cola, mas não conseguem ler a área de transferência por conta própria.
- Leitura em segundo plano não é possível
- Nenhum navegador lê a área de transferência com a aba em segundo plano. Você volta para a aba e ela pega o que você copiou.
- Arquivos são limitados a 5 MB
- Para qualquer coisa maior, uma ferramenta de transferência dedicada é a escolha certa.
Perguntas frequentes
Dá para sincronizar entre dispositivos em redes Wi-Fi diferentes?
Dá, mas não com ferramentas que dependem de descoberta local. AirDrop, LocalSend, KDE Connect e Snapdrop encontram dispositivos por broadcast na rede local, e esse broadcast não atravessa um roteador. Uma área de transferência no navegador funciona de outro jeito: os dois dispositivos se conectam para fora, ao mesmo retransmissor, usando uma chave compartilhada, então as redes em que estão deixam de importar.
Por que meu celular não enxerga o notebook quando está no 4G?
Porque estão em duas redes diferentes. A descoberta local só alcança dispositivos no mesmo segmento de rede, e um celular no 4G está num segmento completamente separado do notebook no Wi-Fi, mesmo com os dois lado a lado. Ligar o Wi-Fi do celular e entrar na mesma rede resolve para aquelas ferramentas; fora isso, é preciso algo que não dependa de descoberta.
Funciona no Wi-Fi de visitantes ou do escritório?
Ferramentas de descoberta local costumam não funcionar. Redes de visitantes e corporativas normalmente ativam o isolamento de clientes, que impede dispositivos da mesma rede de falarem diretamente entre si — de propósito, como medida de segurança. Uma área de transferência no navegador não é afetada, porque cada dispositivo apenas abre uma conexão HTTPS comum para fora, em vez de tentar alcançar o outro.
O servidor vê o que eu copio?
Não. O texto é criptografado no navegador antes de ser enviado, e o retransmissor é endereçado por um hash da sua chave, e não pela chave em si, então consegue encaminhar a mensagem sem conseguir descriptografá-la. Ele não guarda nada em disco. Arquivos não passam por ele — vão direto entre os dois navegadores por WebRTC.
Uma VPN faz ferramentas de rede local funcionarem entre redes?
Às vezes, e dá mais trabalho do que parece. Uma VPN em malha como Tailscale ou ZeroTier coloca os dois dispositivos numa mesma rede virtual, o que pode devolver a descoberta local — mas algumas ferramentas dependem de tráfego de broadcast que essas VPNs não encaminham por padrão, então depende da ferramenta. Também significa instalar e configurar software nos dois aparelhos, que era justamente o que a maioria queria evitar.