Vai al contenuto
MobilityOS
Inizia gratisInizia

Ciò che MobilityOS conserva, e ciò che non conserva

Riservatezza e non conservazione dei dati personali: come l'applicazione garantisce che le informazioni di un cliente non vengano salvate da nessuna parte.

Versione 2026 Autore Guilhem Normand Documento pubblico

Sintesi

Questa nota risponde a una domanda: «Come garantisce l'applicazione che i dati del cliente non vengano salvati da nessuna parte?»

La risposta è strutturale: l'applicazione agisce come uno specchio digitale. Ciò che il cliente inserisce si riflette in tempo reale sullo schermo dell'operatore. Non passa da alcun server né database. Solo l'etichetta mostrata in coda transita dal coordinatore, per la durata dell'attesa. Alla chiusura della sessione, i dati scompaiono.

Architettura dello specchio

La trasmissione passa per WebRTC (Web Real-Time Communication), una connessione diretta peer-to-peer standardizzata dal W3C.

Telefono del visitatore inserisce i propri dati Canale WebRTC, cifrato end-to-end DTLS · da browser a browser server mai sul percorso del modulo Schermo dell'operatore visualizza in tempo reale
Il coordinatore mette in contatto i due dispositivi e tiene la coda. Il modulo, invece, non passa mai da lui.

Nessun server intermedio tocca il contenuto del modulo. Il coordinatore dell'agenzia conosce solo la coda: ordine di arrivo, etichetta mostrata, postazione che prende in carico.

Cosa viene salvato, cosa non lo è mai

Il registro, riga per riga. Tutto ciò che un cliente inserisce sta a sinistra; tutto ciò che una licenza d'agenzia richiede sta a destra.

Mai salvato
  • Indirizzo, CAP, città del clientemai registrati da noi; il completamento automatico interroga Photon by Komoot dal telefono
  • Telefono ed e-mailda pari a pari; trasmessi al fornitore di invio se l'operatore avvia una verifica, mai registrati
  • Indirizzo temporaneo (hotel, Airbnb)stesso canale peer-to-peer
  • Numero di prenotazione del clientepeer-to-peer soltanto, in memoria del terminale, cancellato alla chiusura
Salvato
  • Nome dell'agenzia (licenza)in KV (non è un dato personale)
  • Data di scadenza della licenzain KV (non è un dato personale)
  • Data e versione di accettazione delle condizioniin KV, sull'account dell'azienda (registro legale)
  • Telemetria della console di accoglienzain KV, per sede: impronta del dispositivo, città e posizione arrotondata, 30 giorni; poi totali senza data

L'account di un'azienda registra le sue sedi, il suo personale, le sue misure d'uso e i suoi log. Il dettaglio e i tempi di conservazione sono nell'informativa sulla privacy.

Garanzie tecniche

4.1 Nessun database clienti

Nessuna funzione scrive ciò che un visitatore inserisce nel modulo di accoglienza. L'account di un'azienda registra le sue sedi, il personale di accoglienza e le misure d'uso. Questo contenuto è elencato, con i suoi tempi, nell'informativa sulla privacy.

4.2 Cifratura end-to-end

WebRTC cifra i dati con DTLS. Nessun nodo intermedio può leggerne il contenuto.

4.3 Effimero per progettazione

Ciò che un visitatore inserisce vive solo nella memoria della console e scompare alla chiusura della scheda. Nulla viene scritto sulla postazione. Sul suo telefono resta nella scheda solo la bozza di ciò che ha digitato, perché un aggiornamento non la cancelli. La coda è tenuta dal coordinatore della sede: ordine di arrivo ed etichetta mostrata, fino alla rimozione della riga.

4.4 Nessun registro del contenuto

Ciò che un visitatore inserisce non compare in alcun log: il modulo non attraversa i nostri server. Le intestazioni HTTP bloccano la memorizzazione nella cache delle pagine di accoglienza e della console (Cache-Control: no-store). Le misure d'uso conservate contano gesti, sotto un'impronta che cambia ogni giorno. Sono descritte nell'informativa sulla privacy.

4.5 Verifica e-mail / SMS (facoltativa)

Per verificare un contatto, l'applicazione può inviare al cliente un'e-mail di conferma o un SMS con un link. L'invio passa da un fornitore. L'indirizzo o il numero serve solo a questo invio: non viene mai scritto in un database. Un token temporaneo (30 minuti) collega il clic del cliente alla sessione, poi scade e scompare. Lato operatore, la cronologia delle verifiche resta in memoria e si cancella alla chiusura.

Ciclo di vita di un dato

Un indirizzo e-mail, dal primo tocco alla chiusura della scheda.

  1. Il cliente digita la sua e-mail.
  2. Lo script impacchetta i dati in memoria.
  3. L'oggetto parte tramite il canale WebRTC cifrato, direttamente all'operatore.
  4. L'operatore riceve e visualizza il dato.
  5. Il blocco del modulo non parte con alcuna richiesta HTTP: lascia il telefono solo attraverso il canale cifrato.
  6. Alla chiusura, lo schermo dell'operatore si svuota: non ne esiste alcuna copia. Sul telefono, la bozza sparisce con la scheda.

Conclusione

  • Rispetta il principio di minimizzazione del GDPR (art. 5.1.c).
  • Nessun database di clienti: il modulo non tocca alcun server.
  • Canale peer-to-peer, cifrato end-to-end.
  • Nulla di ciò che un visitatore inserisce viene scritto in un database. Ciò che vi registra l'account dell'azienda è elencato nell'informativa sulla privacy.

Riferimenti al codice

I file da leggere per verificare questa nota, e cosa fa ciascuno.

  • functions/api/check-license.jsVerifica della licenza e impostazioni del modulo. Non riceve né scrive ciò che un visitatore inserisce.
  • functions/api/admin-agencies.jsGestione delle licenze. Scrive solo metadati KV.
  • functions/api/billing/terms.jsRegistra la data e la versione di accettazione dei Termini
  • functions/api/turn-credentials.jsGenera credenziali TURN effimere
  • src/retailer/Console dell'operatore. Nota legale mostrata.

Guilhem Normand · 2026 · Documento pubblico

Torna alla home