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.
Secondo me ti fai troppi problemi. A meno che non stai parlando di servizi cloud a pagamento, mi sa tanto che quando proverai ad uploadare i tuoi file criptati sullo storage “stupido”, questi ti verranno rigettati o misteriosamente cancellati.
Il cloud, specie se gratuito, è una trappola per carpire informazioni, un do ut des dove una parte (loro) sa benissimo cosa vuole da te, mentre l’altra nella maggior parte dei casi sarà felice di caricare la propria roba solo perchè potrà farlo gratis o perchè confida al massimo nella possibilità di far sparire tutto in un secondo tempo se le cose si mettono male (eventualmente anche tirando in ballo la legge che però resterà al palo, quando si scoprirà che la società che gestisce la magic box ha sede in qualche buco sperduto dove non esistono leggi a protezione della privacy).
Non ho capito se le applicazioni sarebbero nel cloud (hostate dallo stesso provider dei dati) o in locale. Se sono in locale, il cloud sarebbe nient’altro che un disco remoto, il provider un mero fornitore di spazio disco, e nno sarebbe redditizio. Se anche le applicazioni sono nel cloud, che differenza fa se accedono attraverso il SO o direttamente? La privacy dei dati viene a mancare nel momento in cui i dati personali viaggiano indietro dal SO verso le applicazioni (che possono a quel punto fare, in background, harvesting, profiling e quant’altro).
Gli scenari possibili sono diversi, e includono quelli che hai elencato. Ne parlerò meglio nel prossimo articolo, che sarà dedicato alle applicazioni.
La privacy non viene a mancare nella misura in cui l’applicazione comunica al cloud il risultato delle sue elaborazioni “sotterranee” impiegando il s.o., perché se il canale è criptato (come disposto dall’utente), al cloud arriveranno informazioni inutilizzabili.
Questo perché, come dicevo nell’articolo, l’accesso al cloud avviene tramite le API o comunque gli appositi i meccanismi messi a disposizione dal s.o., che controlla tutto (su precise disposizioni dell’utente) l’ambiente cloud.
Ciò non toglie che l’applicazione potrebbe benissimo fregarsene dell’ambiente cloud in cui gira, aprire un socket direttamente sul suo sito e passare tutte le informazioni che ha raccolto. Ma questo scenario si verifica già adesso con qualunque applicazione “malevola”. Non serve il cloud, insomma, per minacciare la privacy.
Il vantaggio di un sistema cloud-aware come quello che ho descritto è che i dati passati ai provider sono sotto l’assoluto controllo dell’utente e non dell’applicazione.
Se oggi una normale applicazione tentasse di accedere a internet per passare dei dati, potrei intercettarla tramite il firewall e bloccarla. Ma se quest’applicazione si collega a un cloud, io oggi non posso sapere se sta sfruttando la connessione per espletare strettamente il servizio, o per fare altro. Oggi la mia privacy è effettivamente a rischio.
Invece su una piattaforma cloud-aware come quella descritta le due cose sono separate: al cloud si accede tramite il s.o. e l’utente ha assoluto controllo di quello che passa al provider. Se l’applicazione tenta anche di aprire una connessione “privata” verso qualche sito, posso sempre intercettarla e bloccarla col firewall. Per cui ho sotto controllo tutto, privacy inclusa.
E’ chiaro che un provider viene utilizzato sostanzialmente come storage online, per cui chi pensa di fare business sui dati privati degli utenti non andrebbe da nessuna parte.
Al contrario, servizi come DropBox, che puntano sul superamento della quota gratuita a disposizione per far pagare (giustamente) l’utente, non avrebbero alcun problema.
Ma sono ipotizzabili altri scenari, in cui il provider può offrire anche delle applicazioni. Ne parlerò meglio nel prossimo articolo.
Sono l’unico che ha riempito DropBox con applicazioni in versione portabile, così da avere Thunderbird aggiornato su tutti e 3 i miei pc, openoffice, player musicale, etc?
Certo, non c’è nulla di criptato anche perchè mi chiedo quale possa essere l’utilità di un sistema di criptazione su un pc per usare dati cloud che a quel punto saranno disponibili SOLO su quel pc. A meno di andarsene in giro con una chiavetta usb con su OpenPGP e le proprie chiavi. E’ una soluzione al problema privacy, ma non mi sembra la più comoda.
Il cloud, nella mia idea, rende inutile la macchina e il S.O. agli occhi dell’utente, il quale accede alle proprie applicazioni, ai propri dati, utilizzando il pc come “player” degli stessi. L’utente deve solo ricordarsi una password o se la vogliamo fare più complessa, deve portarsi dietro una chiavetta con su le proprie chiavi, senza nemmeno sapere cosa siano. Vai in un internet point, a casa di un amico, inserisce la propria chiavetta e nel giro di pochi minuti si trova il proprio sistema.
Ovvio che S.O. e applicazioni devono occuparsi di non lasciare traccia sul “player”, possibilmente sfruttando algoritmi crittografici, ma la chiave deve essere la semplicità, se no il cloud fa la fine del web semantico, ottima idea che non è mai veramente decollata (se non forse alcune coniugazioni semplicistiche).
Il cloud definitivo nascerà quando Facebook comprerà Dropbox. A quel punto il 70-80% degli utenti di internet userà il cloud senza nemmeno sapere cos’è, tutti i giorni e in modo semplice.
Il provider potrebbe avere accesso alle informazioni che io metto in cloud per fornire servizi aggiuntivi come ad esempio delle elaborazioni?
PS: Io sono disponibile a pagare per un servizio del genere, ma non molto tipo 5/6 euri al mese.
Cloud come la vedo io sarebbe avere un clone del proprio pc personale su un server.
A quel punto uno può fare accesso ai file manualmente (tipo share di rete), ai suoi dati e impostazioni attraverso una applicazione “aware” (app locale o servizio web più dati remoti, acceduti con il meccanismo della share) o alle applicazioni e al desktop vnc.
Il tutto condito da ACL, crittografia lato client (quì dici bene Cesare) e aggiornamenti asincroni e intelligenti.
Ci sono un tot di problemi ancora e si richiederebbe un riadattamento sostanziale del sistema desktop e l’adozione di diversi standard.
Inoltre sarebbe molto costoso, perchè nessuno ci guadagna e dunque l’utente deve sostenere tutti i costi direttamente.
Si potrà fare il giorno che non ci sarà più bisogno di lucrare e la tecnologia potrà essere sviluppata in maniera coerente e aperta. Fino ad allora io mi porto dietro il portatile o se lo lascio a casa ci tengo ssh acceso.
E’ chiaro che servirebbe uno standard. Non l’ho citato prima, ma è ovvio che debba essere così, perché se ogni provider e/o s.o. implementa un protocollo suo, tutto va a farsi benedire…
@Pluto: non vedo alcun problema, se tu li metti in chiaro.
5/6€ al mese non sono tanti, ma se ti fai i conti per un’azienda potrebbero essere una miniera d’oro.
5€ al mese sono 60€ l’anno. Moltiplicalo per tutti gli utenti…
Credo di essermi spiegato male.
Intendevo dire, attivo una elaborazione in background sulla mia macchina. L’effettiva esecuzione avviene in cloud ma per l’utente questo è trasparente.
I risultati e lo stato di avanzamento del processo sono visualizzati sono ritornati al dispositivo dell’utente.
Mi immagino prorio di avere un task manager che visualizza il carico dei core sulla mia macchina e, vicino, il carico dei “cloud-core”, che ho in affitto.
Ovviamente devono essere in chiaro dal provaider dei servizi.
“E’ chiaro che un provider viene utilizzato sostanzialmente come storage online, per cui chi pensa di fare business sui dati privati degli utenti non andrebbe da nessuna parte.”
Perchè no ? Cosa sta facendo facebook ? La faccia pulita del portale ti permette di rintracciare il compagno delle elementari mentre quella zozza si occupa di fornire biada a “È gratis (e lo sarà sempre)”
In questo momento chi volesse saltare addosso alla torta deve necessariamente alzare il tiro ma non sono mica tutti microsoft che può permettersi di lanciare uno smartphone fatto ad hoc. Il modo migliore è proprio quello di poter mettere le mani sui file che qualcuno pensa di caricare sopra.
Al principio i file testuali sarebbero preferibili perchè facili da scansionare ma chissà che già non esistano degli analizzatori di immagini, video, suoni…
Carichi un video con il compleanno di tuo figlio: c’è una bottiglia di coca cola sul tavolo vicino alla torta, sullo sfondo vedi un TV della sony ed in un angolo un cellulare nokia. Saranno solo fantasie e se invece esistesse già un sistema in grado di passare un video, riconoscere questi prodotti per poi inondarti di pubblicità con babbo natale mentre guarda una partita sul suo nuovo bravia e la commenta con la renna usando un nokia mentre beve una coca ?
Un analizzatore di suoni potrebbe leggersi gli mp3, riconoscere il genere musicale (anche senza spulciare gli id3) e poi bombardarti di spot di cantanti e musicisti che potrebbero piacerti.
E se il video fosse un pornazzo da girare agli amici che spot ti arriverebbe in buca ? Una f… di gomma ?
E’ ovvio che se i dati che ci carichi sopra sono tutti criptati all’origine (magari addirittura il nome) il giochetto non si può fare, se poi ci dovessero scappare degli strumenti per fare tutto in automatico, a prova di niubbo, ciao eh…
Ci tengo a ricordare agli scettici due cosette:
1- una volta c’era tripod, che offriva gratis qualche MB per farsi il proprio sitarello, appena lo aprivi arrivava una raffica di popup direttamente da loro e non li potevi levare. Tempo che hanno cominciato a diffondersi programmi prima ed integrati nel browser poi, per gestire il problema e tripod è sparito tra le nebbie: è venuto a mancare il core business.
2- e più importante, SOLO IN ITALIA voi selezionate la checkbox dove autorizzate l’uso pubblicitario dei vostri dati personali, ma all’estero, ad esempio già solo in UK, la checkbox si comporta nel modo opposto: selezionandola negate il consenso e se vi dimenticate di barrarla, praticamente accettate tacitamente di venire schedati ed eventualmente bombardati. Provate ad indovinare come s’è arricchita la famiglia della futura principessa del Galles…
Applicazioni come FaceBook esisteranno sempre, è inutile girarci attorno.
Non sono soluzioni cloud come quella che ho proposto che cambieranno le sorti dell’umanità. ;)
@Pluto: è fattibile, ma non so quanto possa essere utile. Magari per alcuni applicazioni “intensive” sì, ma per altre l’accesso al cloud dovrebbe essere del tutto trasparente.
I servizi ‘storage-cloud’ sono davvero una grande risorsa!
Tutti i problemi di privacy (presunta o reale) sono quantomeno esagerati. Spiegatemi una cosa, c’è differenza tra inviare come allegato email un bilancio e depositarlo su un servizio storage-cloud?
I dati passano comunque in mano a qualcuno altro (il server da qualche parte esiste, c’è comunque qualcuno che può metterci le mani sopra ecc…e nel 90% le email non utilizzano sistemi di criptazione).
Di fondo quello che manca (e mancherà per un bel pò secondo me in italia) è una ‘cultura informatica’: abbiamo da poco ‘accettato’ la presenza di computer come ‘strumenti di lavoro’, internet è appena agli inizi (a parte siti web e le – solite – pagine di Facebook perchè fa trendi non esistono molte realtà che utilizzano davvero internet ‘per lavorare’) – figuriamoci l’utilizzo di servizi cloud… se poi ci si mette il discorso ‘costo’ diventa tutto più difficile.
Personalmente utilizzo DropBox (gratuito) come sistema di backup dei dati (in pratica se il mio computer al lavoro va a farsi benederire non perde praticamente niente).
Se fossi il titolare dell’azienda per cui lavoro lo renderei obbligatorio per tutte le postazioni, ma essendo ‘ignorante’ in termini informatici è come parlare con un sasso (PS: ho tuttavia riso – di gusto – quando il suo braccio destro è venuto da me con il suo portatile lamentandosi che l’hard disk non funzionava… ciao ciao dati :P)
Anche logmein (che si potremme far rientrare nei servizi-cloud) è una manna dal cielo (poi la versione ‘light’ x emergenze JoinMe è utilissima!)
Per l’aspetto tecnico: il case sensitive è ‘aggirabile’ forzando sempre (ad esempio) il lower case. Fondamentalmente all’utente normale non deve fregare niente di come è scritto il nome di un file (ed in effetti è una delle cose che trovo più scomode e inutili dei sistemi Unix-base).
Il fatto di essere o meno integrato nel’OS invece forse è un bene (secondo me): già l’utente sa poco di come è strutturato un filesystem locale, se poi non capisce/si confonde con la distinzione tra file locale e remoto è la fine.
Al massimo posso concedere l’esistenza di servizi di backup-remoto…
Aspetto i prossimi post su gli altri servizi cloud (presumo applicazioni on-line e remote-work)!
PS: non capisco perchè Facebook dovrebbe comprarsi DropBox… e sinceramente spero che non capiti mai.
PSS: non è stato nemmeno citato ChromeOS o CloudOS che ‘dovrebbero’ essere l’avanguardia dei X-cloud servizi (dove X sta per app,storage,controllo ecc…)
Ciao
Ops! Mi sono accorto dell’esistenza di un ‘precedente articolo’!!! Scusa ho letto solo ora che facevi riferimento a ChromeOS a apps!
“Spiegatemi una cosa, c’è differenza tra inviare come allegato email un bilancio e depositarlo su un servizio storage-cloud?
I dati passano comunque in mano a qualcuno altro”
In teoria chi gestisce le mail non dovrebbe ficcanasare dentro gli allegati che passano dal suo server e sicuramente non ha niente da obbiettare se l’utente cripta i file prima di mandarli.
In fondo o offre un servizio a pagamento dietro abbonamento o si appoggia alle pubblicità (mail.it, schiaffa al fondo di ogni messaggio inviato uno spot).
Ma chi gestisce uno storage cloud di nuovo, o va di abbonamento quindi non dovrebbe (anzi non deve) avere altri interessi perchè dovrebbe già riuscire a mantenersi o va gratis ma allora necessita di un’adeguata contropartita e prova ad indovinare quale può essere.
La morale della favola è che \gratis\ non esiste, tranne quando si tratta di distribuire roba sulla quale non si possiedono diritti di proprietà…
“Se fossi il titolare dell’azienda per cui lavoro lo renderei obbligatorio per tutte le postazioni, ma essendo ‘ignorante’ in termini informatici è come parlare con un sasso”
Ecco allora evita perchè il tipo sarà come dici ignorante ma comunque si crederà abbastanza furbo da utilizzare subito la versione gratuita e guai se dati riservati dovessero finire sotto gli occhi di qualcuno non autorizzato.
Rubriche, fatture, addirittura progetti… da brividi: non è solo questione di dati interni, ma anche di leggi e responsabilità civili e penali che l’azienda tiene nei confronti di clienti e fornitori…
A proposito della ‘sicurezza’ dei dati su Dropbox.
E’ stata una delle cose che mi ha più preoccupato: a parte la semplicità di utilizzo (che non è da escludere) e la usabilità su quasi tutti i device (Win, Mac, Linux, Android, iOS…) ho verificato anche l’aspetto ‘cifratura’.
Tanto per dire in questa pagina ( https://www.dropbox.com/help/27 ) fanno riferimento alla criptazione dei dati (ed al fatto che utilizzano i servizi cloud di Amazon).
Per cui un ‘minimo’ di garanzia (per i dati) esiste, e quindi anche gli incubi di ‘furto/visione impropria’ *dovrebbero* essere ridotti.
Chiaro poi che se mette la solita password con tanto di bigliettino sul monitor…
Aspetta forse non ci siamo capiti. ILlproblema sicurezza non è tanto quel qualcuno che riesce a mettere le mani sul post it con la password quando la stessa società che gestisce dropbox o un qualunque cloud “gratuito”.
@[D]
inutili i tuoi tentativi, al giorno d’oggi i molti “informatici” di turno propagandano quello per cui vengono programmati tramite la loro passione, senza rendersi conto di dove tutto questo ci sta portando… Inutile parlare ai sordi e ai ciechi [D]…
;)
Al giorno d’oggi è più facile trovare complottisti che informatici…