Haben Sie genau einen Computer? Dann sind Sie vielleicht noch nicht über das Sync-Problem gestolpert. Obwohl, auch wer nur einen Rechner hat, wünscht sich, dass alles „irgendwo“ liegt, wo man im Fall des Falles einfach weiterarbeiten kann, wenn die Platte gestorben ist, das Laptop gestohlen wurde oder man sich schnell man einen anderen Rechner leihen musste, weil der eigene „Habemus Papam“ spielt. Kennen Sie das Spiel? Das geht so: Rechner funktionieren bekanntlich mit Rauch. Das erkennt man daran, dass der Rechner nicht mehr tut, sobald der Rauch rausgeht. Und dann spielt es, im Gegensatz zur Papstwahl, keine Rolle mehr, ob der Rauch weiss ist oder schwarz, kaputt ist kaputt.
Kein Problem im Zeitalter von Virtualisierung und Cloud, richtig? Noch wichtiger wird die Syncerei (hihi, wie schreibt man das? Syncherei? Süncker-Ei?), sobald man auf mehreren Rechnern einen und denselben Datenstand haben will. USB-Stick-Sync ist fummelig, schwer automatisierbar und anfällig – vielleicht verliert man den Stick genau an dem Tag, wo man diese hyperwichtigen Dokumente usw. usf. – Horror. Da muss etwas besseres her. Apple-Jünger wissen genau, wovon die Rede ist: Das Tool hieß iDisk und hatte für damalige Verhältnisse ausreichend Kapazität. Leider nur war es laaaaaangsam. Und außerdem war es – schwupps – irgendwann als Dienst eingestellt. Apple macht das durchaus mal. Natürlich gibt es iDisk noch, aber nur dem Namen nach, denn nun synct es keine Verzeichnisse mehr.
Ok, es gab ein Leben nach iDisk: Dropbox. Coole Sache, 2 GB waren frei, das reicht bis ans Lebensende. Denkt man. Das habe ich aber auch schon von der 1,2MB-Floppy gedacht – schließlich passte da gezippt der komplette Shakespeare drauf. Die 2 GB reichten nicht lange, aber es gab Methoden, das Limit zu erhöhen: Das Tool auf Twitter erwähnen, Freunde als neue Nutzer anschleppen, Kameras anschließen (500 MB pro Kamera, ging natürlich unter dem Strich meist nach hinten los), oder auch, wie altmodisch, Geld bezahlen. Nicht gerade Pfennigbeträge, aber ging so, irgendwie 120 Euro pro Jahr, wenn ich mich richtig erinnere. Teurer als eine USB-Festplatte mit 500 GB, aber wir wollen ja jetzt nicht Äpfel mit Birnen vergleichen. Trotzdem hatte Dropbox Nachteile:
- Die Server stehen irgendwo auf der Welt. Schönen Gruß an NSA, Patriot Act, wen auch immer.
- Es war schwer zu überprüfen, ob es den Service morgen noch gibt. Zur Erinnerung: Direkte und indirekte Kunden von Megaupload konnten ihre Daten ja auch mal bei der neuseeländischen Polizei aus der Asservatenkammer holen. Das habe ich mir gemerkt, fand ich noch schlimmer als die NSA-Verwicklungen jetzt.
- Das Arbeiten im Team wurde bestraft: Wenn ich Dateien mit anderen gemeinsam halte, zählt der Speicherplatz bei allen angeschlossenen Nutzern. Wollen vier Leute gemeinsam 100 MB verwalten, „verbraucht“ das 400 MB. Gemerkt habe ich es, als mir ein Freund ein halbes Giga Photos von einem gemeinsamen Segeltörn rüberschob – vorbei war es mit meinen Frei-GB.
- Um Verschlüsselung muss man sich selbst kümmern. Natürlich kann man ein Apple-File-Vault sharen oder so, aber das ist in der Praxis untauglich, da bei jeder Miniänderung alles gesynct werden muss.
Aus diesen Gründen ist in vielen Firmen der Dropboxzugang für dienstliche Belange verboten oder gesperrt. Oder beides. Aber jetzt kommt SpaceNet ins Spiel: Wir haben, wie es aussieht, da einen echten Knaller gelauncht. SpaceNet Sync’N’Share heisst das Produkt, die Server stehen hier in München, pro Vertrag können beliebig viele User eingerichtet werden, clientseitige Verschlüsselung wird unterstützt, und das beste: Im Gegensatz zu anderen Produkten muß man nicht alles syncen. Die Daten liegen in Bibliotheken, also in einer Art Repository, und von denen kann man beliebig viele anlegen und sich aussuchen, welche man auf welchem Rechner syncen will. Besser noch: Man kann aus einer Oberfläche sogar mehrere Server anbinden. Einen privaten, einen für die Abteilung, einen gemeinsamen mit dem Projektteam eines Kunden, was das Herz begehrt. SpaceNet hat das nicht komplett selbst entwickelt, das wäre ja auch sinnlos, das ganze basiert auf Open Source (dort heißt das Projekt „Seafile“).
Mein Anwalt hat das auch schon installiert. Der hatte das Problem, daß er mit seinen technisch meist eher harmlosen Mandanten sensible Sachen per Mail austauschen wollte. Das scheiterte regelmäßig an der Verschlüsselung. Hier ist das einfacher, man kann beispielsweise mit einem Partner ein Passwort vereinbaren und dann nur noch Dateien an eine bestimmte Stelle legen – der Rest geht automatisch. Das kriegt jeder Mandant hin. Und damit ist es auch technisch der unsäglichen DE-Mail überlegen. Ich lege ein Dokument ab, schreibe, von mir aus unverschlüsselt, eine Mail, daß ich was geschickt habe, und die Daten werden kopiert, ohne daß sie irgendjemand dazwischen ausgepackt hätte. Oder auch nur hätte auspacken können. Sicher ist sicher. Aber DE-Mail ist ja keine technische Angelegenheit, sondern eine politische.
Leider werden bei Seafile die Passwörter zum Server übertragen:
„Seafile servers don’t store the password for an encrypted library. To view an encrypted library online, you need to temporarily provide the password to the server. Your password is only recorded in the server’s encrypted memory. It would be cleared from the memory in an hour. After that, if you want to view the library, you’ll have to enter password again.“
Damit ist eine providerbasierte Lösung mit seafile für sensible Anwendungen ungeeignet 🙁
Viele Grüße aus Italien! — Volker
Richtige Beschreibung, falsche Schlußfolgerung. Die Paßwörter müssen halt bei der Übertragung geschützt werden, und dafür gibt es SSL.
Schönen Gruß zurück!
Der Übertragungsweg ist das eine.
Das andere ist, dass ich meine Daten verschlüssele, damit sie auf dem Server (also beim Provider) nicht gelesen werden können. Wenn ich die (Verschlüsselungs-) Passwörter aber dann dem Server schicken muss, dann kann ich mir doch das Verschlüsseln auch gleich ganz schenken. Oder ist mit ‚password‘ was anderes gemeint?
Tanti saluti!
— Volker
Klingt ein bisserl paranoid … Es ist doch so: Das Passwort wird lokal eingegeben, verschlüsselt übertragen und auf dem Server im verschlüsselten Memory abgelegt.
Auf dem Server kann man damit nicht ohne weiteres etwas anfangen, selbst wenn man vollen Administratorzugang hat. Vielmehr müßte man mit krimineller Energie eine Art Man-in-the-middle-Attac installieren.
Da erscheint es mir einfacher, direkt auf Ihrem Client anzusetzen. Ich bleibe dabei: mit Sync’N’Share ist man sehr sicher unterwegs.
Ist aber nur sehr wenig kriminelle Energie erforderlich:
1. Server-Sourcecode downloaden
2. Eine Zeile Code einfügen: savePassword( irgendwoAufPlatte )
3. Compile & Build
4. Server starten
Die Clients haben keine Chance was zu merken, und Herr/Frau Chef merkts nur dann, wenn er/sie was von der Materie versteht und gezielt sucht.
Ich bleibe dabei: Sicher geht anders 🙂
Viele Grüße nochmal!
— Volker
So einfach, wie Sie tun, wäre das nicht. Sie müssten sich dazu erst einmal bei SpaceNet als Mitarbeiter einschleusen (und SpaceNet müsste Sie einstellen). Dann müssten Sie erst mal rauskriegen, wie Sie an den Installationsroutinen vorbei einen bestimmten Server kompromittieren könnten. Oder gleich alle, aber das wäre beides nicht einfach. Und auch wenn Sie das als wenig kriminell empfinden: Für sowas würden Sie bei SpaceNet wahrscheinlich fristlos gefeuert. Wenn man Ihnen auf die Schliche kommt, natürlich. Aber, wie gesagt, da greife ich lieber direkt auf dem Client an. Ist unkomplizierter, unaufwendiger und schwerer nachzuvollziehen.
Ich überzeuge Sie vermutlich nicht, aber wissen Sie was? Das ist eine akademische Frage. Wer sagt Ihnen denn, dass Ihr Keygenerator nicht kompromittiert ist und die Schlüssel auch bei der NSA hinterlegt? Aber wenn Sie dann Sync’N’Share in der Option Private Cloud bei SpaceNet betreiben (das heißt auch, hinter einem Gateway mit privatem IP-Adressraum), kann die NSA noch nicht mal was anfangen mit dem Key. Aber vermutlich hat uns ja die NSA auch schon unterwandert 🙂
Das meinte ich mit Paranoia, ohne Sie damit natürlich angreifen zu wollen. Paranoia ist ja auch ganz gesund, wir gehen keiner Sicherheitsüberlegung aus dem Weg, solange die Möglichkeit besteht, daß Kunden hier Daten verlieren könnten.
Lassen wir’s gut sein, wir haben unsere Standpunkte ausgetauscht und ich glaube an diesem Punkt kann sich jede/r ein eigenes Bild machen. Und vielleicht habe ich mit meinen Anmerkungen ja ein bisschen zur Vorbereitung auf die dabei zu erwartenden Diskussionen beitragen können. Jedenfalls wünsche ich viel Erfolg beim Launch, viele Grüße aus dem herbstlichen Piemont!
— Volker
Sorry, bitte zu korrigieren: „auf die dabei zu erwartenden Diskussionen“ –> „auf die noch zu erwartenden Diskussionen“
🙂
Ein kurze Frage hab ich noch: Habe ich das richtig verstanden, dass die Passwörter nur vom Webclient zum Server übertragen werden, nicht aber von der nativen (zu installierenden) Qt Version?
Nochmals Grüße!
— Volker
PS: Schön wär, wenn auch noch meinem kleinen Korrekturwunsch entsprochen würde, dann könnte auch dieses PS gelöscht werden 🙂
Ich weiss nicht … Wer mit mir reden will, kann mir Mails schreiben. In einem öffentlichen Schreiben zu verlangen, öffentliche Briefe rückwirkend zu ändern, finde ich – gelinde gesagt – strange. Auch, wenn es sich um eine höfliche Bitte handelt, wie hier.
Zur Frage: Das ist richtig, der Browser braucht entschlüsselte Versionen, der native Client kann selbst entschlüsseln (und verschlüsseln natürlich). Den Browser braucht man nur bei der Einrichtung, übrigens, was aber für den Puristen durchaus ein nicht zu vernachlässigender Punkt ist.
Danke für die Info: Also bekommt der Server das Passwort in jedem Fall mindestens einmal pro verschlüsselter Library, nämlich bei der Einrichtung zugeschickt? Gemäß dem Motto ‚einmal ist keinmal‘? Tut mir leid, aber wenn das so ist, ist das m.E. eine in der Tat nicht zu vernachlässigende Schwachstelle.
Nichtsdestotrotz nochmal viel Erfolg,
tanti saluti!
— Volker
PS bzgl. ’strange‘: Ich hatte nach dem Absenden einen doofen Tippfehler entdeckt und im Sinne der besseren Lesbarkeit meines Geschreibsels um Korrektur gebeten. Das ist doch nicht ’strange‘, menno 🙂
Das war eine historische Info, das stimmt nicht mehr: Seit Version 2.x kann man auch auf dem Mac mit dem nativen Client Bibliotheken anlegen. Beim Windowsclient konnte man das ohnehin schon vorher. Nun braucht der Server also in keinem Fall mehr das Passwort.
Na bitte 🙂 Kann man die Möglichkeit zur Nutzung des Webclients serverseitig abschalten?