Privacy Policy

Documentazione legale scaricabile

Tutto quello di cui abbiamo parlato fin qui è nero su bianco in documenti che puoi scaricare, leggere e far verificare dal tuo avvocato. Noi non abbiamo nulla da nascondere.

Cookie e tecnologie simili

La versione breve: nell'uso ordinario GoodScroll non imposta cookie. Non usa cookie pubblicitari, analitici, di profilazione o marketing. L'unica eccezione applicativa è il cookie tecnico temporaneo descritto sotto, creato soltanto quando un account di sviluppo autorizzato avvia volontariamente la diagnostica.

Cookie tecnico della diagnostica di sviluppo: soltanto quando dall'interfaccia viene richiesto l'avvio e il preflight server riconosce un account approvato e abilitato allo sviluppo, il backend imposta un cookie first-party firmato, sicuro, HttpOnly e SameSite=Strict, limitato al proxy API. Non contiene email, UUID o token in chiaro e il JavaScript non può leggerlo. È vincolato crittograficamente alla sessione corrente e scade dopo dodici minuti, due minuti oltre la durata massima del campione per consentire un singolo riavvio. Le normali richieste dell'app non lo emettono e non ne fanno scorrere la scadenza; una capacità ancora valida non viene riemessa a ogni richiesta. Viene cancellato quando una verifica restituisce un account non abilitato. Al logout l'app avvia la richiesta di cancellazione prima di lasciare la pagina e la consegna in modalità keepalive, ma la rete o la chiusura del processo possono impedirne il completamento. Un'eventuale copia residua resta inutilizzabile senza la sessione cui è vincolata e scade comunque entro dodici minuti. Senza una nuova interrogazione al database per ogni richiesta, una revoca amministrativa può quindi impiegare al massimo quei dodici minuti a invalidare una capacità già emessa; il cambio o rinnovo del token la rende comunque inutilizzabile perché cambia la sessione a cui è legata.

localStorage (Web Storage): utilizziamo questo archivio del browser, che non è un cookie, per mantenere la sessione e alcune informazioni funzionali:

• access token, refresh token e scadenza della sessione; del record account restituito da Supabase conserviamo soltanto UUID, email, date di creazione e aggiornamento, conferma email e ultimo accesso, perché sono i campi usati dall'app. Gli altri metadati Auth vengono scartati e GoodScroll non aggiunge alla sessione reazioni, note o Eco;
• versione dell'app e avviso di aggiornamento già mostrato;
• soltanto l'identificativo della storia rinviata o iniziata da riprendere, non il testo, e la data locale dell'ultima storia completata;
• presa visione dell'avviso privacy e chiusura delle istruzioni PWA;
• per Lumi, soltanto il giorno in cui la domanda è stata proposta e il giorno in cui il pensiero della stanza è stato ricevuto.

Gli archivi web sono separati per origine e profilo browser, non automaticamente per account GoodScroll. Al logout o al cambio d'identità il codice rimuove la sessione, la chiave del vault e gli stati locali legati all'account: riferimento alla storia da riprendere, data dell'ultima storia, date funzionali di Lumi, diagnostica di avvio e un eventuale verificatore PKCE residuo. Restano gli asset e gli indicatori generici dell'app, come versione, presa visione privacy e chiusura delle istruzioni PWA.

Altri archivi lato browser: GoodScroll usa Cache Storage per gli asset statici della PWA e, soltanto durante lo scenario diagnostico “Avvio”, sessionStorage per lo stato temporaneo del campione. Il codice corrente non usa IndexedDB. La chiave attiva del vault, la frase durante la derivazione e le note aperte restano in memoria volatile; in JavaScript la rimozione elimina i riferimenti, ma non permette di garantire l'azzeramento fisico immediato della memoria gestita dal browser.

Cache Storage della PWA: il service worker conserva una copia dell'app shell e degli asset statici necessari al funzionamento offline. Non inserisce in questa cache richieste API, risposte Supabase, sintesi vocale, Magic Link, il ponte statico auth-handler.html verso il callback protetto auth-handler.php o il controllo periodico version.json, né documenti PDF. Le chiavi sono canoniche, quindi parametri casuali non producono una cronologia crescente. Quando si attiva una nuova release, le cache GoodScroll delle release precedenti vengono eliminate; il browser può inoltre rimuoverle secondo le proprie politiche o quando cancelli i dati del sito.

