Perché un dispositivo dismesso è una questione di accessi, non di archiviazione
Quando smetti di usare un telefono, un tablet o un portatile, il dispositivo in sé smette di contare — ma l’accesso che portava con sé no. Un client Mastodon che era connesso su quel dispositivo potrebbe ancora avere un token per il tuo account. La domanda da porsi prima che il dispositivo ti sfugga di mano non è “cosa c’è sul disco?” ma “cosa può ancora agire come me?”.
Questa guida separa tre azioni che è facile confondere: disconnettere una sessione, revocare un’app client e cambiare la password dell’account. Non sono intercambiabili, e farne una non fa automaticamente le altre.
Le impostazioni dell’account Mastodon permettono di revocare sessioni attive o app autorizzate. Fonte
La stessa area delle impostazioni dell’account include il cambio password e l’autenticazione a due fattori. Fonte
Questo è l’intero quadro ufficiale su cui si basa questa guida. Tutto il resto che segue è un modo di organizzare le tue decisioni, non un’affermazione sulla formulazione dei menu o sui limiti di un particolare server.
Passo 1: Inventaria il dispositivo dismesso prima di lasciarlo andare
Parti dal dispositivo stesso, finché lo hai ancora in mano. Stai costruendo una lista, non stai ancora sistemando nulla.
- Apri ogni app sul dispositivo in cui ti sei mai autenticato con il tuo account Mastodon. Includi l’app ufficiale, i client di terze parti e qualsiasi cosa ti abbia chiesto di autorizzare l’accesso.
- Annota il nome del client come appare nell’app, non come lo ricordi. Due client dello stesso sviluppatore possono sembrare simili in una lista.
- Annota se l’app si apre ancora sul tuo account senza chiederti di accedere di nuovo. Se lo fa, sta mantenendo una sessione attiva.
- Scrivi qualsiasi accesso a livello di dispositivo che hai usato, come una sessione del browser sulla stessa macchina.
- Prima di cancellare o consegnare il dispositivo, disconnettiti da ogni client che riesci ancora ad aprire. È il primo passaggio cortese e a basso rischio — ma trattalo come manutenzione, non come prova che l’accesso sia sparito.
Una disconnessione eseguita su un dispositivo che stai per perdere è la più debole delle tre azioni, perché non puoi confermare in seguito cosa il client abbia fatto con il suo token. Ecco perché il passo successivo avviene da un dispositivo che tieni.
Passo 2: Controlla sessioni e app autorizzate da un account che controlli
Accedi al tuo account Mastodon da un dispositivo che tieni. Nelle impostazioni dell’account, la stessa area copre sessioni attive, app autorizzate, cambio password e autenticazione a due fattori. Apri quell’area e leggi la lista confrontandola con l’inventario appena scritto.
Non dare per scontato che la lista sia ordinata in modo utile, e non dare per scontato che una voce sia innocua perché il nome sembra familiare. Abbina le voci alla tua scheda di lavoro per nome del client e per quando hai usato l’ultima volta quel dispositivo. Se una voce non corrisponde a nulla che riconosci, non farti prendere dal panico — prima controlla se corrisponde a un browser o a un client che hai dimenticato. Se ancora non corrisponde, trattala come sconosciuta e agisci di conseguenza.
È anche il momento di confermare che la tua configurazione di recupero sia intatta prima di cambiare qualcosa. Cambiare una password mentre la tua unica via di recupero è una casella di posta che non controlli più è il modo in cui le persone si chiudono fuori.
Passo 3: Decidi cosa fare per ogni voce
Usa la scheda di lavoro qui sotto. Lo scopo della tabella è impedirti di ricorrere al martello più grande — un cambio password — per un problema che una singola revoca risolve, o di accontentarti di una disconnessione quando il client è ancora autorizzato.
| Client / sessione | Ancora usato? | Azione | Ricontrollo |
|---|---|---|---|
| App ufficiale sul telefono dismesso | No | Disconnettiti sul dispositivo se possibile, poi revoca il client dalle impostazioni dell’account | Conferma che la voce sia sparita dalla lista delle autorizzate |
| Client di terze parti sul tablet dismesso | No | Revoca il client dalle impostazioni dell’account | Conferma che la voce sia sparita; riapri l’app sul vecchio dispositivo solo se ce l’hai ancora, per vedere che non agisce più come te |
| Sessione del browser desktop su una macchina che stai vendendo | No | Disconnettiti dalla sessione del browser, poi revoca qualsiasi voce di sessione rimanente | Accedi dal dispositivo che tieni e conferma che la vecchia sessione non appaia più |
| Client sul tuo telefono quotidiano attuale | Sì | Tienilo; non revocare | Nessuno necessario |
| Client che non riesci a identificare | Sconosciuto | Revocalo, poi osserva se un client smette di funzionare e riautorizzalo deliberatamente | Conferma che la voce sia sparita; riautorizza solo il client che usi davvero |
| Qualsiasi voce, dopo un sospetto compromesso | — | Cambia la password e controlla l’autenticazione a due fattori nella stessa area delle impostazioni | Accedi di nuovo sui dispositivi che tieni e conferma che rimangano solo i client previsti |
Una regola decisionale compatta, se vuoi una riga: ancora usato, tienilo; non usato, revocalo; sconosciuto, revocalo e riautorizza deliberatamente; sospetto compromesso, cambia anche la password.
Passo 4: Capire cosa fa davvero ogni azione — e cosa non fa
Queste tre azioni differiscono per portata, e nessuna di esse è un reset generale della tua presenza pubblica.
- Disconnettere una sessione termina quell’accesso su quel dispositivo. È l’azione più ristretta e la più facile da sbagliare, perché un client può essere disconnesso localmente pur rimanendo autorizzato a livello di account.
- Revocare un’app client ritira l’autorizzazione di quell’app. È lo strumento giusto per un client su un dispositivo che stai dismettendo. Non è lo stesso che eliminare l’app dal dispositivo, ed eliminare l’app non è lo stesso che revocarla.
- Cambiare la password è un’azione più ampia sull’account. Appartiene a un sospetto compromesso, non è un sostituto del controllo della lista delle autorizzate.
Tre limiti vanno detti chiaramente, perché sono fonti comuni di falsa sicurezza:
- Revocare l’accesso non elimina i post che hai già pubblicato. Il tuo profilo pubblico e la cronologia dei post sono una questione separata dall’autorizzazione delle app.
- Revocare l’accesso non cambia il tuo handle. Il tuo nome utente è un attributo dell’account, non un permesso del client.
- Revocare l’accesso sul tuo account non influisce sugli account che hai su altri server. Le impostazioni dell’account di ciascun server governano l’account di quel server.
Errori comuni
- Trattare una disconnessione come una revoca. Disconnettersi sul dispositivo che stai per perdere ti dice poco su cosa il client conservi ancora. Revoca dal lato account.
- Eliminare l’app e considerarlo fatto. Rimuovere un’app da un dispositivo non ritira la sua autorizzazione a livello di account.
- Cambiare la password prima e controllare dopo. Un cambio password è un’azione ampia. Controlla prima la lista delle autorizzate così sai cosa stai resettando e puoi confermare il risultato dopo.
- Revocare tutto nel panico. Romperai i client su cui conti e poi li riautorizzerai in fretta, ed è così che gli errori si accumulano. Usa la scheda di lavoro.
- Presumere che una voce sconosciuta sia un intruso. Potrebbe essere un browser o un client dimenticato. Indaga prima di concludere, ma non lasciare una voce sconosciuta al suo posto mentre indaghi.
- Presumere che la revoca nasconda i tuoi post pubblici. Non lo fa. Se la tua preoccupazione è la visibilità pubblica piuttosto che l’accesso delle app, è un compito diverso — vedi la guida esistente su come nascondere la tua rete Mastodon e controllare le preferenze di indicizzazione nei motori di ricerca.
- Dimenticare l’autenticazione a due fattori. Si trova nella stessa area delle impostazioni delle sessioni e dei cambi password. Controllala nello stesso passaggio invece che come ripensamento.
Proteggere la tua impronta dopo che il dispositivo è andato
Una volta che il dispositivo dismesso non è più nelle tue mani, il lavoro rimanente riguarda la superficie pubblica piuttosto che l’accesso delle app. Due cose vanno separate nella tua testa:
Gli identificatori pubblici sono indizi, non prove. Se cerchi un nome utente e trovi handle corrispondenti, foto corrispondenti o biografie corrispondenti su più piattaforme, quello è un insieme di indizi. Non è prova che gli account appartengano a una sola persona. Le persone riusano handle, copiano biografie e condividono immagini del profilo; lo stesso handle su due piattaforme può appartenere a due persone diverse. Tratta ogni corrispondenza come qualcosa da corroborare, mai come un’identificazione.
Una ricerca di nome utente non è un inventario degli account. Cercare un handle ti dice dove quella stringa appare pubblicamente. Non elenca ogni account che una persona possiede, e non ti dice quali account sono attivi, dormienti o rinominati. Se stai controllando la tua impronta, parti dagli handle che sai di aver usato e controlla ciascuno deliberatamente.
Se vuoi un punto di partenza per quell’autocontrollo, TraceSeek controlla un nome utente su 3.000+ piattaforme e restituisce corrispondenze pubbliche in circa 20–30 secondi, con una prima scansione gratuita. Riporta ciò che è pubblicamente visibile; non cambia impostazioni su nessuna piattaforma, non garantisce una corrispondenza e non verifica l’identità di nessuno. Per come leggere le corrispondenze, vedi la pagina della metodologia.
Fatti chiave
- Le impostazioni dell’account Mastodon permettono di revocare sessioni attive o app autorizzate.
- La stessa area delle impostazioni dell’account include il cambio password e l’autenticazione a due fattori.
- Disconnettere una sessione, revocare un’app client e cambiare la password sono azioni distinte con portata diversa.
- Revocare l’accesso delle app non elimina i post pubblicati, non cambia un handle e non influisce sugli account su altri server.
- Una corrispondenza pubblica di nome utente è un indizio da corroborare, non prova che gli account appartengano alla stessa persona.