Upspin: koniec silosów, ludzie Google rewolucjonizują udostępnianie plików

Te wszystkie dyski sieciowe – Dysk Google, OneDrive, Dropbox,czy co tam jeszcze, mają jeden podstawowy problem: każde z nichjest zamkniętym światem, każde ma swoje własne sposobylokalizacji plików i ich udostępniania. A przecież nie taki miałbyć Internet, pomyślany jako sieć sieci, z komunikacją poprzezuniwersalne protokoły. Chcielibyśmy raczej czegoś w rodzajuuniwersalnego lokalizatora zasobów, na podobieństwo schematu URIdla sieci Web, czegoś co nie zależy od Microsoftu, Facebooka czyGoogle’a.

Taki właśnie problem widzi zespół inżynierów Google’a.Andrew Gerrand, Eric Grosse, Rob Pike, Eduardo Pinheiro i DavePresotto piszą w w dokumentacjiUpspinu:

Zdjęcia wgrane do Facebooka czy Twittera są zarządzane przeztych dostawców – i w praktyce należą do nich.

Pomijając sporadyczne obejścia za pomocą URL, informacjeprzekazane tym usługom stają się dostępne tylko poprzez teusługi. Jeśli ktoś chce przekazać obrazek z Facebooka na swojegoTwittera, musi najpierw pobrać go z Facebooka, zapisać, a następniewgrać na Twittera. Czy nie powinno być możliwe przekazanie obrazkabezpośrednio z Facebooka do Twittera?

Ten model silosów z danymi, do którego doszliśmy w ciąguostatnich lat, ma sens dla dostawców usług, ale karze użytkowników,tych, którzy tworzą treści – i którzy powinni móc zarządzaćswoimi danymi.

Tak jakby plan9: globalna przestrzeń nazwZapewne wiecie, jak wygląda system nazw plików w systemachuniksowych: ścieżka /home/jan/dokumenty/rachunek.ods mówi nam, żeplik rachunek.ods znajdziemy przeglądając ścieżkę katalogów/home/jan/dokumenty. Nie ma tu czegoś takiego jak „nazwy dysków”,znane z Windowsa czy Symbiana.

Upspin rozszerza tę koncepcję w sposób analogiczny do np.systemu plików sshfs, tworząc ścieżki dostępu powiązane zkonkretnym użytkownikiem. Przykładowo ann@example.com/dir/file tościeżka dostępu do pliku file w katalogu dir na maszynieexample.com używanej przez użytkowniczkę ann. W Upspinie nieistnieje nic takiego jak plik lokalny, wszystkie pliki muszą znaleźćsię w swojej przestrzeni nazw.

Pliki oczywiście mogą być linkami symbolicznymi, czy to dokatalogów czy innych plików, a dostęp do nich jest kontrolowany wschemacie bazującym na infrastrukturze klucza publicznego, dlakażdego pliku w katalogu. Wszystkie niezbędne informacje o dostępiesą przechowywane w tym katalogu, w tekstowym pliku, opisującym, cokomu wolno. Jeśli takiego pliku kontroli w katalogu nie ma, to tylkolokalny użytkownik ma prawo dostępu do plików.

Jeśli więc użytkowniczka Ann zechce udostępnić do odczytuswoje pliki w katalogu użytkownikom joe@here.com i mae@there.com, towystarczy, że w pliku Access znajdzie się wiersz read:joe@here.com, mae@there.com – to wszystko. Tak ustawioneuprawnienia są dziedziczone przez podkatalogi.

Upspin projektowano z myślą nie o wydajności, lecz obezpieczeństwie – deklarują jego twórcy. Cały ten globalnysystem nazw jest trzymany w ryzach przez serwerową strukturę, wskład której wchodzą:

serwer kluczy, przechowujący klucze publiczne wszystkichużytkowników systemu,

serwer storage, przechowujący dane i indeksujący je zwykorzystaniem funkcji skrótu

serwer katalogowy, opisujący powiązania między danymi naserwerze storage i użytkownikami posiadającymi dane. Serwerkatalogowy łączy się w miarę rozwoju systemu z innymi serweramikatalogowymi, poprzez taki sfederowany system możliwe staje sięwyszukiwanie plików. Taka konstrukcja systemu oznacza, że nawet w wypadku naruszeniainfrastruktury serwerowej, użytkownik nie musi się martwić odostęp do jego plików – to on ma do nich klucze, a całeszyfrowanie zachodzi na jego komputerze.

Pojawienie się Upspinu jest prawdziwym przełomem w erze, gdykorporacje oferują użytkownikom gotowe, zamknięte produkty.Dostajemy oto zbiór interfejsów, protokołów i komponentów, zktórych można tworzyć przeróżne aplikacje do swobodnej,bezpiecznej wymiany danych między użytkownikami, bez żadnychsztucznych barier. To wszystko, jak podkreślajątwórcy projektu, nie jest produktem Google’a. To opensource’owapodstawa dla wielu innych produktów, które pozwolą na równiełatwe wymienianie się plikami, jak dziś wysyłamy do siebiee-maile, bez względu na to, z którego serwera poczty korzystamy.

Wydanie tego niezależnie od Google’a oznacza, że w firmie tejwciąż dużą siłę przebicia musi mieć niezależna grupadeweloperów, którzy nie są zainteresowani monetyzowaniemwszystkiego, co tylko możliwe, co w praktyce najczęściej oznaczagromadzenie informacji o użytkownikach. Tam gdzie kadra Googlezarządzająca chce, byśmy korzystali z Dysku, nad którym niesprawujemy żadnej kontroli, inżynierowie kontrolujący bloga obezpieczeństwie chcą, byśmy korzystali z rozwiązania, w którymto my pozostajemy właścicielami swoich danych.