Il percorso e la pausa di 30 minuti non sono conservati nello storage locale: l'autorità è una sola riga sul server, condivisa tra i dispositivi. Il browser riceve l'ora del server e la scadenza e mantiene soltanto in memoria lo stato necessario ad aggiornare la pagina finale, che mostra l'orario statico della soglia. Alla scadenza non parte nulla automaticamente: un nuovo percorso viene richiesto soltanto con un gesto esplicito. Cambiare l'orologio, cancellare i dati del sito o ricaricare la pagina non assegna nuovi contenuti.

Diagnostica locale della reattività: il metodo e il suo limite sono visibili nel menu a tutti gli account; la normale interfaccia consente l'esecuzione soltanto agli account di sviluppo abilitati amministrativamente. Il flag non è leggibile né modificabile dalle normali API del profilo. Prima di creare il campione l'app ripete una verifica sul server: questa richiesta non entra nella misura. Se autorizzata, il backend rinnova la capacità temporanea HttpOnly descritta sopra. Per un massimo di dieci minuti il browser misura durata ed esito di richieste tecniche. Quando è attiva, l'app aggiunge soltanto alle richieste API ammesse dalla lista chiusa un'intestazione tecnica dal valore fisso. L'intestazione da sola non abilita nulla: il backend restituisce le durate soltanto se verifica anche la capacità firmata e il suo legame con la sessione corrente. Non riceve lo scenario scelto, i campioni o il rapporto. In risposta restituisce soltanto durate aggregate delle fasi Aruba e Supabase. Alla voce non viene aggiunta l'intestazione e il backend non restituisce tempi interni: il campione HTTP misura il tempo dalla partenza della richiesta audio già autorizzata fino alla ricezione dell'ultimo byte; l'esito del gesto viene dichiarato riuscito soltanto dopo che il browser ha accettato l'avvio della riproduzione. Non viene misurata la durata di ascolto. Un eventuale rinnovo della sessione può contribuire alla durata complessiva percepita del gesto, ma nello scenario Voce non viene attribuito né campionato separatamente come richiesta di autenticazione. Come ogni dato già misurabile dal browser, le durate client possono essere osservate o strumentate manualmente da chi controlla il proprio dispositivo; la garanzia server riguarda le durate interne aggiuntive, che restano inaccessibili senza la capacità firmata.

Gli scenari non sono semplici etichette applicate a una registrazione continua. Avvio termina quando la prima superficie primaria corrente — contenuti, Bath o messaggio di confine — è stata realmente inserita nell'interfaccia; non attende il silenzio della rete e non usa il solo evento di caricamento della pagina. Reazione, Raccolta e Voce restano armati fino al primo gesto corrispondente e accettano soltanto le richieste a cui il codice passa lo stesso token causale creato da quel gesto. Le richieste contemporanee del menu, di Lumi, del vault o di altri aggiornamenti non correlati restano escluse. Dopo il completamento, annullamento o errore del gesto il rapporto viene congelato: richieste, risorse ed eventi successivi non possono modificarlo. Uso generale è l'unico scenario a finestra libera e termina con il comando manuale. Il rapporto indica scenario scelto, versione dell'app, uso da browser o PWA e, in gruppi aggregati, etichetta tecnica dell'operazione, metodo, esito client, codice HTTP, conteggi delle richieste e statistiche dei tempi. Soltanto per l'avvio include anche il tipo di navigazione e, per una lista chiusa di risorse statiche dell'app, durate e byte aggregati. Anche le operazioni API misurabili appartengono a una lista chiusa: cancellazione dell'account, reset di attività o vault e salvataggio di note o Eco ne sono esclusi. Non include URL o query, contenuti, identificativi, account, token, indirizzo IP, user agent, timestamp assoluti o request ID. I campioni restano in memoria; soltanto Avvio scrive in sessionStorage lo scenario e la scadenza, necessari per misurare il singolo riavvio. Nei gesti che aprono un dialogo nativo il rapporto sottrae dalla durata dell'azione il tempo trascorso in attesa della risposta umana e dichiara separatamente la durata esclusa. Il rapporto nasce sul dispositivo e viene copiato o scaricato soltanto con un tuo gesto: non esiste un endpoint di upload, un beacon o un servizio analytics che lo riceva. Puoi annullare in ogni momento; copia, esportazione, annullamento e scadenza cancellano il campione dalla memoria dell'app. La copia negli appunti o il file che hai scelto di creare restano sotto il tuo controllo sul dispositivo.

