DigiProof: Digitales Testament

Ich hatte mir zu dem Thema digitales Erbe ja schon mal vor einiger Zeit Gedanken gemacht. Inzwischen hatte ich die glorreiche Idee, dafür eine Software zu schreiben, mit der man so ein Testament komfortabel anlegen und verwalten kann. Das "glorreich" klingt etwas ironisch, was (leider) Absicht ist.

Am Anfang hatte ich mich gefragt, wie man so eine Software am besten schreiben kann, so dass sie von möglichst vielen Leuten benutzt werden kann. Es gäbe da diverse Varianten, die mir eingefallen sind:

  • Als native Binary. Das heisst, z.b. in C++ geschrieben und für diverse Plattformen native übersetzt, also als Linux ELF Binary, Windows Exe oder MacOSX App. Die Schwierigkeit - für mich jedenfalls - dabei ist, ein portables GUI Programm zu schreiben. Ich habe mit native GUIs wenig Erfahrung, am ehesten noch mit Perl-TK, was aber für so ein Projekt nicht in Frage käme. Hinzu kommt, dass es für die diversen Systeme die verschiedensten Installationsmethoden gibt. Da ist man jahrelang am rumfrickeln, bis man wirklich die wichtigsten Plattformen untersützt. Also so eher nicht.
  • Als ausfüllbares Dokument. Hier müsste man sich nicht mit irgendwelchen Softwareinstallationen und Portabilität herumschlagen. Allerdings gibt es kein Dokumentenformat, das Formularfelder über alle Plattformen zuverlässig unterstützt. PDF käme dem noch am nähesten, aber unter Unixsystemen ist der Support eher bescheiden. Viel Ahnung hab ich davon auch nicht. Und die Datenpflege in so einem ausgefüllten Formular stelle ich mir auch eher eklig vor. Auch gestrichen.
  • Als Webservice. Das klingt zunächst charmant und in dem Bereich habe ich das meiste Knowhow. Charmant ist das aber nur auf den ersten Blick. Denn ein Webservice bedeutet, dass die Zugangsdaten der Accounts, die man da einträgt, auf einem Server im Netz liegen würden. Und da der Benutzer da immer rankommen können muss, muss es am Server entschlüsselbar sein. Das ist alles der reinste Alptraum und gar nicht machbar. Vom NSA Problem mal ganz abgesehen.
  • Als lokale Javascript App. Ich verwende ja nach wie vor TiddlyWiki, das ist so eine App. Das ist einfach eine HTML Datei, die man sich auf die lokale Platte packt, lokal via file:/// im Browser öffnet und dort Notizen einträgt. Das funktioniert wunderbar, ist portabel und erfordert beim Benutzer keine grossen Aktionen mit Softwaresetups etc. Das klang für mich nach DER tollen Idee.

Die letze Variante habe ich dann umgesetzt. Ich habe unter Verwendung von ember.js eine Javascript App erstellt, mit der man ein digitales Testament erstellen und ausdrucken kann. Die App funktioniert ganz hervorragend, ich hab sie sogar im IE zum Laufen gekriegt.

Im Lauf der Entwicklung hat sich dann jedoch herausgestellt, dass ich da wohl etwas vorschnell und unüberlegt entschieden hatte. Ein Bekannter hatte die Problematik gut auf den Punkt gebracht: Was? Javascript? Und DA soll ich meine ganzen Zugangsdaten eintragen? NEVER EVER! Und er hatte Recht: klar, lokal im Browser geöffnet kann das Teil theoretisch nicht aufs Internet zugreifen und selbstverständlich habe ich auch nicht so eine Funktionalität eingebaut. Nur wer soll mir das glauben? Angesichts der aktuellen Ereignisse um die NSA ist ja vor allem eines sonnenklar: Vertrauen war einmal. Denn ich hatte eigentlich ursprünglich vor, die Idee zu Geld zu machen, sprich: die Software zu verkaufen oder sowas.

Aus dem Vertrauensproblem ergibt sich zwangsweise, dass ich die Software als OpenSource veröffentlichen muss. Dazu gibt es keine Alternative. Unbeteiligte müssen in der Lage sein, anhand des Source zu beurteilen, ob meine Aussagen über die Software stimmen. Ich kann die Software freilich unter die GPL stellen UND trotzdem dafür Geld verlangen. Ich vermute aber mal ganz vorsichtig, dass das wahrscheinlich kein erwähnenswertes Geschäft werden wird, da sich ja jedermann den Source auch einfach ziehen kann. Und da es Javascript ist, muss man da auch nichts compilieren oder so. Runterladen, im Browser aufmachen, gut ist.

