@m0bi13 OVH miał już kiedyś swoją chmurę tego typu, nazywało się toto Hubic. Używałem kilka lat temu do synchronizowania kilkudziesięciu gigabajtów danych, które dość często się zmieniały. Działy się tam istne cuda i to prawdziwe szczęście, że nie straciliśmy żadnych plików. Najpierw, ni z tego ni z owego katalog, w którym znajdował się zaledwie 1 plik o rozmiarze kilku MB rozmnożył się do jakichś 30 GB. Potem było jeszcze lepiej, bo Hubic... Zaczął tworzyć kopie plików o identycznej zawartości, ale o dziwnych nazwach i rozszerzeniach, np. banana.tutu. Pozostaje mieć nadzieję, że jednak wyciągnęli z tego lekcję i ShadowDrive będzie działać lepiej.
Shadow Drive bazuje na kodzie #Nextcloud do udostępniania plików i synchronizacji (w tym webDav). To raczej stabilne i dobrze przetestowane rozwiązanie. Ale co wymyślą i w którą stronę pójdą, to nie wiem. Mają szansę tego nie popsuć i pomału widać, że serwisy oparte o standardowe, otwarte protokoły, mogą wygrać łatwością integracji z tymi od dużych dostawców, którzy chcą zamykać nas w ogrodzonych ogrodach.
E2EE w Nextcloud to co innego. Twoja apka kliencka (może być ich kilka) jest jedynym posiadaczem kluczy. Dla serwera te pliki są niezdatne do niczego, są zaszyfrowane. Nikt ich nie może podglądać, tylko Ty posiadający klucze. Dlatego też tracisz do nich dostęp przez web apkę. Widzisz, że jest folder z włączonym E2EE i tyle. Taki sejf.
Ale co? Https? No przecież wymaga współpracy klienta z serwerem, więc można napisać tak jak oni: end to end. Tyle że transmisja nie odbywa się z punktu A do B przez serwer, a z punktu A jedynie do serwera.
Serwer zna klucze. W "normalnym" e2ee ma nie znać.
@m0bi13 nie, chodziło mi o to, co opisałeś jako "E2EE w Nextcloud". jestem pod tym względem kompletnym laikiem, ale gdy czytam "client-side", to nasuwa mi się na myśl właśnie coś takiego.
Blogasek o Technologii
Aktywne