Prova autenticata locale: è uno strumento distinto dalla diagnostica di reattività, dal Privacy Browser Observer e dal GoodScroll Authenticated Android Storage Observer 1.3.1. Lo strumento in-app non usa ADB e non controlla il sistema operativo. Il metodo è visibile nel menu, ma l'avvio richiede un account di sviluppo controllato, approvato e abilitato dal server; le operazioni previste usano input sintetici. L'avvio è bloccato durante il Philosophical Bath e parte soltanto se lo stato server lascia più di trentuno minuti prima della transizione successiva. Il ciclo reversibile riguarda un contenuto che il server conferma privo anche di una riga attività preesistente. Le mutazioni sulle storie restano bloccate durante l'intera prova, per non cancellarne accidentalmente lo stato di lettura. L'avvio ripete una verifica sul server. Questa verifica non emette da sola il cookie tecnico della diagnostica; quel cookie viene usato soltanto se, nella relativa fase, avvii davvero un campione prestazionale. Per un massimo di trenta minuti la prova guida una fase alla volta e conserva il proprio stato soltanto nella memoria della pagina: una ricarica o chiusura lo perde. Non usa un nuovo localStorage, sessionStorage o IndexedDB e non dispone di endpoint di upload.

Gli snapshot registrano soltanto supporto, conteggi e presenza per categorie chiuse di Web Storage, IndexedDB, Cache Storage e Service Worker. La prova non legge document.cookie: nel rapporto compare soltanto il marker not_read_by_design, senza nomi, valori o conteggi di cookie. Non serializza valori dello storage, email, UUID, token, URL, richieste, testi di note o Eco, risposte a Lumi, frase segreta, chiave, testo cifrato o IV. Gli identificativi necessari a correlare salvataggio e rimozione dello stesso elemento restano transitoriamente in memoria e non entrano nel rapporto. Il JSON viene creato e scaricato soltanto sul dispositivo con un gesto esplicito e include un SHA-256 canonico, utile a rilevare modifiche del file ma non a rendere indipendente l'auto-osservazione. Una fase mancante, una scadenza, un'autorizzazione persa o uno stato sintetico non ripulito producono un esito inconcludente. La prova va eseguita senza un'altra sessione attiva dello stesso account, perché letture di controllo e scritture non formano una singola transazione atomica. Se la pagina viene chiusa forzatamente durante una scrittura, non viene prodotto alcun rapporto e gli input sintetici eventualmente rimasti vanno rimossi manualmente. Cookie HttpOnly, cache HTTP, BFCache, server, RLS, ACL, stato interno di Android, log, backup e fornitori restano fuori dal suo campo di osservazione. È un'auto-osservazione prodotta dalla stessa app, non un audit GDPR, una certificazione o un parere legale.

Non salviamo localmente la risposta data a Lumi. Il frontend non carica librerie da jsDelivr o da altri CDN di terze parti. Il provider di hosting e Supabase possono comunque produrre log tecnici di sicurezza e funzionamento, come descritto nelle sezioni sui responsabili del trattamento.

Il giorno settimanale del Philosophical Bath non è più una preferenza locale: è assegnato casualmente dal server, resta stabile tra dispositivi e non è esposto ad alcuna funzione di modifica dell'utente. Il controllo usa il fuso Europe/Rome ed è applicato anche dal database e dalla sintesi vocale, non soltanto dalla schermata dell'app. Durante la pausa non vengono assegnati un nuovo feed o una Storia del Giorno non già salvata; community e Lumi sono sospesi. La voce accetta soltanto una richiesta esplicita relativa a un contenuto o a una storia che abbia ancora una tua reazione attiva nella Raccolta.

La Raccolta dell'interfaccia resta consultabile nelle sue tre librerie per reazione, limitatamente ai contenuti e alle storie che vi erano già presenti. Rileggere una storia salvata durante il Bath non registra un nuovo completamento. È una modalità di consultazione, non di nuova scrittura: non puoi aggiungere o cambiare reazioni, creare o modificare note, pubblicare o modificare Eco. Se una nota cifrata esiste già, puoi leggerla dopo avere sbloccato il Vault, ma non modificarla. Puoi soltanto ritirare la reazione già attiva; dopo conferma questa cancellazione rimuove anche l'eventuale nota ed Eco associati. La sintesi vocale non si avvia automaticamente e viene autorizzata sul server prima di leggere la cache privata o contattare ElevenLabs; dopo il ritiro della reazione non può più recuperare l'audio. Semina resta disponibile perché consegna il contenuto all'app esterna scelta da te e non scrive un nuovo dato nel database GoodScroll. Restano disponibili anche i controlli di account e privacy, compresi export e cancellazione dei dati.

