Nel precedente articolo ho esposto le mie difficoltà nell’utilizzare alcune tecnologie “cloud”, dovute a una non perfetta integrazione con l’ecosistema in cui sono normalmente immerso, oppure a un nuovo ambiente di lavoro, o ancora a intrinseche limitazioni degli strumenti a disposizione.
Non tutte le problematiche possono essere risolte, ma a mio avviso è possibile porre le basi per migliorare l’esperienza degli utenti traendo vantaggio da queste innovazioni, e riuscendo al contempo ad accontentarne anche una parte che non le vede di buon occhio a causa di motivazioni varie (fondamentalmente privacy e “proprietà” / localizzazione dei dati).
Nella mia visione tre sono gli attori in gioco, a vario titolo, quando parliamo di “cloud” (per comodità ometterò “computing” d’ora in poi, e le virgolette per il primo termine): il provider/fornitore del servizio, il sistema operativo, e le applicazioni.
Le applicazioni non accedono direttamente al provider, ma quando necessario si affidano al s.o. in maniera diretta o del tutto trasparente (ne parlerò meglio nel prossimo articolo), lasciando a quest’ultimo il compito di dialogare col provider per espletare le loro richieste.
Si può far uso di quanti provider si vuole, che si trovano registrati nel sistema. Registrare un provider equivale a definire l’indirizzo internet che utilizza per i servizi che espone, attribuendo a esso un nome ed eventualmente un elenco di protocolli di criptazione dei dati definiti per esso.
L’idea è quella di codificare i dati, sfruttando algoritmi come RSA, DES, AES, o altri, prima che questi vengano passati al provider, in modo da garantire la sicurezza della transazione in corso fra la nostra macchina e il server centrale, e per impedire che quest’ultimo possa andare a frugare nelle nostre informazioni, magari trattenendole illecitamente o fornendole addirittura a terzi.
La sicurezza nasce dal fatto che al server vengono passati i dati già codificati a monte, mentre tutte le informazioni relative all’algoritmo impiegato e parametri annessi (come, ad esempio, la chiave di codifica utilizzata) risiedono esclusivamente nel nostro computer. Il server viene utilizzato sostanzialmente come storage “stupido”: riceve dei dati, li conserva, e li ritrasmette quando richiesto (sarà poi il s.o. a decodificarli, una volta prelevati).
Ricapitolando, gli algoritmi di codifica utilizzati e i loro parametri sono trasversali ai provider. In teoria tutti i provider potrebbero condividere gli stessi (magari conservati in un apposito elenco), perché è l’utente finale a decidere in che modo i dati saranno criptati per uno specifico provider, indicando opzionalmente una configurazione di default nel caso ne sia presente più d’una.
Come accennato prima, è il s.o. che si occupa di interfacciarsi direttamente coi provider. Sappiamo che è compito del s.o. gestire le risorse a disposizione nella macchina, e fra queste le più importanti sono i dati che conserviamo nel filesystem sotto forma di file, cartelle, e degli attributi a essi associati.
Nulla vieta di aggiungere a tali attributi l’elenco dei provider associati a una determinata risorsa, sia esso un singolo file o un’intera cartella, comprensivo del percorso “relativo” (la “posizione” che assume all’interno dello storage del provider).
Questa risorsa sarà opzionalmente codificata prima di essere spedita al provider, nel caso in cui a quest’ultimo fosse associata una configurazione di criptazione, ma in ogni caso sarebbe possibile scegliere una configurazione alternativa allo scopo, in modo da garantire massima flessibilità al sistema.
Al momento per semplicità consideriamo soltanto il caso dell’associazione di un solo provider. Per più provider il discorso è più complicato, ma non impossibile da risolvere; si tratta di definire le politiche di aggiornamento della risorsa nel computer nel caso in cui questa sia stata modificata, ma fortunatamente siamo in presenza di problematiche già presenti e affrontate dai cosiddetti sistemi di versionamento, per cui non ce ne occuperemo.
Risulta più importante definire le politiche di aggiornamento di una risorsa col provider, nel momento in cui questa abbia subito delle modifiche:
- manuale (l’utente determina quando avviene la sincronizzazione)
- alla chiusura del file
- sempre (qualunque modificata va immediatamente comunicata, in modo da garantire coerenza fra i dati locali e quelli remoti)
- a intervalli definiti (ad esempio ogni 10 minuti)
Da ciò risulta chiaro che una copia dei dati rimarrà sempre in locale e, quindi, disponibile all’utente a prescindere dalle sorti del provider, che potrebbe anche chiudere o cambiare le modalità di accesso, senza per questo mettere in difficoltà o, peggio ancora, sotto ricatto l’utilizzatore.
Tornando alle risorse, è bene specificare che, nel caso di oggetti su filesystem, non abbiamo a che fare esclusivamente coi dati (ad esempio il contenuto di un file), ma anche coi loro metadati (nome, dimensione, attributi di accesso, ACL per filesystem e s.o. che li supportano, proprietario, gruppo, ecc.) e anch’essi andrebbero memorizzati nel cloud.
La memorizzazione dei metadati, e il loro recupero quando servono, pone però altri problemi. Supponiamo di avere sul PC #1 il file “Pippo.txt” il cui proprietario è l’utente Pluto, ma a cui gli utenti Topolino e Paperino possono accedere, col primo in lettura e scrittura, e il secondo soltanto in lettura. Una volta copiato il file nel cloud, provando a sincronizzarlo col PC #2 cosa dovrebbe succedere se la cartella in cui dovrà essere memorizzato Pippo.txt conterrà dei permessi diversi da quelli del PC #1? Ad esempio l’utente Pluto potrebbe non essere affatto definito all’infuori di esso.
In tal caso la politica da adottare potrebbe semplicemente essere quella di ignorare i metadati non compatibili con l’ambiente del PC #2, copiando il file e soltanto i metadati effettivamente utilizzabili. Oppure si potrebbe annullare l’operazione. O, ancora, obbligare l’amministratore del sistema a fornire un ambiente adeguato, in modo da procedere poi all’operazione.
Si tratta sempre di scelte riconducibili in ultima analisi alla volontà dell’utilizzatore del computer, ma che altrimenti rimarrebbero di difficile o poco pratica soluzione.
Ad esempio filesystem diversi possono utilizzare codifiche diverse per i nomi dei file. Il nome del file “Città.txt” risulta codificato in maniera diversa utilizzando il set di caratteri latin1 (o il cp1252 di Windows) rispetto all’UTF-8.
Peggio ancora su s.o. Unix-like, dove è facile che il nome del file sia semplicemente una sequenza di byte (escluso il valore zero, che viene usato per determinarne la fine) e, quindi, senza una precisa codifica specificata.
Posto che conosca quali codifiche sono utilizzate, l’utente potrebbe optare per una transcodifica automatica dall’una all’altra, ma tutto andrebbe bene soltanto fino a quando non saltasse fuori un simbolo non traducibile da una codifica all’altra. In tal caso si potrebbe forzare una rinomina del file, oppure annullare l’operazione, ad esempio.
Un altro problema è rappresentato dalla cosiddetta sensibilità alle maiuscole dei filesystem, di cui abbiamo già parlato in un apposito articolo.
In ogni caso bisogna rendersi conto che il nodo gordiano non è rappresentato dal cloud di per sé, quanto dalla differenza fra gli ambienti presenti nei vari computer. In altre parole, dalla famigerata interoperabilità di cui spesso si sente parlare, e di cui le macchine possono farsi carico fino a un certo punto, lasciando all’utente l’onere di “tagliare il nodo”, provvedendo egli stesso a utilizzare ambienti operativi “compatibili” fra di loro.
Comunque un aiuto in tal senso potrebbe essere rappresentato dalla memorizzazione nel cloud dell’ultimo s.o. utilizzato, con relativa versione e piattaforma hardware, in modo da informare l’utente di possibili problemi provando ad accedere da un diverso s.o..
Un ultimo accenno va fatto ad altre tipologie di metadati, come ad esempio il registro di sistema, che non sono direttamente associabili a un file o una cartella, quanto a una risorsa concettualmente astratta, anche se pragmaticamente locata su uno o più file all’interno del sistema (o del cloud).
Si tratta di strumenti che sono intrinsecamente legati al s.o. di cui si sta facendo uso, e che possono creare grossi problemi di interoperabilità nel caso in cui si volessero condividere i dati del registro su computer con s.o. completamente diversi, con versioni diverse del medesimo, o addirittura con la stessa versione ma su architetture diverse (x86 e x86-64).
Vedremo nel prossimo articolo in che modo un’applicazione potrebbe risolvere il problema, e in generale il suo ruolo e il rapporto che ha col cloud al fine di espletare (meglio) le sue funzioni, a tutto vantaggio dell’utente finale.
