Exportar cookie: quando faz sentido e quando queima a sessão

A máquina do gestor pifa na sexta. Alguém lembra que “dá para colar o cookie no outro Chrome” e a BM reabre em quatro minutos. Às vezes isso salva o plantão. Às vezes a plataforma trata o login como sequestro e a sessão que era saudável vira checkpoint eterno. Exportar cookie não é mágica de identidade. É copiar um crachá. O crachá só convence se o uniforme continuar parecendo o mesmo.

Este texto é o recorte de migração. O texto irmão sobre cookies versus fingerprint separa storage de medição. Aqui a pergunta é operacional: quando o time deve mover a sessão, quando deve nascer login fresco, e o que o arquivo no Drive faz com o dono da conta.

Sessão emprestada não é conta nova

Cookie é storage. Guarda o token que diz “este browser já autenticou”. Exportar é copiar esse storage. Importar é colar. A identidade no servidor não muda. BM, MCC, pixel, cartão, restrição, histórico de anúncio: tudo permanece. Você só mudou o crachá de bolso.

Por isso o atalho mental “exportei, então é ambiente novo” é falso. Ambiente novo seria perfil nascido limpo, IP coerente, fingerprint estável, login que a plataforma emitiu naquele retrato. Cookie colado é o login antigo tentando morar noutro retrato. Se os retratos forem primos, a plataforma pode aceitar. Se forem estranhos, a plataforma vê mudança brusca de dispositivo. Mudança brusca de dispositivo é o padrão de roubo de sessão.

Há um segundo equívoco: achar que exportar é backup de reputação. Reputação não vive no JSON. Vive no grafo da conta e no histórico daquele ambiente. O arquivo só evita o 2FA na tarde de pânico. Evitar 2FA não é estratégia. É comodidade. Comodidade tem preço quando o arquivo vaza ou quando o destino não parece com a origem.

Trate o export como chave. Quem segura o arquivo entra enquanto o token valer. Não precisa da senha. Não precisa do SMS. Por isso o grupo de WhatsApp, o Notion da agência e a pasta Downloads do plantão são o lugar errado. O lugar certo é o mesmo critério de senha: poucos donos, rastreio, revogação.

Quando a migração é o caso honesto

Máquina morta. Disco na assistência. Notebook da empresa trocado pelo TI. Perfil de operação que precisa mudar de ferramenta de browser com a mesma identidade. Esses são os casos em que mover sessão pode ser mais limpo do que forçar um login novo no calor, com 2FA no celular de quem já saiu de férias.

O critério é continuidade. A identidade continua a mesma. O anunciante continua o mesmo. O job continua o mesmo. Você está mudando o suporte físico da sessão, não inventando um gêmeo. Se o time está exportando para “abrir outra BM no mesmo cookie”, o caso não é migração. É atalho de grafo. Não faça.

Continuidade pede alinhamento. O destino deve parecer a origem. Mesma família de sistema — Windows que continua Windows, não um salto súbito para um retrato de mobile. Mesmo fuso. Mesmo idioma. Mesmo país de IP, de preferência o mesmo tipo de ASN. Se a origem era residencial estável em Curitiba, o destino não é datacenter em Miami. Isso não é migração. É teleporte.

Há o caso de escolher navegador antidetect para sair do Chrome da casa. Muita agência quer levar a sessão pronta para o perfil isolado. Pode funcionar se o perfil novo for coerente e se ninguém publicar no mesmo minuto. O AdSafe, nesse recorte, é o perfil isolado da identidade — não um botão que lava cookie velho. O cookie continua sendo o crachá antigo. O isolamento só impede que o crachá more na mesma jarra que o da BM vizinha.

Há o caso que não é honesto e o time disfarça: freelancer, plantão externo, “só o final de semana”. Exportar cookie para terceiro é dar admin temporário sem convite, sem papel, sem registro de quem entrou. Quando der errado, você não revoga um usuário. Você espera o token expirar. Isso não é cobertura. É buraco.

O que a plataforma vê quando o retrato muda