Modifiche a questa policy:

Questa policy cambia quando cambia il software. Se introducessimo nuovi dati, finalità o fornitori, li descriveremmo prima di considerarli parte ordinaria del servizio. Le versioni precedenti non sono una promessa che il progetto resterà tecnicamente immobile.

Le modifiche materiali saranno comunicate con un avviso nell'app e, quando incidono significativamente sul trattamento, anche tramite email.

Testiamo quello che diciamo

La pagina Metodo pubblico e stato delle prove distingue controlli applicativi interni, test pubblici dello strumento, esecuzioni osservazionali e verifiche manuali del backend. Non hanno la stessa forza e non vengono presentati come equivalenti.

Nell'agosto 2025 GoodScroll 1.0.7 è stato sottoposto a un test osservazionale con la versione 3.0 di uno script scritto in Python, progettato per rilevare cookie, alcune chiavi dello storage del browser, richieste di rete e corrispondenze con una lista di tracker noti.

Il report storico dichiarava di non aver osservato cookie di tracking o servizi analytics durante quel percorso. Una revisione del 27 luglio 2026 ha però accertato che lo strumento poteva produrre un punteggio positivo anche con fasi non completate o raccolta di evidenze insufficiente. Quel risultato non dimostra quindi la conformità GDPR e non costituisce prova della versione attuale. Non è un audit GDPR completo.

In particolare, il test storico non verificava policy RLS e autorizzazioni del database, cancellazione ed export completi, gestione delle chiavi, tempi di conservazione, log dei fornitori o tutti gli storage del browser. Il report conteneva inoltre un'anteprima tecnica della sessione che non è opportuno distribuire. Report, script, database di rilevazione e archivio originale sono conservati byte per byte in un archivio storico privato, fuori dal sito, e non vengono più presentati come strumento corrente.

Provenienza del reperto storico: test del 1° agosto 2025, GoodScroll 1.0.7, report PDF di 10 pagine; SHA-256 279f3a2a3ae6ad84917c2c14abc4205135eb03282b78f2f41c6f94f565d41e2e. L'originale è stato ritirato dalla pubblicazione e archiviato senza modificarlo il 27 luglio 2026. Il ritiro non può cancellare eventuali copie già scaricate da terzi; l'hash permette di riconoscere il file storico senza ripubblicarlo. Stiamo sostituendo quel metodo con una verifica riproducibile che distingue “osservato”, “non osservato”, “non verificato” e “inconcludente”, senza punteggi di conformità.

Metodo corrente: il GoodScroll Privacy Browser Observer 4.0.1 usa un profilo browser nuovo e osserva esclusivamente la pagina pubblica senza login o interazioni. Registra evidenze redatte su rete, cookie, Web Storage, IndexedDB, Cache Storage, Service Worker e versioni dell'ambiente. I file di evidenza non serializzano, conservano o pubblicano valori di cookie o Web Storage, token, email, UUID, header o body. Le API di automazione possono rendere alcuni di questi dati transitoriamente disponibili nella memoria del processo: il collector ne estrae soltanto i metadati dichiarati e scarta il resto prima di creare qualsiasi output. Se una delle nove fasi obbligatorie manca, non è disponibile o fallisce, termina con errore e crea soltanto una diagnostica inconcludente: non lascia né il rapporto HTML né quello PDF.

Le osservazioni pubbliche prodotte con la versione 4.0.1 non osservano l'app dopo l'accesso e non vengono usate per provare sessione autenticata, vault, reazioni, Echi, Lumi, diagnostica di sviluppo o dati lato server. Queste parti richiedono verifiche distinte di codice, test applicativi e backend. Il 2 agosto 2026 la prova autenticata locale ha completato 9/9 fasi sulla PWA di produzione 1.10.41, con pulizia riletta dal server e stato finale supported. È stata un'esecuzione assistita e supervisionata: un controllore ADB/CDP esterno ha inviato un solo evento UI alla volta e il titolare ha mantenuto il controllo della frase segreta e della riapertura della PWA. Lo strumento in-app non ha ricevuto dati da ADB; ha prodotto il proprio rapporto limitato a ciò che la pagina poteva osservare. Il primo tentativo TTS è terminato come fallimento classificato e non è stato ripetuto nella run. Rapporto, campione prestazionale e SHA-256 sono pubblicati nella pagina Metodo e prove. L'helper esterno è stato corretto durante l'esecuzione per gestire il check-in giornaliero di Lumi e il rapporto non ne incorpora l'hash: la catena del controllore non è quindi un'attestazione crittografica. Questa auto-osservazione non trasforma le precedenti run senza login né prova server, RLS, ACL, log, backup o conformità legale.

