Rosie — architettura, sicurezza, esercizio

Rosie è un’ app web progressiva in JavaScript puro. L’applicazione gira come processo Node su un’istanza Debian presso Infomaniak, in Svizzera, preceduta da Caddy come proxy inverso con gestione automatica dei certificati. La persistenza avviene tramite libSQL/SQLite sulla stessa istanza (modalità WAL), lo storage a oggetti tramite lo storage a oggetti compatibile S3 di Infomaniak. Il service worker lavora con un CACHE_PREFIX per ogni versione. Davanti al sito pubblico è posto un servizio di protezione — non conserva dati; l’interfaccia si rivolge direttamente all’istanza svizzera.

• Dominio principale: rosie-app.ch (incl. www).
• Alias / mirror: rosie-planer.com — come reindirizzamento 301. Va considerata una finestra di cache di circa due minuti, che si risolve da sé. Verifica immediata dell’origine tramite ?cb=<random>.
• Sottodominio dell’app: l’applicazione gira sotto un nome proprio che punta direttamente all’istanza svizzera («solo DNS», senza servizio intermedio).
• Nessuna voce jolly. *.rosie-app.ch non esiste — un nome inventato non si risolve. È voluto ed esclude l’appropriazione di un sottodominio.
• Servizio di protezione a monte solo per il sito pubblico; non conserva dati dei clienti.

• sw.js con CACHE_PREFIX, marcato da shared/version.mjs (scripts/sync-version.mjs).
• Cache a monte: circa due minuti di ritardo dopo la messa in produzione, che si risolve da sé.
• immutableheader di cache per le risorse con versione.
• Librerie caricate su richiesta tramite _loadVendor — XLSX, html2canvas.
• Schermata di avvio iOS obbligatoriamente in PNG — WebP abbandonato dalla versione r168.
• Nessuna sincronizzazione in background — di proposito: una riesecuzione senza scheda aperta non avrebbe un token valido e rischierebbe doppie registrazioni in mancanza di chiavi di idempotenza. La coda della chat si svuota solo con l’app aperta (v. docs/OFFLINE.md).
• Notifiche web su iOS solo nell’app installata — imporre l’aggiunta alla schermata Home.

• Chiavi VAPID (pubblica e privata) conservate come segreti sull’istanza, sotto /etc/rosie/env.
• subscribeToPushNotifications è un UPSERT idempotente.
• Le ore di silenzio sono rispettate.
• Attivazione per categoria di allarme: bounty · planPublished · adminAlert · messages · absenceResult.

• Solo HTTPS in uscita sulla porta 443.
• Abilitazione per rosie-app.ch e il sottodominio dell’app. Non servono altre destinazioni — l’app non richiama da sé alcun servizio presso il cliente.
• Nessuna porta in entrata.
• WebSocket non necessario — l’app interroga il server ogni 60 secondi.

Invio tramite SMTP verso una casella svizzera presso Hostpoint. Il mittente di tutte le e-mail di sistema è support@rosie-app.ch — un indirizzo a cui si può rispondere, non un vicolo cieco. SPF, DKIM e DMARC sono impostati; consigliamo di provare una volta la consegna contro il filtro antispam del cliente dopo la prima configurazione.

• iOS 14.5+, Android 8.0+.
• App web — nessun pacchetto da store.
• Il MDM può configurare il browser preferito, i collegamenti sulla schermata Home e i siti attendibili .
• Da notare: Notifiche web su iOS richiede l’app installata; schermata di avvio iOS in PNG (non WebP).

Le migrazioni si trovano sotto database/migrations/ , numerate progressivamente, e vengono applicate solo in avanti. Lo stato attuale è nella cartella stessa — questa pagina non indica di proposito alcun numero, che sarebbe sbagliato già alla versione successiva. Dopo ogni esecuzione segue una verifica dello schema. Le migrazioni sono costruite in modo da poter ricostruire per intero una banca dati vuota.

• Backup automatici della banca dati, cifrati e depositati fuori sede.
• Finestra di ripristino di 30 giorni con punti di ripristino ogni ora (perdita massima di dati: un’ora).
• Storage a oggetti viene sottoposto a backup separato.
• Esportazione completa dei dati per mandante, in qualsiasi momento dall’interfaccia di amministrazione.
• Nessuna ridondanza geografica. Si gestisce di proposito una sola istanza di produzione: un riavvio o un aggiornamento comporta una breve interruzione. È un compromesso noto e accettato, recuperabile senza cambiare l’architettura.

A ogni versione corrisponde un’etichetta checkpoint-rNNN-deployed nel sistema di gestione del codice sorgente. Si può così dimostrare in ogni momento quale versione era in produzione e quando.