Você não precisa de um ID místico. Precisa da lista chata. Fingerprint do browser: tela, GPU, fontes, User-Agent, fuso. IP e ASN. WebRTC. Horário. Sequência. Cookie antigo em retrato novo empilha divergência. Uma divergência leve — outro notebook da mesma mesa, mesmo proxy — às vezes passa. Cinco divergências ao mesmo tempo — outro país, outro canvas, outro fuso, horário de madrugada, datacenter — parece sequestro.

A analogia útil é o cartão de crédito usado em outro continente no mesmo dia. O banco não “prova” que foi você. Sinaliza risco. Pede verificação. Às vezes bloqueia. Plataforma de anúncio faz o análogo com sessão. Checkpoint, captcha, senha de novo, deslog. Em conta já marcada, o análogo é pior. A sessão colada vira mais um ponto no cluster.

Por isso “colar e anunciar em dez minutos” é o pior rito. Você junta mudança de dispositivo com velocity de publicação. Dois sinais de abuso no mesmo bloco. Se a migração for necessária, importe, deixe a sessão existir, navegue como humano no painel, não dispare cem criativos. Paciência não é folklore de aquecimento mágico. É não parecer script de cookie stuffing.

WebRTC desencontrado piora. HTTP no proxy, candidato na LAN da casa: dois mundos. Cookie de um mundo colado noutro. O texto de vazamento WebRTC existe para esse furo. Não migre sessão para um perfil que ainda vaza o escritório. Primeiro o retrato. Depois o crachá.

Alinhar destino: checklist curto

Antes de exportar, escreva o retrato de origem. Sistema, fuso, idioma, geo do IP, tipo de proxy, sticky, horário habitual de login. Sem isso, o destino é chute.

No destino, monte o perfil vazio. Confira HTTP, WebRTC, DNS, fuso e idioma. Os cinco têm que contar a história que você escreveu. Se não contam, não importe. Corrija o ambiente. Cookie não conserta proxy.

Importe. Abra o painel. Não publique. Não troque cartão. Não convide admin. Não exporte público. Olhe. Se pedir senha, é sinal: o token não convenceu. Aí o caminho honesto é o login fresco no ambiente já alinhado, não insistir no arquivo.

Se entrar, espere. Horas, não segundos. O plantão odeia isso. O plantão também odeia checkpoint no meio da campanha. Escolha o ódio menor com antecedência: migração de máquina se planeja, não se improvisa no anúncio do cliente.

Depois, invalide a sessão antiga se a origem ainda existir. Dois discos com o mesmo cookie são dois crachás. Perda da máquina: assuma o arquivo como único. Máquina velha formatada: não deixe o perfil antigo vivo “por precaução”. Precaução nesse caso é duplicar sessão.

Documente. Quem exportou, de qual perfil, para qual perfil, quando, por quê. Sem registro, a próxima auditoria acha um JSON na pasta e não sabe se é backup ou vazamento. Agência que já organiza identidade por perfil aguenta essa linha. Agência que vive de pasta no Chrome não sabe nem de onde saiu o arquivo.

Quando o login fresco é mais barato

Ambientes distantes. Origem residencial Brasil, destino escritório com IP de cloud. Origem Windows, destino que se apresenta como outro universo de canvas. Origem horário comercial, destino plantão em fuso invertido no mesmo dia. Nesses casos, force login novo no retrato novo. O 2FA chato de uma tarde vale menos do que a sessão marcada.

Conta já em restrição. Colar cookie de conta quente em perfil novo junta dois problemas. A plataforma já olha a identidade. Agora olha o teleporte. Deixe a conta quente no recurso oficial. Não “salve” com JSON.

Terceiro na operação. Freelancer, estagiário, outra agência na passagem de conta. O caminho é convite e papel. Não é cookie. Cookie não tem papel. Cookie é admin implícito enquanto valer. Passagem de conta se faz com revogação e convite, não com arquivo.

Dúvida de malware na origem. Exportar cookie de disco suspeito é empacotar o incidente. Formate. Recrie perfil. Login fresco. O JSON do notebook que baixou o crack não é semente de ambiente limpo.

