Il rollback è una prova, non una lista di comandi inversi

Trasparenza: sviluppo Tabwell. La versione pubblica 1.1.1 consolida, dopo un test funzionale esterno, l’architettura di ripristino introdotta dalla 1.1.0: bundle con più finestre, journal locale durevole, Gentle Restore e operazioni «Salva e chiudi» / «Sostituisci corrente» progettate per fallire senza nascondere lo stato.

Il problema generale è questo: in un’estensione Manifest V3 non esiste una singola transazione che comprenda più finestre di Chrome. Il service worker può essere sospeso, una scheda può cambiare indirizzo e un gruppo può essere ricostruito soltanto in parte. Al risveglio, eseguire alla cieca i comandi inversi non è un rollback: è una seconda mutazione basata su informazioni vecchie.

Per questo il journal deve conservare almeno quattro cose distinte:

1. l’intento, con l’identità dell’operazione e lo snapshot scelto;
2. una traccia durevole della fase e della frontiera già raggiunta;
3. la relazione tra l’operazione e gli oggetti creati;
4. una ricevuta finale che dica che cosa è davvero avvenuto e se un nuovo tentativo è sicuro.

La 1.1.1 ha irrigidito proprio il terzo confine. Se l’aggiornamento dei metadati di un gruppo esaurisce i tentativi, Tabwell rilegge lo stato corrente e rimuove soltanto la struttura che può ancora essere verificata come creata dalla stessa operazione. Se la prova non coincide, conserva l’oggetto. È una scelta meno elegante di una pulizia totale, ma più corretta: l’utente o un’altra operazione potrebbero aver già riutilizzato quella scheda o quel gruppo.

Lo stesso principio compare in «Sostituisci corrente». Chrome può esporre temporaneamente `pendingUrl` anche quando la destinazione effettiva non è cambiata: la 1.1.1 accetta quel segnale stretto, ma continua a fermarsi davanti a una vera deriva dell’URL. Non si tratta di rendere l’operazione permissiva; si tratta di distinguere un’osservazione transitoria da una modifica reale.

Anche Stop ha un significato preciso. Interrompe il coordinamento di Gentle Restore, ma non chiude automaticamente le schede segnaposto già create. Senza una ricevuta durevole di proprietà, la pulizia automatica rischierebbe di eliminare una scheda che nel frattempo è diventata utile. Questa limitazione resta visibile e intenzionale.

La lezione utile oltre Tabwell: un rollback affidabile non è la lista inversa dei passi eseguiti. È un obbligo di prova applicato allo stato presente. Se non si può dimostrare di possedere ancora un oggetto, conservarlo è spesso la decisione meno distruttiva.

Figura — il flusso «intento → traccia durevole → riconvalida → risultato». Il ramo verde consente la pulizia soltanto quando la proprietà coincide; il ramo ambra conserva lo stato quando la prova manca.

Testo e diagramma preparati con assistenza AI e ricontrollati sui fatti della release pubblica 1.1.1. #software #affidabilità #browser #testing

Ripristinare una sessione senza nascondere le decisioni

Trasparenza: sviluppo Tabwell, un’estensione per browser. Quando una sessione deve essere ricostruita, riaprire le schede è soltanto l’ultimo passaggio. Prima bisogna sapere che cosa è stato salvato, quale operazione cambierà lo stato corrente e che cosa accade se il ripristino si interrompe.

Nella release 1.1.0 ho distinto quattro aspetti operativi:

1. Impostazioni visibili. L’interfaccia espone l’intervallo e la durata di conservazione delle istantanee, la finestra da mostrare dopo un arresto anomalo e l’eventuale ripristino automatico: scelte controllabili, non automatismi nascosti.
2. Punto di ripristino locale. Le istantanee atomiche mantengono separate le finestre e conservano le schede bloccate e attive, l’ordine complessivo delle schede e le informazioni native sui gruppi.
3. Operazioni protette. Con «Salva e chiudi», le schede originali vengono chiuse soltanto dopo il completamento del salvataggio e un nuovo controllo della finestra; «Sostituisci corrente» chiede conferma e, se si interrompe, conserva la possibilità di tornare allo stato precedente.
4. Stato dell’operazione dichiarato. Per le sessioni di grandi dimensioni, il ripristino graduale conserva lo stato di avanzamento, consente di riprendere l’operazione e rende espliciti lo stato di arresto e quello di pulizia dell’operazione. Se il risultato di una chiusura non può essere confermato, rimane «sconosciuto» invece di essere considerato riuscito. Inoltre, i checkpoint sono associati a una generazione, così un salvataggio in ritardo non può cancellare o sovrascrivere un punto più recente.

Il principio utile anche fuori da Tabwell è questo: «automatico» non significa automaticamente «affidabile». Un risultato verificabile può essere anche «sconosciuto»: la differenza è dichiararlo invece di confonderlo con un successo. L’automazione diventa verificabile quando impostazioni, punto di ripristino, operazione potenzialmente distruttiva ed esito restano distinguibili.

Figura 1 — interfaccia reale di Tabwell 1.1.0 in italiano. Le impostazioni mostrano intervallo e conservazione delle istantanee, protezione da arresto anomalo, finestra di ripristino e ripristino automatico disattivato.

Figura 2 — diagramma editoriale dei quattro livelli operativi: impostazioni visibili, punto di ripristino locale, operazione protetta e stato dichiarato.

Ho verificato testo e immagini sulla release pubblica 1.1.0. Un’IA ha aiutato nella struttura e nella revisione linguistica; ho controllato personalmente i fatti di prodotto e le due immagini.

#informatica #browser #affidabilità

## Uno zero locale non descrive tutta la rete

Trasparenza: sviluppo Mailshade, un’estensione per browser. Nella versione 1.0.7 ho cambiato una frase del report perché un risultato apparentemente semplice poteva suggerire una conclusione troppo forte.

Se, in un intervallo e per una sorgente selezionata, il report mostra zero eventi osservati, la conclusione corretta è limitata: **nel perimetro disponibile all’estensione non sono stati registrati eventi che soddisfano quei filtri**. Non equivale a dire che il messaggio non contenesse tracker.

Il motivo è architetturale. Un’estensione vede ciò che arriva al browser e ciò che il client di posta rende osservabile. Alcuni provider possono però caricare immagini attraverso un proxy prima che la pagina le esponga. Proton Mail è un caso rilevante: l’assenza di un evento nel DOM non dimostra l’assenza di una richiesta a monte.

Per leggere correttamente una misura locale conviene separare almeno quattro domande:

1. la casella era abilitata nell’estensione?
2. il profilo aveva ancora il permesso host necessario?
3. il client ha esposto la risorsa al livello osservabile?
4. l’intervallo e il filtro del report includevano quell’evento?

Solo dopo queste verifiche uno zero diventa un dato interpretabile. Rimane comunque un dato sul confine misurato, non un verdetto sull’intera rete del provider.

La stessa distinzione vale per il filtro “eventi da”: seleziona la sorgente degli eventi storici visualizzati; non abilita né disabilita oggi una casella e non riscrive il passato. Separare stato corrente, permessi e storico evita di trasformare l’interfaccia in una promessa che il sistema non può verificare.

Figura 1 — interfaccia italiana reale della release 1.0.7 con dati dimostrativi deterministici; non sono dati di una casella reale.

Figura 2 — diagramma editoriale del confine tra rete del provider, DOM osservabile e report locale.

Testo e verifica tecnica preparati con assistenza IA.

#privacy #informatica #accessibilità