So. Das ist der Stand der Dinge. Ich habe nun also die Ehre, die Software hier an dieser Stelle als BETA zu veröffentlichen. Man kann die vorerst testweise benutzen und ausprobieren, bis ich mir überlegt habe, wie es damit letztlich weitergeht.

Hier ein paar Screenshots von dem Tool:

So sieht der Hauptscreen aus:

Man muss einige persönliche Angaben machen:

Hier wird ein Erbe eingegeben:

Und hier die Eingabe der Daten für einen Account, den zuständigen Erben und was der damit machen soll:

So sieht es nach der Eingabe aus:

Das ist das fertig generierte und ausgedruckte Testament:

Hier auch nochmal als PDF: Beispiel Testament Ausdruck (PDF)

 

Man kann die Daten verschlüsselt exportieren:

 

Und natürlich später wieder importieren:

Der Export sieht so aus:

Den Source der aktuellen BETA 2013-09-11-232202 gibt es bei Github.

Hier in Kurzform eine Featureliste:

  • in Javascript/HTML/CSS geschrieben, plattformunabhängig
  • Daten werden nur temporär und nur lokal gespeichert, es wird nichts irgendwo hochgeladen
  • man kann beliebige Accounts anlegen, pro Account die Zugangsdaten, den Erben und was damit zu tun ist
  • man kann ausserdem beliebig viele Erben anlegen, pro Erben auch einen Vertreter/Ersatz
  • das Anlegen von Erben ist optional, per Default würden dann die normalen Erben Rechtsnachfolger (also die, die durch Testament oder gesetzliche Erbfolge erben)
  • das Testament kann man ausdrucken, pro Erbe wird extra ausgegeben, so dass ein Notar jedem Erben getrennte Dokumente aushändigen kann
  • man kann die Daten verschlüsselt exportieren (Verschlüsselt mit einem 32fach mit SHA256 Hash aus einem Passwort mit AES256 im CBC Mode, mit einem Authentication MAC SHA512) und später wieder importieren.
  • Unterstützung für Mehrsprachigkeit, derzeit deutsch und englisch (orientiert sich nach den Browsereinstellungen), hier mal ein Screenshot mit deutscher Sprache.

Zu guter Letzt ein Hinweis: Benutzung auf eigene Gefahr! Ich übernehme keine Gewähr für entstandene Schäden!

12 September 2013 | #source

 

Warum man WhatsApp nicht nutzen sollte

  • Telefonnummer unverschlüsselt übertragen: Die Telefonnummer wird unverschlüsselt auf einen Server in den USA übertragen. Immer.
  • Das komplette Telefonbuch wird auf den Whatapp Server übertragen: Bei der Erstanmeldung (und auch später) wird das vollständige Telefonbuch des Handys zum Whatsapp Server übertragen. Enthalten sind die Telefonnummern und Namen aller Kontakte. Als Antwort erhält die App vom Server eine Liste aller Kontakte, die bei Whatsapp teilnehmen. Die Kontakte wiederum werden von ihrer App über den neuen Teilnehmer informiert.
  • Authentisierung ist hochgradig unsicher: Als Benutzername wird die Telefonnummer verwendet. Als Passwort auf dem iPhone die MAC-Adresse des WLAN-Interfaces und auf Android die IMEI (Hardware-ID). Jeder, der diese Daten hat, kann Nachrichten fälschen.
  • Die Verschlüsselung von Nachrichten ist unsicher: Erst im August 2012 hat Whatsapp angefangen, übertragene Nachrichten zu verschlüsseln. Die implementierte Methode ist unsicher, funktioniert nicht und ist mit zumutbarem Aufwand knackbar.
  • Bezahlsystem unsicher: Bei der Abobezahlung wird HTTPS nicht erzwungen. Ein Angreifer kann einen Benutzer umleiten und so an seine Bankdaten (Kreditkarte) gelangen. Die Angriffsmethode ist seit etwa 10 Jahren bekannt.
  • Datenbankverschlüsselung ist unsicher: Es handelt sich nicht um Verschlüsselung im eigentlichen Sinne, sondern eher um eine Art Verbergen. Gelangt ein Angreifer in den Besitz eines Telefons mit installiertem Whatsapp, kann er ohne viel Aufwand die Datenbank öffnen und auslesen.
  • Inkompetente Entwickler: Die Whatsappentwickler sind bekanntermaßen inkompetent was Themen wie Kryptographie, Netzsicherheit oder Privatsphäre anbelangt. Die oben aufgelisteten Probleme sind zum Teil seit Jahren bekannt und wurden bisher noch nicht erfolgreich behoben. Entweder weil die Entwickler die Sache noch schlimmer gemacht haben oder weil sie die Problematik ignoriert haben. Das Unternehmen verklagt regelmäßig Sicherheitsexperten, die Fehler in der App bekannt machen.

