Cookie e token do Facebook no computador: cinco coisas, um nome só

Vale começar por uma observação sobre a própria busca. Se você digitar esse assunto no Google no Brasil, as sugestões vêm todas em inglês: cookies json, cookie checker, how to get facebook cookies, cookie editor extension. A versão em português da pergunta praticamente não existe, e "o que é cookie de sessão" não devolve sugestão nenhuma.

Isso diz algo útil: quem chega aqui já está com um arquivo na mão e quer saber o que fazer com ele. Então esta página não explica o conceito por três parágrafos. Ela separa os objetos que estão todos sendo chamados de cookie, porque é essa confusão que faz gente perder acesso.

Os cinco objetos que recebem o mesmo apelido

• Cookie de sessão do navegador. É o que prova que aquela aba já está autenticada. Vive no navegador, morre quando a sessão é encerrada do lado do Facebook ou quando você sai da conta.
• Arquivo JSON de cookies. Não é outro tipo de credencial, é o mesmo cookie exportado como texto por uma extensão. O formato é do exportador, não do Facebook, e por isso um JSON gerado por uma extensão às vezes não é aceito por outra.
• Token de acesso de aplicativo. Coisa completamente diferente. É emitido para um aplicativo agir em nome da conta pela interface de programação, tem escopo definido e é revogado retirando o aplicativo da lista de conectados, não saindo da conta.
• User agent que vem junto no pacote. Não autentica nada. É a etiqueta de navegador que combina com aquela sessão.
• Senha. Continua sendo a única coisa que permite reconfigurar a conta. Um pacote sem ela entrega uso, não posse.

A consequência prática dessa lista: trocar a senha derruba as sessões, mas não retira um aplicativo conectado, e retirar o aplicativo não derruba as sessões do navegador. São duas listas separadas, em dois lugares separados, e quem faz só uma acha que fechou a porta.

Um perfil de navegador por conta, e o motivo

A regra é conhecida e o motivo costuma ser mal explicado. Não é o endereço de rede que junta as contas primeiro. É o perfil.

Um perfil de navegador carrega cookies de todos os sites que passaram por ele, armazenamento local, histórico e extensões. Duas contas no mesmo perfil compartilham tudo isso ao mesmo tempo, e nenhum ajuste de rede desfaz essa sobreposição, porque ela acontece antes de qualquer pacote sair da máquina.

Montagem que funciona no dia a dia:

1. Um perfil dedicado por conta, criado do zero, nunca clonado de outro.
2. As extensões mínimas dentro dele. Cada extensão com permissão ampla enxerga o que a página enxerga, inclusive a sessão.
3. O user agent que veio no pacote aplicado nesse perfil, se ele veio.
4. Uma saída de rede estável para aquele perfil. Estável importa mais do que ser residencial, e vale registrar que a nossa própria prateleira de proxies é pequena, oitenta e dois anúncios de doze fornecedores, com residencial e datacenter praticamente empatados na descrição dos anúncios. Quem promete que datacenter nunca serve está vendendo uma regra que o próprio catálogo não sustenta.
5. Nada de copiar cookie entre perfis "só para testar". É o jeito mais rápido de transformar duas contas separadas em duas contas ligadas.

Por que isso é tão comum justamente no Facebook

Dá para medir. Contando os anúncios ativos por prateleira aqui no site, a etiqueta de entrega por cookies aparece assim:

• Facebook: perto de metade dos anúncios, seiscentos e oitenta e oito de mil quatrocentos e cinquenta e dois.
• Twitter e X: pouco menos de um terço.
• Instagram: menos de um anúncio em quinze.
• Gmail: menos de um em vinte e cinco, e nesses poucos a etiqueta custa mais que o dobro da mediana da prateleira.

Duas leituras saem daí. No Facebook, entregar sessão virou o normal, não a exceção, e é por isso que qualquer roteiro de operação com muitas contas passa por aqui. E no Gmail acontece o inverso: é raro e é caro, porque naquele contexto o cookie substitui algo que a plataforma protege de outro jeito. A mesma técnica tem valor de mercado oposto dependendo da plataforma.

A ordem da troca de mãos

Aqui é onde a maioria dos problemas nasce, e a ordem não é intuitiva.

1. Importe e confirme que abre. Só isso. Não mude nada ainda.
2. Abra a lista de sessões abertas e leia. Antes de derrubar. O que está ali é o inventário de quem mais tem acesso, e depois de derrubar você perde essa informação.
3. Confira o email e o telefone cadastrados. Se o email não é seu, a conta ainda não é sua, e nenhum passo seguinte muda isso.
4. Só então troque a senha, o que derruba as sessões, inclusive a sua importada. Isso é esperado. Você volta pela senha nova.
5. Depois disso, retire os aplicativos conectados que você não reconhece, que é a lista que a troca de senha não tocou.
6. Por último, ative o segundo fator, já com a senha sua e a lista de aplicativos limpa.

Quem inverte os passos dois e quatro perde o inventário. Quem pula o cinco deixa uma porta aberta que não aparece em nenhuma tela de sessão.

Duas coisas honestas sobre o método

A primeira: importar sessão não é imunidade a verificação. É comum ler que o método "pula a tela de dois fatores por completo". Ele pula o login, e isso é diferente de pular a checagem. Uma verificação pode disparar no meio do uso, e nesse momento quem não tem a senha e o email não passa dela.

A segunda: uma sessão importada tem exatamente o mesmo poder que a senha teria, e às vezes mais, porque não pede segundo fator. Um arquivo desses num diretório sincronizado com a nuvem, ou numa conversa de trabalho, é uma senha publicada. Trate como credencial, com prazo de descarte, e apague o original depois que a importação estiver confirmada.

Sobre garantia, que costuma pegar quem compra às pressas: nessa prateleira a mediana é de doze horas contadas a partir da entrega. Teste no mesmo dia. Como o relógio funciona está no guia de entrega.