Il codice e il metodo sono scaricabili in un archivio pubblico; SHA-256 c7a91a1556efdd3fc61e253e2e467492589810f781e6fe6095628bce77116d08. L'hash deterministico del codice eseguito e delle risorse metodologiche è 6d38276a627b0cd2c01433ae0593ff019f2bc8982d994cc7e75483f7c7f121fd. L'archivio contiene una propria cartella tests/: i suoi 33 test unitari offline verificano esclusivamente il funzionamento del Privacy Observer con componenti fittizi, senza browser o rete. Non coincidono con i 64 file presenti nell'inventario applicativo interno di GoodScroll (47 nella linea di base 1.10.31 e 17 test-obiettivo successivi) e non verificano app, backend, Supabase o RLS. Il conteggio dei file interni non equivale al loro esito. I 33 test dello strumento risultano superati il 27 luglio 2026.

Pubblichiamo anche il rapporto tecnico di pre-rilascio in PDF, generato dallo stesso test a partire dalla medesima osservazione strutturata usata per JSON e HTML; SHA-256 c6b473380c21a7d07c88696bba8ab99221575e67714a59bb76710c324ee71c4c. La run del 27 luglio 2026 ha completato tutte le nove fasi sulla preview locale 127.0.0.1:4188, senza login né interazioni, ed è stata poi controllata visivamente. Il documento dichiara in prima pagina che è una preview locale: non verifica il dominio pubblico o l'hosting Aruba. Non contiene grafici, punteggi o giudizi di conformità. È un'osservazione tecnica limitata, non un audit GDPR, una certificazione o un parere legale. Nella webroot pubblichiamo una copia autonoma del PDF, non observation.json, report.html o il manifest.json della run: il PDF non viene presentato come pacchetto probatorio completo.

Osservazione del dominio di produzione: il 29 luglio 2026 alle 21:19:52 UTC il Privacy Browser Observer 4.0.1 ha aperto https://goodscroll.it/, che ha reindirizzato a https://www.goodscroll.it/, in un profilo browser nuovo, senza login o interazioni. Tutte le nove fasi obbligatorie sono state registrate. In quella singola esecuzione sono state osservate dieci richieste entro il confine del dominio, la chiave goodscroll_current_version senza il relativo valore, la cache goodscroll-1.10.24 e il Service Worker /sw.js. Cookie, Session Storage e IndexedDB non sono stati osservati. “Non osservato” non significa assente in altri momenti, stati, account, browser o dispositivi.

Il pacchetto completo della run di produzione contiene observation.json, report.html, report.pdf e manifest.json; SHA-256 b4b8d32583b49e779afc2587717d24e73a0bc5538eb7e8a213ae7710491ba438. Il PDF consultabile separatamente è byte-identico alla copia nell'archivio; SHA-256 134c796ccb62d89a0db3f921ed7b640a877797161f4ada4d12fbc5ce52798e51. È un'osservazione tecnica non autenticata, non un audit GDPR, una certificazione o un parere legale.

L'osservatore ha registrato il nome della cache 1.10.24, ma non ricalcola gli hash degli asset applicativi pubblicati. Il campo config_sha256 presente nei suoi output identifica la configurazione metodologica del Privacy Observer, non il file backend api/config.php. Quest'ultimo, lo ZIP Aruba, token, credenziali, log grezzi e dati personali non fanno parte del pacchetto pubblico.

Verifica HTTP distinta: il 30 luglio 2026 un secondo strumento ha letto version.json all'inizio e alla fine, confrontato 35 asset statici pubblici con una baseline prodotta dall'operatore e controllato, senza conservarne il corpo, 15 percorsi protetti e tre endpoint pubblici. I risultati macchina, la baseline e i relativi SHA-256 sono descritti e collegati nella pagina del metodo. Il rapporto conserva soltanto una allowlist di header di sicurezza; non conserva cookie, Set-Cookie, body API, token, query o IP.

L'esito supported_with_findings significa che i 35/35 asset osservati coincidevano e la versione è rimasta 1.10.24 durante il run, ma sono emerse anche mancanze reali: anti-clickjacking HTTP e HSTS assenti, canonical non allineato all'host finale e hardening secondario incompleto. Non significa “deployment sicuro”, “intero server verificato” o “conforme GDPR”. La release successiva introduce correzioni sorgente, che richiedono una nuova verifica dopo il caricamento.