Quellen:

11 September 2013 | #networking

 

2 meiner Garnelen

Heute nicht viel, nur ein Foto:

2013-09-08 - Garnelen:

08 September 2013 | #aquarium

 

Der Herausgeber konnte nicht verifiziert werden

Heute habe ich auf meinem Arbeitsplatz PC mal den Emacs upgedatet. Ich habe jahrelang 20.7 benutzt, aber nun war es doch mal an der Zeit :)

Im Falle von Emacs muss man nicht mit irgendwelchen "portable apps" herumfummeln, es gibt einen offiziellen Windowsport bei GNU. Runterladen, Auspacken, Feddich.

Dachte ich.

Aber beim Starten kam dann folgende Meldung (und die kommt jedesmal):

Der Herausgeber konnte nicht verifiziert werden. Möchten Sie diese Software ausführen?

Diese Datei verfügt über keine gültige digitale Signatur, die den Herausgeber verifiziert. Sie sollten nur Software ausführen, die von Herausgebern stammt, denen Sie vertrauen.

Hier ein Screenshot davon:

Die Meldung ist ein wenig irreführend und dementsprechend habe ich mich beinahe tot gegoogelt. Auf diversen Windowshilfeseiten wurden die obskursten Dinge empfohlen, vor allem irgendwelche Registryeinstellungen. Huh?

Wie sich heraussstellt, kriegt man das viel einfacher weg. Windows merkt sich, wo eine Datei hergekommen ist. Insbesondere der Schritt vom Auspacken auf die Platte wird anscheinend peinlichst genau überwacht und gespeichert. Die Lösung ist daher ebenso logisch wie einfach: die Datei muss lokal erzeugt worden sein, dann ist er happy. Wenn man Cygwin installiert hat, geht das wie folgt:

cat runemacs.exe > re.exe && mv re.exe runemacs.exe

Da "cat" kein Entpacker ist, den Windows beobachtet, weiss es nicht, woher "cat" die Daten hat, aus denen es die neue Datei erzeugt hat und somit ist nach dieser Maßnahme die nervige Warnung weg. Daran sieht man auch sehr schön, dass das ganze mit Signaturen herzlich wenig zu tun hat.

Wo ich dabei bin, so erstellt man einen Startmenüeintrag für den Emacs unter Windows:

  • Verküpfung/Ziel: C:\portable\emacs-24.3\bin\runemacs.exe -l c:\cygwin\home\user\.emacs
  • Ausführen in: C:\Temp

Die Pfade muss man natürlich anpassen. Die Datei "c:\cygwin\home\user\.emacs" entspricht dem Cygwinpfad "/home/user/.emacs" und beinhaltet die Einstellungen. Aber das sollte man als Emacsler bereits wissen.

Und noch eine Sache: obwohl ich nun die Version 24.3 im Einsatz habe, erkennt der Emacs unter Windows nicht von alleine UTF8 Dateien, warum auch immer (unter Unix kann er das). Daher musste ich noch folgende Einstellungen in die .emacs mit aufnehmen:

;; set up unicode
(prefer-coding-system       'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(setq default-buffer-file-coding-system 'utf-8)
(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING))
(set-clipboard-coding-system 'utf-16le-dos)

02 September 2013 | #unfassbar

 

Rainbow Shiner im Paarungskleid

Gestern waren meine Rainbow Shiner endlich mal in Paarungsstimmung. Einige Männchen waren leuchtend orange gefärbt, ein beeindruckender Anblick. Währenddessen sind sie leider ziemlich hektisch herumgeschwommen, daher sind die Fotos etwas verschwommen.

2013-09-23 - Nochmal:

2013-08-29 - Elritzen Paarung Orange 2:

2013-08-29 - Elritzen Paarung Orange 1:

Update 2013-09-23:

Am Sonntag Wasserwechsel gemacht und schon geht’s wieder los:

29 August 2013 | #aquarium