Cosa succede davvero all'esportazione della chat nel momento in cui la carichi

La domanda dietro la domanda

"È sicuro?" quasi mai significa "avete scritto un'informativa privacy?". Significa: la mia chat esce da questo dispositivo, e se qualcosa esce, cosa contiene esattamente. Sono domande a cui si risponde descrivendo percorsi di codice, non facendo promesse, ed è così che è scritto questo articolo.

Un'esportazione di chat è un file insolitamente delicato per due motivi. È completo, contiene ogni messaggio della conversazione selezionata e non un campione, ed è dati di altre persone quanto tuoi, perché chi sta dall'altra parte non ha acconsentito a nulla. Uno strumento che lo tratta con serietà dovrebbe saper descrivere in concreto il viaggio del file: quale processo lo legge, cosa esce da quel processo e cosa un endpoint può ricevere.

Primo passaggio: il file va in un Web Worker, non su un server

Quando carichi un export .txt o .zip, il file viene passato a un Web Worker, cioè un thread JavaScript separato all'interno della tua stessa scheda del browser. Serve a evitare che un lavoro pesante blocchi l'interfaccia, e l'effetto collaterale rilevante qui è l'isolamento: il worker riceve il file, il thread principale no.

Dentro quel worker succede tutto. Il testo viene diviso in righe, ogni riga diventa un timestamp, un mittente e un corpo, e da quella struttura si calcolano tutte le statistiche: conteggi di messaggi, tempi di risposta, giorni attivi, emoji, frasi ricorrenti. Il worker è il posto dove il testo grezzo vive e dove resta.

Non esiste un endpoint di upload per l'export. È la versione secca dell'affermazione, ed è quella che chiude davvero la questione, perché un server che non riceve mai un file non può conservarlo di nascosto. L'analisi gira sulla tua macchina, con la tua CPU. Su un export molto grande te ne accorgi, e proprio quello è l'indizio: il lavoro è locale.

Secondo passaggio: cosa torna indietro al thread principale

Un worker comunica con la pagina scambiando messaggi attraverso un confine. Tutto ciò che attraversa quel confine è qualcosa che abbiamo deciso di mandare. Qui tornano indietro numeri derivati e stringhe brevi derivate: conteggi, medie, classifiche, i nomi dei partecipanti già presenti nell'export, le espressioni più ricorrenti sopravvissute all'aggregazione. I corpi dei messaggi non fanno quel viaggio.

Non è un cavillo tecnico. Il thread principale è quello che disegna la schermata, ed è il livello che in un'implementazione meno attenta potrebbe spedire qualcosa a uno strumento di analytics o a un servizio di error reporting. Se il testo della conversazione non arriva mai lì, lì non c'è nulla da far uscire. Il confine tra worker e pagina funziona come controllo di privacy, non solo come accorgimento di prestazioni.

Spiega anche un limite che qualcuno nota: non puoi chiedere al recap di mostrarti un messaggio preciso, perché quando l'interfaccia esiste ha visto soltanto l'aritmetica.

Terzo passaggio: l'unico endpoint che esiste, e i tre valori che accetta

Uno strumento con zero chiamate al server sarebbe una cosa strana da costruire e facile da millantare, quindi ecco la versione onesta. Esiste un endpoint, /api/wrap/commit, e serve al conteggio, cioè a registrare che un recap è stato generato.

Il suo schema accetta esattamente tre valori scalari e rifiuta qualunque altra cosa. Non li ignora e non li ripulisce: la richiesta non passa la validazione. Ha peso, perché quell'endpoint è l'unico punto attraverso cui un client potrebbe provare a far transitare contenuto della chat, e la strettezza del contratto elimina la possibilità invece di limitarsi a scoraggiarla.

Nella tabella wraps finisce di conseguenza pochissimo: una data, un conteggio di messaggi, l'indicazione se la chat era a due o di gruppo, e una lingua. Nessun nome di partecipante. Nessun testo. Nemmeno le statistiche che stai guardando a schermo. Una riga dice che un recap è avvenuto e quanto era grande l'input. Non può dire con chi parli né di cosa.

Il recap salvato sta in un'altra tabella, di proposito

Se salvi un recap in una libreria per riaprirlo dopo, qualcosa in più viene conservato: le statistiche calcolate, nomi dei partecipanti ed espressioni ricorrenti compresi. È inevitabile, perché un recap salvato che non salva nulla non è un recap salvato.

Quello che viene conservato è l'output, mai la trascrizione. I messaggi che hanno prodotto una certa espressione non viaggiano con essa, e non esiste un percorso che dal recap salvato riporti alla conversazione riassunta.

Tenerlo in una tabella deliberatamente separata da quella di conteggio è una scelta progettuale che vale la pena dire ad alta voce. Due tabelle con contenuti diversi e ragioni d'esistere diverse non possono confondersi l'una nell'altra. La riga di conteggio resta una riga di conteggio anche per chi non salva mai niente, e il recap salvato resta legato solo all'azione che lo ha creato.

Come verificarlo da solo

Non fidarti di una spiegazione sulla parola, nemmeno di questa. Apri gli strumenti per sviluppatori del browser, vai nella scheda rete e carica un export. Vedrai caricarsi le risorse della pagina e, soprattutto, non vedrai una richiesta con un corpo da svariati megabyte. Genera il recap e guarda cosa contiene la chiamata di commit: tre valori.

Lo stesso test funziona con qualsiasi strumento di analisi chat tu stia valutando, ed è un filtro migliore della lettura di una pagina legale. Un'informativa descrive le intenzioni, la scheda rete descrive il comportamento. Se un sito manda la tua trascrizione da qualche parte, lì si vede, qualunque cosa dica il testo promozionale.

Seconda verifica: stacca la connessione dopo che la pagina si è caricata e prova a generare un recap. L'analisi locale continua a funzionare fino al punto in cui deve registrare che il recap è avvenuto. Un'analisi lato server si ferma e basta.

Da cosa questo non ti protegge

L'elaborazione locale risolve il problema della trasmissione. Non risolve tutto, e sostenere il contrario sarebbe la stessa esagerazione che questo articolo critica.

Il file di export resta nella cartella dei download dopo che lo hai richiesto a WhatsApp, in chiaro, leggibile da qualsiasi cosa abbia accesso a quel dispositivo. Cancellarlo quando hai finito è un'abitudine sensata. Qualunque screenshot che mandi in un gruppo è uscito dal recinto locale per tua scelta, il che va benissimo purché sia una scelta consapevole. E l'altra persona nella conversazione continua a non aver acconsentito a essere analizzata, che è una questione che riguarda te e non il software.

L'affermazione stretta è quella corretta. Con questo strumento la chat non lascia il tuo dispositivo. Cosa fai del recap dopo è una decisione separata, ed è tua.