• Filtro dei mandanti lato server — tenant_id in ogni interrogazione.
• Le variabili globali del mandante in memoria vengono svuotate al logout tramite _resetTenantCalendarData() (sei variabili del calendario).
• I test sulle fughe fra mandanti sono fissati da casi di regressione.
• Attivazione del salvataggio tramite marcatore del mandante companySettingsDirty.

• X-Worker-Version (r166 A10), X-Request-Id in ogni risposta.
• Web Vitals → /api/analytics, invio in keepalive, segnale «Do Not Track» rispettato.
• Filtro dei dati personali prima di ogni analisi.
• k-anonimato ≥ 4 per i grafici aggregati.
• Registri si trovano sull’istanza (systemd/journald) e vengono analizzati dal fornitore; un monitoraggio esterno controlla la raggiungibilità e allerta.

• Obiettivi LCP / CLS / INP come budget di prestazione.
• Correzione dello spostamento visivo: width / height sui tag <img>.
• Librerie caricate su richiesta tramite _loadVendor — XLSX / html2canvas.
• Risparmio batteria: l’interrogazione si sospende quando document.hidden (pausa alla perdita di visibilità).

• Fornitore di IA: attivabile per mandante; un servizio fisso per ogni scopo, senza servizio di riserva automatico. Quale fornitore venga impiegato è indicato nell’elenco dei subincaricati del contratto di trattamento — non qui, perché questa pagina non diventi falsa in caso di cambiamento.
• Limite di frequenza: 30 richieste all’ora per utente.
• Il filtro dei dati personali rimuove indirizzo e-mail, numero AVS, IBAN, telefono e data prima di ogni chiamata al servizio di IA.
• Attività pianificate dell’IA 0 2 / 0 4 per l’apprendimento dei modelli dei compiti — richieste senza staff.id.
• Riconoscimento vocale: gestito dal browser (Web Speech API); a seconda del browser o del sistema operativo, la registrazione viene inviata al suo servizio di riconoscimento vocale — ROSIE non riceve né conserva alcuna registrazione audio. Per il riconoscimento del comando, solo il testo riconosciuto va al servizio di IA, con consenso (art. 6 cpv. 6 nLPD).

Moduli opzionali: Gestione della qualità (QMS), Voice-to-Schedule, Preparazione salari & finanze, Smart Matchmaker, Radar di carico, Rete regionale. Attivazione per mandante tramite Amministrazione → Strumenti.

• Tasto Esc globale e trappola del focus .
• Barra di avanzamento ARIA .
• Quattro lingue dell’interfaccia: DE / FR / IT / EN.
• 14 lingue nella chat per la comunicazione interna — la traduzione avviene sul dispositivo.

• I segreti si trovano in /etc/rosie/env sull’istanza, leggibili solo dall’utente di servizio: chiave di firma delle sessioni, coppia di chiavi VAPID, credenziali per lo storage a oggetti, l’SMTP e il servizio di IA.
• Rinnovare ogni anno la chiave di firma.
• La rotazione delle chiavi VAPID invalida le sottoscrizioni alle notifiche (limite noto).
• Hashing delle password: PBKDF2-SHA-256 con sale, in quattro passaggi concatenati da 100 000 iterazioni ciascuno (400 000 in totale).

La creazione di un mandante avviene presso il fornitore, sull’istanza svizzera. Presso il cliente non serve alcuna installazione — nessun server, nessun agente, nessuna porta in entrata. Quel che segue è l’elenco dei punti che spettano davvero al cliente.

Esistono procedure per: errori di accesso · errori della banca dati · errori di messa in produzione · consegna delle e-mail · guasto dell’IA · consegna delle notifiche · errori di migrazione.

• TLS 1.3.
• AES-256 a riposo. I campi di testo libero particolarmente degni di protezione sono inoltre cifrati singolarmente.
• Conservazione dei dati in Svizzera (Infomaniak): potenza di calcolo, banca dati, storage a oggetti e backup. Il servizio di protezione posto davanti al sito pubblico e il fornitore dei pagamenti sono nominati nell’elenco dei subincaricati del contratto di trattamento.
• Contratto di trattamento disponibile.
• Nessun cookie, nessun tracciamento — il segnale «Do Not Track» è rispettato.
• Distruzione delle chiavi come revoca operativa; cancellazione entro 30 giorni dalla fine del contratto, con attestato scritto.
• L’SSO (SAML/OIDC) è non disponibile ed è in valutazione; non esiste una data vincolante. Accesso con e-mail e password, con TOTP opzionale.