Dove finiscono i dati dei suoi moduli online?

Una scuola guida di Bellinzona ha sul proprio sito un modulo di iscrizione: nome, indirizzo, data di nascita, numero di telefono, categoria e un campo per le osservazioni, in cui ogni tanto qualcuno scrive di portare gli occhiali. Il modulo funziona da anni. Un giorno una cliente telefona e chiede dove finiscano davvero quelle indicazioni.

La domanda è semplice da porre e sorprendentemente difficile da sciogliere, se in azienda nessuno ha mai controllato. Eppure una risposta esiste, e non richiede competenze tecniche particolari: si trova in una manciata di documenti che esistono già, e il percorso dei dati ha meno tappe di quanto si immagini.

La catena, tappa per tappa

Fra il clic su «invia» e il momento in cui qualcuno in azienda legge la risposta, le tappe sono quasi sempre le stesse.

Tappa	Che cosa succede
Browser	I dati inseriti vengono composti in una richiesta HTTP
Indirizzo di destinazione	La richiesta parte verso il server indicato nel modulo
Applicazione del fornitore	La risposta viene verificata, salvata, registrata nei log
Archivio e backup	Banca dati, deposito dei file caricati, copie di sicurezza
Notifica	Un’e-mail con il contenuto della risposta arriva in azienda
Collegamenti	Esportazione, tabella, contabilità, newsletter, webhook

Ognuna di queste tappe è un luogo, e un luogo si può nominare. Le quattro distinzioni che vi stanno dietro — luogo di conservazione, ordinamento giuridico, accesso e subfornitori — sono state separate in un articolo a sé; qui si segue il percorso concreto di una singola risposta.

Tappa 1: dove il modulo invia

Un modulo HTML ha un attributo chiamato action. È lui a stabilire dove vanno i dati. Le MDN Web Docs lo descrivono così: l’attributo action definisce dove i dati vengono inviati e il suo valore deve essere un URL valido, relativo o assoluto; se l’attributo manca, i dati vanno all’URL della pagina che contiene il modulo.

Questa sola riga decide più di tutto il resto della pagina. Se contiene un indirizzo del proprio dominio, la risposta resta dapprima presso il proprio hosting. Se contiene l’indirizzo di un servizio di moduli, la risposta lascia il sito nel momento stesso in cui qualcuno preme «invia», anche quando il modulo appare integrato nella pagina e chi lo compila non ha mai avuto l’impressione di uscire dal sito.

Se il trasferimento sia cifrato dipende dal protocollo di quell’indirizzo. Con un indirizzo HTTPS i dati vengono cifrati insieme al resto della richiesta; se il modulo si trova su una pagina sicura ma punta a un indirizzo HTTP non cifrato, secondo MDN tutti i browser mostrano un avviso di sicurezza al momento dell’invio.

Vale la pena distinguere che cosa fa e che cosa non fa la cifratura del trasporto: protegge il tragitto. Non dice nulla sul luogo in cui la risposta viene poi depositata, né su chi lì la possa leggere.

Tappa 2: che cosa dice la documentazione del fornitore

In fondo a quell’indirizzo c’è un servizio, e la maggior parte dei servizi documenta pubblicamente dove conserva i dati. Due esempi, entrambi tratti dalla documentazione dei fornitori stessi.

Microsoft Forms. Microsoft elenca Forms fra gli «Additional Microsoft 365 Services», quelli per cui, salvo diversa indicazione delle condizioni di prodotto, non sussistono impegni specifici di residenza dei dati. La tabella indica poi il luogo di conservazione previsto secondo la geografia predefinita del tenant: per i tenant in Paesi dell’UE o dell’AELS si tratta della «Macro Region Geography 4 — European Union/EFTA», per tutte le altre sedi degli Stati Uniti. La Svizzera è un Paese AELS. Accanto a ciò esiste l’offerta aggiuntiva Advanced Data Residency, che assume impegni per singole regioni nazionali; Microsoft vi elenca la Svizzera fra le regioni locali possibili e indica uno per uno i servizi inclusi — Exchange Online ne fa parte, Forms no.

Google Forms. Per Google Workspace, Google offre le cosiddette regioni di dati: i dati coperti possono essere conservati in un luogo geografico scelto, ossia negli Stati Uniti oppure in Europa. Per Forms, Google indica come dati coperti «Text, embedded images, responses, and draft responses». Sulla stessa pagina compaiono due limiti: a seconda dell’abbonamento la copertura riguarda i dati inattivi e non necessariamente il trattamento, e le regioni di dati non si applicano ai tipi di dati che non vi sono espressamente menzionati, per esempio i log e i contenuti nella cache.