Ansiedade de “não perder o aquecimento”. Não há aquecimento no arquivo. Há token. Token expira. Identidade permanece. Quem vende cookie como reputação portátil está vendendo outra coisa. Este artigo não ensina mercado de sessão. Ensina a não queimar a sessão boa da operação.

O arquivo é credencial: onde não pode morar

Downloads. Desktop. Grupo. E-mail. Drive com link público. Pendrive do plantão. Notion da wiki de senha. Cada um desses lugares já foi o enredo de um incidente real em agência. O arquivo não precisa de malware. Precisa de encaminhar.

Cofre com acesso por papel. Poucas pessoas. Revogação na saída. TTL mental: sessão exportada para migração deveria morrer na origem e não virar acervo. Acervo de cookie é acervo de chaves sem fechadura visível.

Nomeie o arquivo como se fosse senha. Não coloque o nome do cliente no JSON solto. Não sincronize a pasta do browser com o Google pessoal. Backup de máquina da empresa, se existir, trata perfil de operação como dado sensível. TI que clona disco sem política clona a BM do anunciante para o arquivo morto.

Se o cookie vazou, o rito é o de sessão comprometida: revogar, trocar fator, olhar admin e gasto, avisar o cliente. Não “gerar outro export rápido”. O segundo arquivo não lava o primeiro. Lava a ansiedade. A plataforma continua vendo o uso paralelo se o comprador do arquivo já importou.

Token que expira e arquivo que permanece

Cookie não é eterno. A plataforma revoga. O relógio revoga. Troca de senha revoga. Saída bem-feita revoga. O arquivo no Drive, se ninguém apagou, continua parecendo útil. Útil e morto. O plantão importa, toma login, acha que o export “não funciona mais”, gera outro a partir de uma sessão ainda viva. Agora há dois arquivos. Um morto, um vivo. O morto continua no Drive. O vivo vai para o grupo. Superfície duplicada.

TTL mental: o JSON vale enquanto a sessão vale. Depois da migração, apague o arquivo da origem e o da pasta de transferência. Backup de cookie “para o caso da máquina morrer de novo” é o mesmo erro do print de senha. A máquina nova já tem a sessão. O acervo não precisa do crachá antigo. Se a sessão nova morrer, o caminho é login fresco, não arqueologia de JSON.

Há plataformas que amarram o cookie a um dispositivo aparente com mais força. Importar funciona uma vez, na segunda o desafio pede senha. Trate isso como sinal, não como defeito da ferramenta. O retrato não convenceu. Não insista no arquivo. Insista no ambiente alinhado e no login que a plataforma emitir ali.

Extensão que “gerencia cookie” no perfil de produção amplia a superfície. Precisa exportar de verdade, use o fluxo da ferramenta de operação, com registro. Não instale o utilitário da moda no mesmo perfil da BM. Utilitário lê o pote. O pote é a BM.

Rito da agência, em uma página

Default: não exporte. Login no perfil da identidade, no ambiente alinhado, com 2FA no cofre — não no grupo.

Exceção: troca de máquina ou de ferramenta na mesma identidade, com retrato escrito, destino conferido, paciência antes de publicar, sessão antiga invalidada, registro.

Proibido: freelancer, plantão externo, “esquentar”, clonar BM, colar em datacenter, colar depois de malware, colar e gastar no mesmo bloco.

Quem aprova a exceção: o dono da identidade no inventário, não o primeiro que lembrou do JSON. Sem dono, não há migração. Há atalho.

O comparativo de ferramentas de browser discute isolamento, proxy e perfil. Nenhuma ferramenta transforma cookie num passaporte. Passaporte, no sentido de identidade, a plataforma já tem. O que você move é só o crachá da sessão. Mova quando o uniforme for o mesmo. Recrie o login quando o uniforme mudou de país. Essa frase evita a maior parte dos checkpoints que o time chama de “o cookie queimou sozinho”. Não queimou sozinho. Teleportou.