La domanda sulle prima sembra avere una risposta ovvia. Per come e’ costruito facebook, e per il suo modello di business, i dati devono essere catturati da Facebook e processati allo scopo di ottenere tutte quelle informazioni utili al profiling dell’utente e delle campagne in atto. In questo senso, quindi, dando Facebook come costante, per il modello di business di Facebook, per i servizi che vende e per come e’ stata costruita, e’ indispensabile che i vostri dati siano sul database di Facebook. Punto.
La domanda pero’ ha un risvolto interessante: puo’ esistere un modello di social network che NON tenga i dati degli utenti, ad esclusione dei dati di autenticazione? Questo e’ molto piu’ interessante, perche’ la risposta e’ sorprendente. Si, posso immaginare un’architettura che tenga i vostri dati sul pc locale, e li metta a disposizione.
Pensate ad una tecnologia come SIP. SIP e’ un protocollo che viene normalmente associato al VoIP perche’ e’ questo il suo uso maggiore, ma di per se’ SIP sta soltanto facendo da iniziatore. Lo stesso acronimo significa Session Initiation Protocol. Che cosa fa allora questo protocollo? Esso facilita due sistemi che vogliano parlare: la prima parte della negoziazione si occupa della parte di rete, definendo la disponibilita’ della controparte, e il suo indiirizzo.
Non e’ sempre necessario che avvenga questo, ma la piu’ performante configurazione di un server SIP e’ che i due client si loggino, e quando uno vuole chiamare l’altro il server SIP si limiti a dire “chiama questo IP e questa porta”. A quel punto il client A non ha piu’ bisogno del server (motivo per cui e’ la configurazione piu’ performante) , e il resto puo’ proseguire tra i due client, senza coinvolgere il server che viene cosi’ scaricato.
Ci sono configurazioni intermedie, nel senso che magari un client chiama il server SIP su IP, il server SIP va sulla rete telefonica e chiama l’altro client usando una normale telefonata (1). Oppure il caso in cui entrambi usano il server SIP per la telefonata.
La seconda fase, detta SDP, Session Definition Protocol, consiste nel fare in modo che i due client si accordino su COSA scambiare. Normalmente su SIP si scambia una normale chiamata voce, ma per come e’ definito SDP, i client potrebbero scambiarsi mail, immagini, indirizzi web, pagine html, documenti word, qualsiasi cosa abbia un mime type.
- L’ utente A si logga nel social network. Tutti i suoi dati sono sul PC/SmartPhone/Quelchele client. Uno o piu’ di uno.
- L’ utente B si logga nel social network. Tutti i suoi dati sono sul PC/SmartPhone/Quelchele client. Uno o piu’ di uno.
- L’utente A (il suo client) vede sulla sua bacheca che l’utente B ha convidiso una risorsa. Diciamo una foto.
- Il client dell’ utente A si collega al social network e chiede “come reperisco questa foto?”.
- Il server del social network fornisce l’indirizzo IP e l’hash tramite cui reperire la foto.
- Il client dell’utente A contatta il client dell’ Utente B e gli chiede la foto.
- Se vuole o se puo’ , il client dell’utente B la fornisce al client dell’utente A.
- L’utente A vede la foto di B nella sua bacheca.
- Se l’utente B ha piu’ di un dispositivo (diciamo un PC, una console, e uno smartphone), su quale dei client deve essere la foto? La risposta e’: i client devono tenersi continuamente allineati tra loro. Un simile sistema quindi deve prevedere un meccanismo di allineamento tra i client. In questo modo, si ridistribuisce la capacita’ dello storage, si ridistribuisce il consumo di rete (che non e’ piu’ diretto verso il centro-stella rappresentato dal social network) e si creano copie di backup.
- Ovviamente questo risente delle latenze di rete. Su questa affermazione qualcuno potrebbe concordare e qualcun altro no. Innanzitutto, questo sistema fa poche chiamate al nodo centrale, e poi se la sbriga tra i client. Se i client sono nella stessa rete/ISP, come capita per esempio agli utenti di Fastweb, o nelle universita’, non e’ detto che la banda sia poca. I client piu’ lenti peraltro sono sincronizzati con una copia (diciamo la copia nel PC di casa) e possono se necessario redirigere li’ le richieste.
- Il sistema funziona solo se almeno uno dei vostri client e’ online. Ma questo e’ proprio il bello: potete disconnettervi impedendo accesso FISICO ai vostri contenuti. Potete decidere, attraverso un firewall, chi puo’ e chi non puo’. Ovviamente, se VOLETE essere sicuri di essere visti, dovete lasciare un client che giri sempre in una rete a banda decente, tipo il computer di casa. Ovviamente tutti gli altri client devono scegliere se essere master o slave, nel qual caso si limitano a sincronizzare i contenuti.
- Il cloud viene visto anche come sistema di backup. Vero. Ma per questo potete semplicemente avere molti client sincronizzati tra loro. Il vantaggio in compenso e’ che avete un completo controllo sull’accesso dei dati, ovvero potete sapere in tempo reale CHI sta accedendo ai vostri contenuti.
- Si comporta come un server di autenticazione. Tutti i client si autenticano li’.
- Quando un contenuto viene condiviso, si limita a salvare un hash unico nel database, e l’identita’ di chi ha sottoposto il contenuto. Condividere un contenuto consiste nel salvare l’hash del proprietario e l’hash del contenuto sul social network. Il contenuto NON si muove dal client.
- Quando ci sono piu’ client, ogni software client si fa carico di sincronizzarsi tra diversi dispositivi. Il client si fa anche carico di redirigere le chiamate verso il client piu’ veloce.
- Quando il social network, il nodo centrale, riceve la richiesta di un contenuto , si limita a restituire una redirezione al luogo ove si trova il contenuto.
- Il client che vuole leggere il contenuto deve autenticarsi anche col client che lo deve fornire. Il quale confronta l’hash del richiedente con uno che ottiene dal server, ottiene un nounce, e se e’ chi dice di essere, allora lo fornisce.
- Valgono i filtri di privacy che settate SUL CLIENT, e non quelli che settate sul server centrale.
Se considerate che i tracker torrent hanno gia’ meccanismi di autenticazione che permettono solo ad alcuni di scaricare i contenuti , di fatto stiamo riducendo tutto il social network ad una interfaccia web centrale “potenziata” dal fatto di presentare le risorse sotto forma di un relativo torrent a download ristretto, la quale fornisce solo il frame e la struttura del sito, e il client non e’ altro che un browser che quando trova un oggetto embedded “di un certo tipo” (magnet link?) lo scarica usando torrent , piu’ un client che fa sia web che torrent, e che decide a chi dare i vostri contenuti ed a chi no. Le configurazioni di sicurezza sono sul client. Niente di piu’.
Anche lo storage non vi serve troppo, visto che si, dovete avere lo spazio per i dati di autenticazione e per i file torrent, ma niente di piu’: i contenuti sono tutti sui client.
Il vero problema di un modello simile e’ che di per se’ la sicurezza si sposta sul lato client, e quindi dovrete stare molto attenti ai meccanismi di autenticazione client-server e client-client, e nessuno vieta ad un client di ricondividere il contenuto fuori dal vostro controllo: vi faccio presente pero’ che questo avviene ANCHE OGGI, voi non sapete cosa fara’ chi legge la vostra pagina delle vostre foto, quindi non e’ un problema che risolverete centralizzando tutto.
(1) Usando Linux potete farlo con asterisk ed un normale modem, e’ abbastannza semplice.