Ein Werkzeug zur sicheren und verteilten Dateisynchronisation

  • Meine schwer versehrten Damen und Herren
  • Dies ist eine Projektvorstellung.
  • "Unverständlichste Folie"
  • Begriffserklärung des Titels.
    • Unterscheidung: Synchronisieren / Austauschen
    • "sicher" ist schwammig
    • "dezentral" heißt ohne zentralen Server (wie git)
    • Werkzeug wie git
    • Name: Zweimaster, wendig, leichtgewichtig, verteilt Datenströme.
  • Ihr werdet heute zu Versuchskaninchen ausgebildet.

Um was geht's?



  • Demo nimmt ca. 50% Zeit ein, wird also nicht so trocken.
  • Viel Stoff für 45 minuten, muss schnell reden, ihr werdet am Ende abgefragt.
  • Viel Terminal, wenig Bling-Bling.
  • Es kommen aber viele Comics und Bilder!

Fragen bitte erst gegen Schluss stellen, weil der Vortrag so aufgebaut ist, dass er erst mal viele Fragen stellt. Dringende Fragen dürfen aber gleich gestellt werden. Sowas wie "Darf ich mal auf's Klo?".

Wer ist'n das?

  • Aus dieser Hochschule.
  • Vollzeit München.
  • Open Source Entwickler (rmlint)
  • Wer mehr über mich wissen will, darf gern nachher fragen.
  • Wer ich bin, ist ja eigentlich unwichtig… Darum geht's in dem Vortrag auch nicht.


Chris Pahl.





Wer mehr über mich wissen will:

https://sahib.github.io

Es war einmal…



  • Dann mal rein ins Thema...
  • Umfrage: Wer benutzt...
    • Dropbox oder andere Cloud Storage Anbieter (OneDrive, Google Drive)
    • ownCloud oder nextCloud
    • Syncthing, git-annex, resilio
    • Was selbst gebasteltetes?
    • git

Ihr seht schon: Es gib so einige Tools die man benutzen kann.

Das Problem

  • Ihr erwartet jetzt sicherlich, dass ich euch sage was schlecht an Dropbox ist.
  • Single point of failure, unsicher by default, us unternehmen, proprietär.
  • Zusammenarbeit über Dropbox (zB an Quelltext) funktioniert nicht wirklich.
  • (Man bräuchte sowas wie git: Man entscheidet selbst wie man es einsetzt und wie sicher es ist.)
  • Dateiaustausch ist eine Art Babel: Jeder benutzt was anderes.
  • Am längsten dauert der Handshake bis man sich auf's Tool geeinigt hat.
  • (Hyperlinks sind möglich, aber machen halt abhängig von einem Hersteller.)

Was ist das Ziel?





MAKE FILE SYNCING GREAT AGAIN!

Und das machen wir indem wir eine Mauer um die Cloud bauen. :) It will be tremendous. Great stuff.

Geht das auch detaillierter?

Dinge die Dateiaustausch sein sollte:



Viele Buzzwords. Und viele davon widersprechen sich auch noch. Aber wir reden ja von einer idealen Lösung. Spruch: "Ein Tool das alles kann, kann nichts richtig gut"

  • Einfach: User Discovery, FUSE Filesystem, ist kompatibel, nervt nicht.
  • Sicher: Daten sind by default stets verschlüsselt.
  • Schnell: Eigentlich optional, aber Video Streaming ist nett.
  • Versioniert: git junkie, Zusammenarbeit wird möglich, keine revisions filenames mehr.
  • Dezentral: Datenhoheit. Dropbox hinterlässt ein schlechten Nachgeschmack.

Aber, aber…

Ja, es gibt schon einige dezentrale Tools.

