Por que um dispositivo aposentado é uma questão de acesso, não de armazenamento
Quando você para de usar um celular, tablet ou notebook, o dispositivo em si deixa de importar — mas o acesso que ele carregava não. Um cliente Mastodon que estava conectado nesse dispositivo pode ainda manter um token da sua conta. A pergunta que vale responder antes de o dispositivo sair das suas mãos não é “o que está no disco?”, mas “o que ainda pode agir como eu?”.
Este guia separa três ações que são fáceis de confundir: encerrar uma sessão, revogar um aplicativo cliente e trocar a senha da conta. Elas não são intercambiáveis, e fazer uma não faz automaticamente as outras.
As configurações da conta do Mastodon permitem que os usuários revoguem sessões ativas ou aplicativos autorizados. Fonte
A mesma área de configurações da conta inclui troca de senha e autenticação de dois fatores. Fonte
Esse é o quadro oficial completo em que este guia se baseia. Todo o restante abaixo é uma forma de organizar suas próprias decisões, não uma afirmação sobre o texto dos menus ou limites de qualquer servidor específico.
Passo 1: Faça um inventário do dispositivo aposentado antes de se desfazer dele
Comece pelo próprio dispositivo, enquanto ainda o tem em mãos. Você está montando uma lista, não consertando nada ainda.
- Abra todos os aplicativos no dispositivo em que você já fez login com sua conta do Mastodon. Inclua o app oficial, clientes de terceiros e qualquer coisa que tenha pedido autorização de acesso.
- Anote o nome do cliente como ele aparece no aplicativo, não como você se lembra. Dois clientes do mesmo desenvolvedor podem parecer semelhantes em uma lista.
- Anote se o aplicativo ainda abre na sua conta sem pedir para você entrar novamente. Se sim, ele mantém uma sessão ativa.
- Anote qualquer login em nível de dispositivo que você usou, como uma sessão de navegador na mesma máquina.
- Antes de apagar ou entregar o dispositivo, saia de cada cliente que você ainda consegue abrir. Essa é a primeira passada cortês e de baixo risco — mas trate-a como arrumação, não como prova de que o acesso sumiu.
Um logout feito em um dispositivo que você está prestes a perder é a mais fraca das três ações, porque depois você não pode confirmar o que o cliente fez com o token. É por isso que o próximo passo acontece a partir de um dispositivo que você vai manter.
Passo 2: Revise sessões e aplicativos autorizados a partir de uma conta que você controla
Entre na sua conta do Mastodon a partir de um dispositivo que você vai manter. Nas configurações da conta, a mesma área cobre sessões ativas, aplicativos autorizados, troca de senha e autenticação de dois fatores. Abra essa área e leia a lista comparando com o inventário que você acabou de escrever.
Não presuma que a lista está ordenada de forma útil e não presuma que uma entrada é inofensiva só porque o nome parece familiar. Relacione as entradas com sua planilha pelo nome do cliente e por quando você usou aquele dispositivo pela última vez. Se uma entrada não corresponder a nada que você reconheça, não entre em pânico — primeiro verifique se ela corresponde a um navegador ou a um cliente que você esqueceu. Se ainda assim não corresponder, trate-a como desconhecida e aja sobre ela.
Este também é o momento de confirmar que sua configuração de recuperação está intacta antes de mudar qualquer coisa. Trocar a senha quando sua única rota de recuperação é uma caixa de e-mail que você não controla mais é como as pessoas se trancam para fora.
Passo 3: Decida o que fazer com cada entrada
Use a planilha abaixo. O objetivo da tabela é impedir que você recorra à maior marreta — a troca de senha — para um problema que uma única revogação resolve, ou que se contente com um logout quando o cliente ainda está autorizado.
| Cliente / sessão | Ainda usa? | Ação | Reverificar |
|---|---|---|---|
| App oficial no celular aposentado | Não | Saia no dispositivo, se possível, e depois revogue o cliente nas configurações da conta | Confirme que a entrada sumiu da lista de autorizados |
| Cliente de terceiros no tablet aposentado | Não | Revogue o cliente nas configurações da conta | Confirme que a entrada sumiu; reabra o app no dispositivo antigo só se ainda o tiver, para ver que ele não age mais como você |
| Sessão de navegador no desktop de uma máquina que você está vendendo | Não | Saia da sessão do navegador e depois revogue qualquer entrada de sessão restante | Entre a partir do dispositivo que você mantém e confirme que a sessão antiga não aparece mais |
| Cliente no seu celular diário atual | Sim | Mantenha; não revogue | Nada necessário |
| Cliente que você não consegue identificar | Desconhecido | Revogue e depois observe se algum cliente para de funcionar e reautorize-o deliberadamente | Confirme que a entrada sumiu; reautorize apenas o cliente que você realmente usa |
| Qualquer entrada, após suspeita de comprometimento | — | Troque a senha e revise a autenticação de dois fatores na mesma área de configurações | Entre novamente nos dispositivos que você mantém e confirme que só os clientes esperados permanecem |
Uma regra de decisão compacta, se você quiser uma linha: ainda usa, mantenha; não usa, revogue; desconhecido, revogue e reautorize deliberadamente; suspeita de comprometimento, troque a senha também.
Passo 4: Entenda o que cada ação realmente faz — e o que não faz
Essas três ações diferem em escopo, e nenhuma delas é uma redefinição geral da sua presença pública.
- Encerrar uma sessão termina aquele login naquele dispositivo. É a ação mais restrita e a mais fácil de errar, porque um cliente pode ser desconectado localmente enquanto permanece autorizado no nível da conta.
- Revogar um aplicativo cliente retira a autorização desse app. É a ferramenta certa para um cliente em um dispositivo que você está aposentando. Não é o mesmo que excluir o app do dispositivo, e excluir o app não é o mesmo que revogá-lo.
- Trocar a senha é uma ação de conta mais ampla. Ela pertence a uma suspeita de comprometimento, não como substituta da revisão da lista de autorizados.
Três limites merecem ser ditos com clareza, porque são fontes comuns de falsa confiança:
- Revogar o acesso não exclui posts que você já publicou. Seu perfil público e histórico de posts são uma questão separada da autorização de aplicativos.
- Revogar o acesso não muda seu identificador (handle). Seu nome de usuário é um atributo da conta, não uma permissão de cliente.
- Revogar o acesso na sua conta não afeta contas que você mantém em outros servidores. As configurações de conta de cada servidor governam a conta daquele servidor.
Erros comuns
- Tratar um logout como revogação. Sair no dispositivo que você está prestes a perder diz pouco sobre o que o cliente ainda mantém. Revogue pelo lado da conta.
- Excluir o app e considerar resolvido. Remover um aplicativo de um dispositivo não retira sua autorização no nível da conta.
- Trocar a senha primeiro e revisar depois. Uma troca de senha é uma ação ampla. Revise a lista de autorizados primeiro para saber o que está redefinindo e poder confirmar o resultado depois.
- Revogar tudo em pânico. Você vai quebrar clientes dos quais depende e depois reautorizá-los com pressa, o que é como os erros se acumulam. Use a planilha.
- Presumir que uma entrada desconhecida é um invasor. Pode ser um navegador ou um cliente esquecido. Investigue antes de concluir, mas não deixe uma entrada desconhecida no lugar enquanto investiga.
- Presumir que a revogação esconde seus posts públicos. Não esconde. Se sua preocupação é visibilidade pública e não acesso de aplicativos, essa é outra tarefa — veja o guia existente sobre ocultar sua rede no Mastodon e revisar preferências de indexação em buscadores.
- Esquecer a autenticação de dois fatores. Ela fica na mesma área de configurações que as sessões e a troca de senha. Revise-a na mesma passada, não como pensamento posterior.
Protegendo sua própria pegada depois que o dispositivo se foi
Depois que o dispositivo aposentado sair das suas mãos, o trabalho restante é sobre a superfície pública, não sobre acesso de aplicativos. Duas coisas merecem ser separadas na sua cabeça:
Identificadores públicos são pistas, não provas. Se você pesquisa um nome de usuário e encontra handles, fotos ou biografias iguais em várias plataformas, isso é um conjunto de pistas. Não é evidência de que as contas pertencem a uma pessoa. Pessoas reutilizam handles, copiam bios e compartilham fotos de perfil; o mesmo handle em duas plataformas pode pertencer a duas pessoas diferentes. Trate cada correspondência como algo a corroborar, nunca como uma identificação.
Uma busca por nome de usuário não é um inventário de contas. Pesquisar um handle mostra onde essa string aparece publicamente. Não enumera todas as contas que uma pessoa mantém e não diz quais contas estão ativas, dormentes ou renomeadas. Se você está revisando sua própria pegada, comece pelos handles que você sabe que usou e verifique cada um deliberadamente.
Se você quer um ponto de partida para essa autorrevisão, o TraceSeek verifica um nome de usuário em 3.000+ plataformas e retorna correspondências públicas em cerca de 20–30 segundos, com a primeira verificação gratuita. Ele relata o que é visível publicamente; não altera configurações em nenhuma plataforma, não garante uma correspondência nem verifica a identidade de ninguém. Para saber como ler as correspondências, veja a página de metodologia.
Fatos principais
- As configurações da conta do Mastodon permitem que os usuários revoguem sessões ativas ou aplicativos autorizados.
- A mesma área de configurações da conta inclui troca de senha e autenticação de dois fatores.
- Encerrar uma sessão, revogar um aplicativo cliente e trocar a senha são ações distintas com escopos diferentes.
- Revogar o acesso de um aplicativo não exclui posts publicados, não muda um handle nem afeta contas em outros servidores.
- Uma correspondência pública de nome de usuário é uma pista a corroborar, não prova de que as contas pertencem à mesma pessoa.