Hi dimi11,
ich habe mich, angeregt von deinem Beitrag, in den letzten Tagen gründlich mit Dropbox befasst. (Danke für den Anstoß!)
Gleich zu Beginn: Eine beworbene Verschlüsselung, welche mit Schlüsseln des Providers und nicht des Kunden funktioniert, betrachte ich persönlich als nicht vorhanden. Muss ich wohl nicht begründen ... . Diesen Schwachpunkt hätte man vermeiden können, wenn man es denn gewollt hätte.
Aber das ist auch das einzige, was mir an DB nicht gefällt. Den "Rest" finde ich schon sehr gelungen!
Truecrypt:
Ich kann dir bestätigen, dass beim Mounten eines auf dem Server liegenden TC-Containers keine Klardaten übers Netz fließen. Die Ver- und Entschlüsselung erfolgt lokal und es werden nur die verschlüsselten Daten geschrieben. Und das unabhängig davon, wo der Container physich gespeichert wird. Du kannst also getrost einen in der DB liegenden Container mounten. (Eine andere Frage ist aber immer, inwieweit ich überhaupt einen gemounteten (= unverschlüsselt vorliegendenden) Container auf einem System haben will, welches mit dem Internet verbunden ist. Hier muss jeder selbst einschätzen, ob er das verantworten kann! Das hat aber nichts mit Dropbox zu tun.)
Für das o.g. Ergebnis habe ich unzählige (unverschlüsselte!) Verbindungen zu diversen Servern aufgebaut, auf denen ich vorher TC-Container platziert habe. Dann wurde der Container gemountet und gelesen bzw. beschrieben. Sämtliche Vorgänge wurden mit Wireshark überwacht. Es floss definitiv kein Klartext. (Ja, das steht auch so in der Dokumentation zu TrueCrypt!)
Die Verbindung zur Dropbox konnte natürlich so nicht geprüft werden, denn selbige ist ja von Hause aus verschlüsselt - nur eben mit dem Schlüssel des Providers.
Fazit: TC-Container auf der Dropbox ist eine praktikable Lösung!
Abgleich mit Dropbox:
Es wird beworben und entspricht auch den Tatsachen, dass bei gleichem Timestamp nur die geänderten Bestandteile synchronisiert werden. Der Traffic hielt sich also wirklich in Grenzen. Das trifft auch auf den gemounteten TC-Container zu. Auch hier wurden nur "ein paar Byte" an Änderungen übertragen.
Ich habe auch mehrfach Tests mit Prüfsummen gemacht - keine Beanstandungen.
Ich kann mir also vorstellen, dass im Gegensatz zu meiner zuerst genannten Meinung dein Konstrukt funktionieren kann. Es ist und bleibt nach meinem Verständnis aber immer eine interessante (!) Bastellösung. Ohne wirkliche Notwendigkeit würde ich persönlich so was nicht machen. Zumindest nicht in einem produktiven Umfeld.
Was ich sonst noch gemacht habe:
Ich habe ja schon längere Zeit meine Kalender (ggw. 13 Stück!) auf einem WebDAV-Server und meine Adressbücher auf einem eigenen LDAP-Server zu liegen. Somit immer und von Überall die gleichen Kalender und Adressbücher verfügbar.
Jetzt habe ich testweise Auszüge dieser Dateien nach /Dropbox kopiert und im TB-Profil durch entsprechende Links ersetzt. Funktionell haben sich keinerlei Probleme ergeben. Die Adressverwaltung ist erwartungsgemäß schneller als über den LDAP, denn es wird ja trotzdem auf lokal vorliegende Daten zugegriffen. Beim LDAP muss ja immer erst auf dem Server gesucht werden, was immer einige ms dauert. Beim Kalender gibt es keine Unterschiede.
Die Adressbücher und Kalender aber in einen Container zu sperren und diesen immer erst mounten zu müssen, ist mir allerdings etwas vom Aufwand übertrieben. Andererseits habe ich beim unverschlüsselten Hosten von persönlichen Daten anderer Menschen (eben die Adressbücher mit vielen Hundert vollständigen Einträgen!) auf einem nicht dem dt. Datenschutzrecht unterliegenden Server so meine Bedenken! Also habe ich wieder den Datenzugriff auf meinen eigenen und gut gesicherten LDAP-Server und den IMHO vertrauenswürdigen WebDAV-Server meines Providers aktiviert.
MfG Peter