I due esempi mostrano lo stesso schema, ed è uno schema utile: un’indicazione sul luogo di conservazione vale per certi dati, in una certa versione del prodotto, in una certa regione. «Dove sono i dati» ha quindi di rado una risposta di una sola parola, ma quasi sempre una risposta consultabile.

Tappa 3: chi altro collabora

Quasi nessun fornitore gestisce tutto da sé. Dietro un servizio di moduli ci sono di norma un centro di calcolo, un servizio di spedizione per le notifiche, un registro degli errori, uno strumento di supporto. Questi prestatori sono subfornitori, e molti fornitori li pubblicano in un elenco.

Quanto può contenere un elenco simile lo mostra Google Workspace. Per ogni voce Google indica la società, i servizi interessati, l’attività — per esempio «Technical Support» o «Security Risk Detection» —, i Paesi in cui avviene il trattamento, l’indirizzo registrato, il Paese di registrazione e la società madre ultima. Le versioni precedenti dell’elenco restano accessibili sulla stessa pagina, così i cambiamenti sono ricostruibili.

Sul piano giuridico questa catena non è un dettaglio: il responsabile del trattamento può affidare il trattamento a un terzo soltanto previa autorizzazione del titolare (art. 9 cpv. 3 LPD). Se un elenco pubblico manca, anche questa è un’informazione, e si può chiedere per e-mail.

Tappa 4: la seconda copia che nessuno conta

La maggior parte dei servizi di moduli invia un’e-mail di notifica a ogni nuova risposta, e in molte configurazioni quell’e-mail contiene il contenuto completo della risposta. Da quel momento la risposta esiste in almeno due luoghi: nell’archivio del servizio e nella casella di posta dell’azienda.

La casella di posta è una tappa a sé, con risposte proprie. Exchange Online, per esempio, rientra negli impegni dell’offerta Advanced Data Residency di Microsoft, che Forms non comprende: stesso gruppo, stesso accesso, due risposte diverse alla stessa domanda. Si aggiungono i collegamenti: l’esportazione in una tabella, il passaggio a uno strumento di contabilità o di newsletter, un webhook verso un sistema terzo. Ciascuno è una copia in più in un luogo in più, e ciascuno è visibile nelle impostazioni del modulo, perché qualcuno lo ha configurato lì una volta.

Per la scuola guida questo significa, molto concretamente: l’iscrizione di una cliente non sta «nel modulo». Sta nel servizio, nella casella di posta, nella tabella scaricata sul computer dell’ufficio e, se del caso, nell’agenda degli appuntamenti.

Che cosa aggiunge il contratto

Per l’azienda la catena tecnica è una metà, il contratto è l’altra. L’IFPDT enuncia il punto di partenza senza giri di parole: anche quando il trattamento di dati personali viene affidato a un responsabile, il committente resta responsabile della protezione dei dati ed è tenuto a sceglierlo con cura, a istruirlo in modo adeguato e a sorvegliarlo per quanto necessario. Fra i punti che l’IFPDT elenca figurano il trattamento soltanto secondo le istruzioni, misure adeguate di sicurezza dei dati e il consenso preventivo al coinvolgimento di ulteriori prestatori.

Presso molti fornitori questo contratto è disponibile come documento standard da scaricare, spesso sotto la voce «Data Processing Agreement» o contratto di trattamento. Risponde a ciò che la documentazione tecnica lascia aperto: quali istruzioni valgono, come vengono annunciati nuovi subfornitori, che cosa succede in caso di violazione della sicurezza e che fine fanno le risposte alla scadenza del contratto.

E dal punto di vista di chi ha compilato il modulo

Chi raccoglie dati personali informa in modo adeguato la persona interessata e le comunica almeno l’identità e i dati di contatto del titolare del trattamento, lo scopo del trattamento e, se del caso, i destinatari o le categorie di destinatari (art. 19 cpv. 1 e 2 LPD). Se i dati sono comunicati all’estero, l’informazione comprende anche lo Stato e, se del caso, le garanzie secondo l’art. 16 cpv. 2 LPD oppure l’eccezione secondo l’art. 17 LPD (art. 19 cpv. 4 LPD).

È questo il motivo per cui la catena interessa: ciò che alla fine compare in un’informativa sulla protezione dei dati è esattamente l’elenco delle tappe che qualcuno ha messo insieme una volta. Con quell’elenco, la domanda della cliente al telefono si risolve in una frase; senza, l’elenco si ricostruisce in un’ora o due: codice sorgente, documentazione del fornitore, elenco dei subfornitori, contratto, casella di posta, collegamenti.

L’app per moduli online che stiamo sviluppando prende la catena dall’altro capo: le risposte saranno cifrate già nel browser di chi le compila, e gestione e conservazione si troveranno in Svizzera. La catena non sparisce per questo: si accorcia, al punto da stare in una frase. Che poi è la misura più utile: non se una risposta alla domanda esista, ma se stia in una frase.