GoodScroll
Metodo pubblico e stato delle prove
Cosa controlliamo, cosa abbiamo osservato e cosa resta ancora da dimostrare.
"La coerenza fra ciò che si dichiara e ciò che si fa è ancora possibile."
È il quinto principio del nostro manifesto, ed è
l'unico che gli altri quattro devono onorare. Una promessa tecnica che non
offre condizioni con cui possa essere smentita resta una dichiarazione,
non una prova.
Per questo censiamo qui le promesse che siamo riusciti a tradurre in
condizioni verificabili. Se una di queste condizioni viene contraddetta,
la suite interna fallisce e rende visibile a noi la divergenza
nel controllo pre-rilascio;
non blocca da sola il server già pubblicato e non sostituisce una verifica
indipendente. Questa pagina distingue strumenti, controlli ed esecuzioni
con forza probatoria diversa: è una mappa dello stato delle evidenze, non
la prova completa di ogni frase del progetto. Comprende anche i cinque
limiti che non hanno un controllo eseguibile, perché nasconderli sarebbe
già una contraddizione.
Stato attuale delle evidenze
“Pubblico”, “interno”, “osservato” e “non ancora verificato” non
sono sinonimi. Questa è la fotografia dichiarata oggi.
Controllo interno
Suite applicativa
L'inventario di sviluppo contiene 64 file: 47 nella
linea di base della 1.10.31 e 17 test-obiettivo aggiunti
dopo. Il conteggio non equivale all'esito della suite,
non osserva continuamente il server online e non è una
verifica indipendente.
Strumento pubblico
Privacy Observer 4.0.1
Metodo e codice sono scaricabili. I 33 test offline
controllano lo strumento con componenti fittizi, non
GoodScroll, Supabase o le RLS.
Run pubblicata, perimetro limitato
Preview locale senza login
Il rapporto del 27 luglio 2026 documenta 9/9 fasi su
127.0.0.1, senza autenticazione né interazioni. Non
verifica il dominio o l’hosting Aruba.
Run pubblicata, perimetro limitato
Produzione 1.10.24 senza login
Il 29 luglio 2026 il Privacy Observer 4.0.1 ha completato
9/9 fasi su goodscroll.it, con redirect osservato a
www.goodscroll.it, senza autenticazione né interazioni.
Non verifica i flussi post-login o il backend.
Run pubblicata con finding
Deployment HTTP 1.10.24
Il 30 luglio 2026 una verifica separata ha confrontato
35/35 asset statici pubblici e ha controllato versione,
redirect e percorsi protetti. Ha anche reso visibili
protezioni HTTP mancanti nella 1.10.24.
Verifica interna manuale
Backend e Supabase
RLS, ACL, RPC e catalogo vengono controllati con SQL
versionato dopo le modifiche. Il controllo non è continuo,
pubblico o indipendente.
Run pubblicata · auto-osservazione limitata
Produzione autenticata 1.10.41
Il 2 agosto 2026 la PWA ha completato 9/9 fasi con
input sintetici e pulizia riletta dal server. È stata
un'esecuzione assistita e supervisionata; il primo tentativo
TTS è fallito in modo classificato. Non è un audit indipendente.
64file nell'inventario interno
15promesse con controllo interno
5senza controllo eseguibile
Questa pagina cita 31 file di test distinti. Gli altri 33
sorvegliano integrazioni, trasporto, regressioni e costruzione del
rilascio. Diciassette dei 64 file sono test-obiettivo successivi alla
1.10.31: possono descrivere lavoro ancora da completare e non sono
presentati come prove superate. La suite resta interna e non viene
distribuita nella webroot.
Sei livelli diversi, con confini diversi
1. Suite applicativa interna. L'inventario
corrente comprende 64 file .test.cjs:
47 discendono dalla linea di base 1.10.31 e 17 sono
test-obiettivo aggiunti dopo. Controllano che codice e documenti
non si allontanino dalle condizioni censite qui, ma il numero
dei file non certifica che ogni controllo sia superato. Vengono
eseguiti nel nostro ambiente di sviluppo prima del rilascio:
non girano sul tuo dispositivo, non sorvegliano continuamente
il server online e non sono pubblicati nella webroot.
2. Test pubblici del Privacy Observer. Sono 33 test
unitari Python, inclusi nella cartella tests/
del suo archivio scaricabile. Usano componenti fittizi, senza browser
o rete, per verificare lo strumento: redazione, regola fail-closed,
output ed errori. Non verificano l'app GoodScroll, il backend,
Supabase o le RLS e non coincidono con i 64 file
dell'inventario interno.
3. Esecuzione osservazionale. È il momento in cui il
Privacy Observer apre davvero una pagina e raccoglie le fasi dichiarate.
Sono pubblicate due esecuzioni non autenticate distinte: la preview
locale del 27 luglio 2026 e la run sul dominio di produzione del
29 luglio 2026. Nessuna delle due osserva ciò che accade dopo il
login e nessun risultato autenticato può essere ricavato
retroattivamente da queste run.
4. Prova autenticata locale nell'app. È un percorso
distinto, riservato dal server agli account di sviluppo approvati.
Usa un account di sviluppo controllato e input sintetici, guida un solo
gesto alla volta e, per il contenuto di prova, richiede che il server
confermi anche l'assenza di una riga attività preesistente prima della
prima scrittura; ne rilegge poi la pulizia prima della chiusura. Le
mutazioni sulle storie sono escluse e bloccate dal percorso, perché
ritirare una reazione può cancellarne anche lo stato di lettura. Osserva
esiti chiusi dei normali flussi applicativi e inventari browser
minimizzati, conserva lo stato soltanto in memoria e scarica il JSON
solo con un gesto esplicito. Il contratto è sorvegliato da
tests/authenticated-evidence-guide.test.cjs
e il JSON da
tests/authenticated-evidence-report-validator.test.cjs.
Lo strumento in-app non usa ADB, non controlla il sistema operativo
ed è distinto dal GoodScroll Authenticated Android Storage Observer
1.3.1. Se manca una
fase o la pulizia non è confermata, non produce un esito positivo.
Poiché è la stessa app a descrivere ciò che vede, non è un osservatore
indipendente e non prova server, RLS, ACL, log, backup, GDPR o
contenitori invisibili alla pagina; non è un audit o una certificazione.
Va eseguita in un giorno di apertura e senza un'altra sessione attiva
dello stesso account. L'avvio usa lo stato Bath appena restituito dal
server e richiede che manchino più di trentuno minuti alla transizione
successiva. La prima run completa pubblicata è stata acquisita sulla
PWA di produzione 1.10.41 tra le 17:02:59 e le 17:21:19 UTC del
2 agosto 2026. Le interazioni sono state assistite, un solo evento
alla volta, da un controllore ADB/CDP esterno e supervisionate dal
titolare; la frase segreta e la riapertura della PWA sono rimaste
sotto controllo umano. Il rapporto è stato prodotto e verificato
dall'app, non dal controllore. Le esplorazioni precedenti non
diventano prove retroattivamente.
5. Verifica del deployment pubblico. Un verificatore
HTTP separato confronta soltanto gli asset statici inclusi in una
allowlist pubblica, legge version.json
all'inizio e alla fine e controlla risposte predeterminate senza
conservare body API. I suoi confini sono sorvegliati da
tests/production-deployment-verifier.test.cjs,
tests/deployment-security-headers.test.cjs e
tests/canonical-origin.test.cjs. Non dimostra
i sorgenti PHP o l'intero server.
6. Verifica del backend. RLS, ACL, RPC e stato del
catalogo richiedono query eseguite sul database reale. Gli script
sono versionati e falliscono se il contratto atteso cambia, ma
l'esecuzione è manuale, interna e puntuale: non costituisce
monitoraggio continuo né verifica indipendente.
La diagnostica locale di reattività
è ancora un'altra misura: viene avviata nell'app soltanto da un account
di sviluppo e produce un rapporto locale che GoodScroll non riceve.
Promesse con controllo automatico interno
Per ognuna: cosa diciamo, dove lo diciamo, e cosa verifica esattamente il test.
Le righe con la spunta sono sintesi leggibili, quindi parafrasi: il contratto
eseguibile resta nel file interno indicato. Queste schede descrivono controlli
pre-rilascio, non attestano da sole il codice già in produzione. Quando una
condizione dipende dal database, la verifica del catalogo resta separata e manuale.
«Lumi non misura quanto spesso torni.»
Manifesto · Come funziona
Controllo automatico interno
tests/lumi-ethics.test.cjs ·
tests/lumi-behavior.test.cjs
- Il codice di Lumi non può contenere streak, stati evolutivi, punteggi o umori calcolati
- Il server non espone più alcun endpoint che registri un evento di Lumi
- Le vecchie chiavi di frequenza vengono cancellate dai browser che le avevano già
- Il dock non deve pulsare o richiamare attenzione automaticamente
«La risposta non viene classificata, ricordata o inviata al server.»
Come funziona · Manifesto
Controllo automatico interno
tests/lumi-behavior.test.cjs ·
tests/lumi-prompts.test.cjs
- Il check-in non deve produrre richieste di rete
- Ogni scelta deve ricevere la stessa conferma neutra
- I prompt sono locali, immutabili e privi di risposte mappate
«Nel Philosophical Bath le tre librerie per reazione della Raccolta restano consultabili senza nuove scritture; l'unico gesto sullo stato salvato è ritirare una reazione esistente. La voce parte soltanto su richiesta per un elemento ancora presente nella Raccolta. Nuovo feed, Storia del Giorno non salvata, community e Lumi restano chiusi.»
Come funziona · Privacy · Saggio
Controllo automatico interno
tests/lumi-ethics.test.cjs ·
tests/bath-saved-replay.test.cjs ·
tests/saved-view-bulk-loading.test.cjs ·
tests/story-access-boundary.test.cjs ·
tests/tts-server-timing.test.cjs ·
tests/tts-bath-source-boundary.test.cjs
- Il controllo del sorgente dell'interfaccia verifica che il Bath non devii la Raccolta alla schermata di chiusura e che carichi contenuti e storie già salvati
- La rilettura di una storia salvata non deve registrare un nuovo completamento
- Una nota già esistente resta leggibile dopo lo sblocco del Vault ma in sola lettura; non compaiono comandi per creare o modificare note ed Eco
- Nel Bath soltanto la reazione già attiva può essere ritirata; una reazione nuova o diversa resta bloccata
- Semina resta disponibile come condivisione esterna e non riapre una scrittura nel database GoodScroll
- Il nuovo feed e una Storia del Giorno non salvata restano indisponibili
- Nel giorno di chiusura anche Lumi resta indisponibile
- La stanza rifiuta di aprirsi se è il giorno del Bath
- La community non viene riaperta dalla Raccolta
- La voce non parte automaticamente: interfaccia e server la consentono soltanto per un elemento con una reazione propria ancora attiva
- L'autorizzazione del singolo elemento precede sempre cache privata e provider vocale
- Le verifiche SQL versionate controllano separatamente RLS e RPC del database; non vengono presentate come prova del comportamento dell'interfaccia
Il controllo dell'interfaccia, quello degli script SQL e un'eventuale
esecuzione sul database reale sono evidenze distinte. La presenza dei test
nel sorgente non afferma da sola che la produzione sia già stata migrata
né che tutti i controlli siano stati superati.
«Il Mind Hashrate è un'impronta locale e simbolica di campioni limitati della Raccolta: non un'identità, un punteggio o una misura della mente.»
Come funziona · Privacy · Saggio
Controllo automatico interno pre-rilascio
tests/client-latency-correctness.test.cjs ·
tests/saved-removal-reconciliation.test.cjs
- Una sola RPC restituisce un contratto versionato e dalla forma esatta
- Per ogni contenuto il materiale non supera 128 caratteri Unicode; oltre la soglia usa quattro segmenti e non il testo completo
- Ordinamento, segmenti e formato canonico rendono deterministico il calcolo SHA-256
- Vengono mostrati soltanto i primi 16 caratteri esadecimali
- Errore e Raccolta vuota restano stati diversi
- Richieste concorrenti condividono un solo volo e una risposta vecchia non può sovrascriverne una nuova
- L'impronta non viene scritta in storage, cookie o database e non viene inviata
Questo controllo riguarda il sorgente preparato per il rilascio. La
presenza, il corpo e i permessi della RPC nel database reale richiedono
anche preflight, verifica del catalogo e smoke test autenticato separati:
questa scheda non li sostituisce e non afferma da sola che la produzione
sia già migrata.
«Ricaricare, cambiare orologio o cancellare lo storage locale non abbrevia la pausa di 30 minuti.»
Come funziona
Controllo automatico interno
tests/server-feed-pause.test.cjs
- L'orologio della pausa non deve essere catturato prima dei lock
- La pagina finale non deve diventare un conto alla rovescia o riavviarsi
- La pausa deve invitare esplicitamente a lasciare la pagina
- Lo stato operativo non deve diventare una cronologia comportamentale
«GoodScroll non espone un conteggio aggregato degli Echi: nessuna scheda anticipa se o quanti ce ne siano.»
Come funziona
Controllo automatico interno
tests/echo-metrics-retirement.test.cjs
- Le due funzioni che restituivano un numero sono state eliminate dal database
- Echi accessibili senza conteggi aggregati o segnali preventivi
- Gli script di verifica restano di sola lettura
«Le note sono cifrate sul dispositivo con una frase segreta che GoodScroll non conserva.»
Come funziona · Privacy
Controllo automatico interno
tests/note-vault.test.cjs
- La frase segreta non deve apparire nei metadati persistibili
- Ogni nota deve avere un IV casuale — due note identiche non si somigliano nel database
- Il contesto crittografico impedisce di spostare una nota cifrata da una riga all'altra
- Un IV di lunghezza sbagliata deve essere rifiutato invece che accettato in silenzio
«Non usiamo raccomandazioni costruite sul tuo comportamento.»
Come funziona · Privacy
Controllo automatico interno
tests/story-invitation-ethics.test.cjs ·
tests/legacy-tracking-retirement.test.cjs
- L'invito alla storia deve avere una cadenza editoriale deterministica
- L'invito non deve usare soglie casuali o penalità comportamentali
- Dopo una storia completata non deve partire un nuovo invito giornaliero
- Le vecchie colonne di tracciamento sono state rimosse dal database
«Il metodo della diagnostica è visibile a tutti, ma nell'interfaccia soltanto un account di sviluppo autorizzato dal server può avviarla; le durate interne del backend richiedono anche una capacità firmata. I campioni restano in memoria per non più di dieci minuti e soltanto Avvio attraversa un riavvio; copia e download avvengono soltanto con un gesto e cancellano lo stato dall'app.»
Se sei arrivato qui dal menu dell'app: questo
collegamento non avvia un test e non invia dati. Spiega il metodo
della diagnostica locale, chi può eseguirla, cosa misura e cosa
esclude. La diagnostica non è il Privacy Browser Observer e non è
la suite applicativa interna.
Privacy · Menu dell'app
Controllo automatico interno
tests/performance-diagnostics.test.cjs ·
tests/developer-diagnostics.test.cjs ·
tests/proxy-server-timing.test.cjs ·
tests/tts-server-timing.test.cjs
- Il controllo resta visibile, ma lo start è disabilitato per gli account non di sviluppo
- Prima dello start una verifica server esterna al campione rinnova una capacità HttpOnly firmata e vincolata alla sessione
- L'intestazione di opt-in, da sola, non può abilitare Server-Timing
- Solo un gesto nel menu può avviare un campione, per non più di dieci minuti
- Reazione, Raccolta e Voce includono soltanto le richieste legate al singolo gesto tramite un token causale opaco
- Nella Storia del Giorno un gesto vocale riguarda soltanto il passaggio visibile: non simula tocchi, non avanza la pagina e viene interrotto quando il lettore cambia passaggio o si chiude
- Il tempo trascorso nei dialoghi di conferma o errore è escluso dalla durata tecnica dell'azione e dichiarato separatamente
- Avvio termina alla prima superficie primaria corrente; il rapporto concluso è byte-stabile rispetto ad attività tardive
- Non esistono upload, beacon o analytics per il rapporto
- Il rapporto dichiara categorie, esiti, codici HTTP, conteggi e durate; per l'avvio aggiunge il tipo di navigazione e i byte aggregati delle sole risorse statiche ammesse
- URL, query, contenuti, identificativi, account, token e timestamp assoluti sono esclusi
- Cancellazione account, reset e scrittura di note o Eco non vengono campionati
- Per le API il backend restituisce soltanto durate numeriche con nomi fissi e non inoltra l'opt-in a Supabase; per la voce non espone timing interni, il campione HTTP arriva all'ultimo byte e il gesto riesce soltanto dopo l'avvio della riproduzione
«I dati applicativi disponibili nell'app possono essere esportati; account e dati live possono essere cancellati.»
Come funziona · Privacy
Controllo automatico interno
tests/data-integrity.test.cjs ·
tests/echo-delete-regression.test.cjs
- Un export parziale deve fallire esplicitamente invece di sembrare completo
- Una cancellazione rifiutata dal server non deve sembrare riuscita
- Non deve apparire "Salvato" senza controllo dell'esito
- Una reazione non salvata deve propagare l'errore
«Gli Echi sono visibili alla community autenticata e approvata, non sul web aperto.»
Come funziona
Controllo automatico interno
tests/backend-boundaries.test.cjs ·
tests/acl-hardening.test.cjs ·
tests/schema-drift.test.cjs
- Il runtime non usa una chiave Supabase service role
- I segreti server restano in file PHP bloccati all'accesso HTTP, non negli asset HTML e JavaScript consegnati al browser
- Il permesso di lettura globale è revocato: nessun accesso anonimo
- Le funzioni privilegiate invocabili dagli utenti devono comparire nell'inventario e nell'allowlist versionati
- Se il catalogo espone una funzione non censita, il controllo fallisce; questo non dimostra da solo la qualità della revisione umana
«Ogni contenuto indica se proviene dall'AI o da una fonte umana.»
Come funziona · Manifesto
Controllo automatico interno
tests/lumi-ethics.test.cjs
- Anche il pensiero che Lumi lascia dichiara la propria origine, AI o umana
- Il pensiero proviene solo dal corpus già caricato, non da una richiesta nuova
- Il pensiero non è una ricompensa per aver completato il rito
«L'approvazione è manuale e non ha tempi garantiti.»
Home
Controllo automatico interno
tests/manual-approval.test.cjs ·
tests/account-bootstrap-cleanup.test.cjs
- Un errore di verifica deve restare un errore, non diventare "approvato"
- Ogni nuovo account nasce in attesa, mai già abilitato
«Se salti un giorno, non perdi nulla: la storia ti aspetta.»
Come funziona
Controllo automatico interno
tests/story-access-boundary.test.cjs
- Se il database non restituisce una storia, il client deve fallire chiuso
- Il codice pubblico non contiene storie di riserva da mostrare al posto di quella vera
- Il browser conserva soltanto il riferimento alla storia rinviata o iniziata; contenuto e completamento vengono recuperati e convalidati dal database protetto
«Fuori dal Bath puoi modificare o ritirare direttamente un tuo Eco. Nel Bath la community è chiusa: puoi però ritirare la reazione associata, eliminando dopo conferma anche l'eventuale Eco e nota privata.»
App
Controllo automatico interno
tests/story-echo-withdrawal-ui.test.cjs ·
tests/bath-saved-replay.test.cjs ·
tests/client-latency-correctness.test.cjs
- Fuori dal Bath il ritiro diretto dell'Eco non deve modificare la reazione o la nota privata
- Nel replay Bath la community non viene aperta e soltanto la reazione già attiva può essere ritirata
- Lo smoke SQL autenticato include separatamente le RPC di ritiro della propria reazione nel giorno di pausa
- Il modale non si chiude finché il server non ha davvero risposto
- Una lettura fallita o ambigua non deve sembrare assenza
- Un secondo ritiro accidentale viene ignorato invece di generare errori
Il controllo statico verifica la conferma nell'interfaccia e lo smoke
autenticato esegue il ritiro dentro una transazione annullata. La fixture
attuale dello smoke non dimostra però, nello stesso caso, la cancellazione
simultanea di una nota e di un Eco associati; questa scheda non la presenta
quindi come prova runtime completa né come verifica del database di produzione.
Promesse e limiti senza controllo eseguibile
Queste non hanno un test. Elencarle è parte della promessa:
se non sapessi quali sono, non sapresti dove dobbiamo ancora meritarci fiducia.
«Nessuna pubblicità. Nessun contenuto sponsorizzato.»
Manifesto
Nessun test
Oggi è vera semplicemente perché non c'è pubblicità da nessuna parte. Ma nessun
test impedisce di aggiungerla domani: si può verificare l'assenza di un tracker
noto, non l'assenza di un'intenzione futura. Resta una promessa sulla parola.
«Contenuti che stimolano il pensiero critico.»
Manifesto
Nessun test possibile
Nessun test dirà mai se un pensiero è buono. Questa promessa la puoi giudicare
solo tu, leggendo. È la ragione per cui tutto il resto di questa pagina esiste:
per lasciare che il tuo giudizio si concentri qui, invece che sul chiederti se
ti stiamo misurando di nascosto.
«Non possiamo promettere una revisione umana individuale di ogni testo.»
Manifesto
Limite dichiarato
Non è una promessa ma il suo contrario: un limite che abbiamo scelto di scrivere
invece di nascondere. Usiamo l'intelligenza artificiale per produrre in batch
parte del corpus, e questo può produrre errori, ripetizioni o testi deboli.
«Il vault protegge il database e i backup, non un browser compromesso.»
Come funziona
Limite dichiarato
Il codice che cifra le tue note è lo stesso che, se venisse manomesso, potrebbe
sottrarti la frase segreta. Nessuna crittografia lato browser può difendersi dal
browser stesso. Lo diciamo perché "cifrato" da solo suona come una garanzia
che non è.
«Made with 💚 in Italia.»
Ogni pagina
Non verificabile
E va benissimo così. Non tutto deve essere dimostrato — ma quando qualcosa
riguarda i tuoi dati o la tua attenzione, allora sì.
Cosa questi test non dimostrano
La parte che di solito non si scrive.
-
Verificano il codice, non il server in esecuzione.
Leggono i file di GoodScroll e controllano che dicano ciò che promettiamo.
Che il server online stia eseguendo esattamente quel codice è una cosa
che noi controlliamo e tu, per ora, devi credere.
-
Il database viene verificato a parte, e a mano.
Esistono script che interrogano il database e restituiscono un esito
secco, ma vanno lanciati da noi dopo ogni modifica. Un test automatico
ci avvisa se la superficie cambia rispetto all'ultimo controllo — non
è la stessa cosa di un controllo continuo.
-
Un test verifica ciò che qualcuno ha pensato di verificare.
Sorveglia la promessa che aveva in mente chi l'ha scritto. Se sbagliamo a
formulare una promessa, il test la sorveglierà sbagliata insieme a noi.
-
Non sostituiscono un audit indipendente.
Sono la nostra dimostrazione, controllata da noi. È più di una
dichiarazione d'intenti e meno di una certificazione. Chiamarla in un
altro modo sarebbe già il primo strappo.
-
L'auto-osservazione autenticata vede soltanto ciò che
la pagina può vedere. Non legge
document.cookie
e nel rapporto registra soltanto il marker
not_read_by_design; non osserva cookie
HttpOnly, cache HTTP, BFCache, processo
Android, log o backup. Lo strumento in-app non legge né usa ADB;
nella run 1.10.41 un controllore ADB/CDP esterno ha però assistito
i gesti e il passaggio alla Home. Questo non amplia ciò che il
rapporto può vedere. Il suo hash rileva modifiche del file, ma non
è una firma e non rende indipendente un rapporto prodotto dalla
stessa app.
Vuoi controllare tu?
Le condizioni della suite applicativa sono riportate qui in forma leggibile,
ma i 64 file interni sotto site/tests/ non
vengono distribuiti nella webroot: contengono dettagli di implementazione
e non sono una verifica indipendente. Dichiarare pubblici file che il
pacchetto Aruba non espone sarebbe inesatto.
Nella privacy policy trovi la provenienza, l'hash
e i limiti accertati del report e dello script Python usati per il test
osservazionale di GoodScroll 1.0.7 nell'agosto 2025. Sono conservati
nell'archivio storico privato, non sono più offerti come download e non
vengono presentati come prova della versione attuale.
Lo strumento e il metodo correnti che sostituiscono il vecchio
script sono invece pubblici:
GoodScroll
Privacy Browser Observer 4.0.1. È fail-closed, non assegna punteggi
di conformità e, se una fase obbligatoria è incompleta, conserva soltanto
una diagnostica inconclusiva. Il suo archivio contiene una diversa cartella
tests/: sono i 33 test offline dello strumento,
non la suite applicativa interna. Rendere pubblico lo strumento consente
di esaminarlo e ripetere il metodo; non trasforma da solo tutte le
promesse di GoodScroll in fatti osservati.
È disponibile anche il
rapporto tecnico PDF della
preview locale. È un esempio reale del formato e documenta quella
singola esecuzione, senza grafici o giudizi legali. Non è una verifica
del dominio pubblico né dell'hosting di produzione. Sul sito pubblichiamo
questa copia autonoma del PDF, non gli altri output della run
(observation.json,
report.html e
manifest.json): non la presentiamo quindi come
un pacchetto probatorio completo.
Per il dominio pubblico è disponibile il
pacchetto completo della run di produzione 1.10.24.
L'esecuzione è iniziata il 29 luglio 2026 alle 21:19:52 UTC su
https://goodscroll.it/ e ha osservato il
redirect a https://www.goodscroll.it/.
L'archivio contiene, senza rinominarli,
observation.json,
report.html,
report.pdf e
manifest.json. SHA-256 dell'archivio:
b4b8d32583b49e779afc2587717d24e73a0bc5538eb7e8a213ae7710491ba438.
Per la lettura immediata è disponibile anche il
rapporto tecnico PDF della
run di produzione; SHA-256
134c796ccb62d89a0db3f921ed7b640a877797161f4ada4d12fbc5ce52798e51.
È una copia byte-identica del file report.pdf
incluso nell'archivio.
La run ha osservato la cache
goodscroll-1.10.24, ma il Privacy Observer
non confronta byte per byte gli asset online con il rilascio privato.
L'associazione alla 1.10.24 è il contesto dichiarato dell'esecuzione,
corroborato dal nome della cache, non un'attestazione crittografica
dell'intero deployment. Non verifica login, dati lato server, RLS,
cancellazione, export, log dei fornitori o conformità legale.
La verifica HTTP separata del 30 luglio 2026 è consultabile come
rapporto leggibile,
JSON strutturato,
baseline pubblica dei 35 asset e
SHA-256 degli artefatti.
version.json ha dichiarato 1.10.24 sia
all'inizio sia alla fine; 35/35 asset hanno coinciso, 15/15 percorsi
protetti hanno risposto 403/404 e i tre endpoint pubblici hanno
restituito gli stati attesi.
La classificazione è
supported_with_findings, non “sicuro”:
la 1.10.24 non inviava una protezione anti-clickjacking applicabile
né HSTS e dichiarava un canonical diverso dall'host finale.
La 1.10.25 introduce correzioni sorgente per questi finding; la loro
applicazione effettiva su Aruba dovrà essere verificata dopo il
caricamento. Il rapporto resta storico e non descrive automaticamente
lo stato presente o futuro del sito.
Il 2 agosto 2026 è stata completata sulla PWA di produzione 1.10.41
un'esecuzione assistita e supervisionata della prova
autenticata, dalle 17:02:59 alle 17:21:19 UTC. Il titolare ha usato il
proprio account di sviluppo; un controllore ADB/CDP privato ha inviato
un solo evento UI alla volta, mentre frase segreta, avvisi nativi e
riapertura della PWA sono rimasti sotto controllo umano. Il controllore
ha guidato i gesti: il rapporto è stato costruito dall'applicazione.
Non è una prova manuale non assistita, un audit indipendente o
un'osservazione completa del dispositivo.
Sono disponibili il
rapporto autenticato JSON, il
campione diagnostico Reazione e i
relativi SHA-256. Il primo file ha SHA-256
76525dbc4121854230c0ab7251510100e96ee5785b9e1ad4f0e203a92260fa08;
il secondo
350dceb326d5fead0e4057545a7a8ecaa67ba72a0923c737fca257ae7dfe01b3.
Il validatore versionato ha restituito
valid, supported
e accepted, senza errori. Tutte le nove
fasi sono complete, gli snapshot iniziale e finale coincidono e il
server ha confermato l'assenza di note, Eco o reazioni sintetiche residue.
La fase voce documenta un tentativo iniziato ma una riproduzione non
avviata: failure_classified è vero e
playback_started è falso. Non è stato eseguito
un secondo tentativo all'interno della run. Questo non dimostra né un
guasto permanente né che un retry avrebbe avuto successo.
Il campione prestazionale contiene una sola richiesta
content_reaction_save, conclusa con HTTP 200:
1.686,5 ms nel browser, 1.465,66 ms dichiarati dal backend e 220,84 ms
fuori dal server. Nella scomposizione applicativa 1.378,06 ms sono
attribuiti alla connessione TLS verso il target a monte. I 4.489,9 ms
dell'intero gesto includono anche la rilettura preventiva del target
pulito richiesta soltanto da questa prova. È un singolo campione, utile
a descrivere quella richiesta ma insufficiente per generalizzare le
prestazioni del servizio.
Limite di provenienza del controllore: durante la run il suo helper
locale è stato corretto per gestire il check-in giornaliero di Lumi
prima della stanza. Il rapporto non incorpora l'hash di quell'helper
e quindi non ne attesta i byte. La modifica non ha cambiato la build
1.10.41 né il produttore del rapporto, ma impedisce di presentare la
catena di esecuzione come crittograficamente chiusa.
"Una promessa che non può essere smentita
non è una promessa: è uno slogan."