(Siehe: https://brig.readtheodocs.org/comparison.html)

  • So Vergleichdiskussion sind müßig und können den ganzen Tag dauern, ohne dass am Ende was dabei rauskommt...
  • nextCloud kann man hier in gewissen Sinne auch nennen ("dezentral")
  • Mein Tool macht aber auch einige Dinge anders, die nicht direkt vergleichbar sind.

Jetzt machen wir hier gedanklich mal einen Cut.

IPFS

»Inter-Planetary-File-System«

  • Ist wie beim Trinken: Man braucht eine gute Basis.
  • Interplanetary Filesystem. Das ist wörtlich zu verstehen.
  • Das ganze soll eine Art dezentrale, sichere versionierte Alternative zum heutigen Internet werden. Jeder Nutzer ist Server und Client zugleich.

Was kann das so?



$ echo 'Hallo Augsburg!' | ipfs add
added QmbLr7bEQkC85EEGEmQk42dLz25VBy2L6iHyZQu


$ ipfs cat QmbLr7bEQkC85EEGEmQk42dLz25VBy2L6iHyZQu
Hallo Augsburg!

Vorteil: Ganz ohne zentralen Server.

Nachteil: Kann bereits zum filesharing benutzt werden, aber nur sehr rudiemntär.



$ ipfs id -f '<id>\n'
QmeLNNcryy9Ky1dXnfnEPaDQ2KuJ6yafaSRZssjQ83ie84

»brig«



Entwicklungsgeschichte:

  • Betonung auf Hash Nanny.
  • Sicher durch Verschlüsselung und Public-Key Kryptografie.
  • Das ist das erste "beta" release (0.1.0-beta) - WELTPREMIERE!
  • Mit sehr viel Vorsicht benutzen.
  • Alles kann sich auserdem noch ändern.
  • Release early, release often.

Kurz gesagt: Fokus

Natürlich kann kein Tool gleichzeitig einfach zu benutzen, sicher und effizient sein. Es soll eine Balance zwischen Benutzbarkeit und Sicherheit geben - die Effizienz (hat zumindest momentan) eher drunter gelitten.

Siehe Demo.

Demo

  • Imperial March Musik
  • Big buck bunny
$ brig mv raiders twix
# sonst ändert sich aber nix.

Workflow

  • Synchronisieren kleines Ein mal Eins
  • Ein Tag aus dem Leben einer Datei.

Disclaimer: Sicherheit?

Ich hab ziemlich oft schon das Wort "sicher" benutzt. Wenn ich sagen würde, dass »brig« sicher ist, dann heißt das eigentlich nur dass ich beim Schreiben der Software die Absicht hatte, sichere Software zu schreiben.

Es kommt auf die Angriffsvektoren an. Und selbst wenn ich das geschafft hätte, dann kann man das Tool sicher benutzen, aber jemand könnte immer noch an deinen ungelockten PC gehen... (uvm) Vertragung und Speicherung ist sicher gemacht, aber man könnte zb derzeit trotzdem mit wenig Mühe herausfinden wer mit wem kommuniziert.

Philosophie ist allgemein: Ein Schloss, dass man nur unter Mühe öffnen kann, benutzt kaum einer.



Dezentralität

  • Was heißt jetzt eigentlich dezentral?
  • Problem: Beide müssen zur selben Zeit online sein.
  • Auch abhaengig vom Usecase:
    • Austausch von Folien und Notizen zwischen Studenten und Professoren: gut.
    • Einseitiges Herunterladen von Formularen bei einer Behoerde: schlecht.

Nutzermanagement

  • Ist nicht wirklich vorhanden.
  • Es gibt keine registrierten Nutzer.
  • Zwei Nutzer können den selben Displaynamen haben!
  • Aber nicht den selben Fingerprint.
  • Email bzw. Jabber ID ähnlich.






Nutzen:

Versionierung

  • brig = git - diff
  • versionierung hilft im Alltag, aber git ist normal nicht tauglich.
  • Man braucht keine diffs. Ein Tool sollte das möglichst "einfach so" machen.

Pinning

  • Nachbereitung.
  • Komplette Separation von Daten und Metadaten.




Roadmap





Hauptproblem: Nur ein Entwickler.

... und der arbeitet nen Vollzeitjob.

Keine gute Basis für eine stabile Weiterentwicklung.

Features die noch kommen sollen:

  • Knoten, die automatisch synchroniseren (als »blessed repo« wie bei git)
  • Fingerprints als QR Code
  • Mobile Version mit simplen Dateibrowser.
  • Verbessertes User-Management.

Hilfe? Erwünscht.

Problem: Man macht ein Release und kriegt 20 Feature Requests, mit teils total widersprüchlichen Anforderungen. Das artet in Feature-itis aus (-> Wollmilchsau)

Am Ende steht man mit eine Software da, die Kaffee kochen kann, dafür aber nur so mittel und dessen Name mit "j" beginnt. (Müsst ihr mal drauf aufpassen... jDownloader, jQuery, java)

Experience Reports:

  • Fokus auf Problemen, nicht auf Lösungen.
  • Was ihr tun wolltet
  • Was ihr eigentlich gemacht/erwartet habt
  • Warum das nicht so ganz funktioniert hat

Mithilfe via Experience Reports.

  1. Was habt ihr gemacht?
  2. Was habt ihr erwartet?
  3. Warum hat das nicht funktioniert?


Und sonst?

Probem gelöst?

Sagt ihr es mir...

  • Ja, die Lösung ist also ganz einfach... man schreibt einfach ein Tool das alles richtig macht, jeder nutzt das und gut ist.
  • Randall Munroe, der xkcd Autor sagt nein.
  • Abe ja, sagt ihr es mir: Waere so ein Tool hilfreich fuer manche von euch?

Letzte Worte



http://brig.rtfd.org

github.com/sahib/brig

http://sahib.github.io/brig/public



Fragen?

1
SpaceForward
Right, Down, Page DownNext slide
Left, Up, Page UpPrevious slide
GGo to slide number
POpen presenter console
HToggle this help