Dirk beschreibt in einem Blogposting und dem Update dazu seine Kommunikationswerkzeuge. Ich habe mir mal angeschaut, wie das bei mir aussieht:

Nutze ich

• E-Mail (ist für mich eines der Hauptkommunikationsmittel. Daher kann ich Dirks These so nicht unterschreiben.)
• Signal
• XMPP/Jabber
• Jitsi
• Keybase
• Matrix (@qbi:matrix.kraut.space)
• Mumble
• Slack (nicht wirklich erreichbar, da ich den Client nur manchmal öffne)
• SMS
• Threema
• Twitter DM (nicht aktiv genutzt, wird aber als Kanal genutzt)
• Wire
• Zoom

Nutze ich nicht (mehr)

• Briar (würde ich gern, hier fehlen mir Leute, die das auch benutzen)
• Mattermost
• Telegram
• WhatsApp

Alles, was nicht genannt ist, fällt vermutlich in die Kategorie nicht genutzt.

Viele von euch werden Ende Mai viele E-Mails erhalten haben. Firmen wollten unbedingt Informationen über deren hervorragenden Datenschutz loswerden und in einigen Fällen wurde dazu aufgerufen, in irgendetwas einzuwilligen. Doch ging es euch auch so, dass da Firmen dabei waren, von denen ihr noch nie gehört habt?

Mir ging es so. Ich bekam einige E-Mails von Firmen, die ich nicht kenne und wo ich mich nicht erinnern kann, mit denen in einer Beziehung zu stehen. Ein Blick in die Datenschutz-Grundverordnung zeigt, dass es da ein wichtiges Recht für mich als Bürger gibt: das Auskunftsrecht.

Also werde ich das jetzt mal anwenden. Mit dem untenstehenden Muster schreibe ich die Firmen an und bitte um Auskunft. Falls ihr mögt, könnt ihr dies ebenfalls verwenden. Das lässt sich aber auch noch erweitern bzw. anpassen.

Sehr geehrte Damen und Herren,

die untenstehende E-Mail erreichte mich auf meiner persönlichen E-Mail-Adresse <FOO@example.com>. Nach Art. 15 DS-GVO habe ich ein Auskunftsrecht über meine personenbezogenen Daten.

Bitte teilen Sie mir daher gemäß Art. 15 Abs. 1 DS-GVO mit, ob Sie personenbezogene Daten verarbeiten und geben Sie ggf. Auskunft über diese Daten. Insbesondere möchte ich Sie bitten, mir die folgenden Informationen mitzuteilen:

1. Welche Daten über meine Person sind bei Ihnen gespeichert oder werden durch Sie verarbeitet?
2. Zu welchem Zweck wurden diese Daten verarbeitet?
3. Welchen Empfängern oder Kategorien von Empfängern wurden meine personenbezogenen Daten offengelegt?
4. Sofern die personenbezogenen Daten nicht bei mir erhoben wurden, geben Sie mir bitte alle verfügbaren Informationen über die Herkunft der Daten.
5. Falls meine personenbezogenen Daten an ein Drittland oder eine internationale Organisation übermittelt wurden, bitte ich Sie, mir mitzuteilen, welche Garantien gemäß Art. 46 DS-GVO vorgesehen sind.

Gemäß Art.15 Abs. 3 DS-GVO bitte ich um eine Kopie der personenbezogenen Daten, die Gegenstand der Verarbeitung sind.

Ich bitte Sie, mir diese Auskunft unverzüglich zu erteilen. Sollte ich binnen eines Monats nach Versand dieser E-Mail keine Rückmeldung erhalten, werde ich mich an die zuständige Aufsichtsbehörde wenden.

Mit freundlichen Grüßen

Der oben zitierte Art. 15 bietet noch das Recht auf mehr Informationen. Die in dem oben genannten Schreiben sind mir aber die wichtigsten Punkte. Daher habe ich das etwas eingekürzt.

Wenn ihr den Brief ebenfalls verwendet, würde ich mich über eure Erfahrungen freuen. Ich werde ggf. ebenfalls interessante Begebenheiten bloggen.

Ich treffe immer wieder Menschen, die gemeinsam an Dokumenten schreiben. Manchmal sind dies wissenschaftliche Veröffentlichungen, mal Pressemitteilungen, mal ganz andere Sachen. In vielen Fällen läuft es so, dass jemand einen Entwurf macht, den per E-Mail oder Messenger verteilt. Dann editieren andere Leute und schicken dies wieder weiter. Wenn ich solch ein Setup sehe, stelle ich den Leuten EtherPad vor und stoße auf helle Begeisterung.

Kürzlich fiel mir auf, dass es verschiedene EtherPad-ähnliche Software gibt und ich fragte nach, welche Software andere so kennen. Unten habe ich eine Liste von Software zusammengestellt, mit der man synchron im Web zusammenarbeiten kann. Sollte euch da etwas fehlen, hinterlasst bitte einen Kommentar.

• EtherPad bzw. Etherpad Lite: ist der Klassiker auf dem Gebiet. In einem Browserfenster kann man gemeinsam Dokumente bearbeiten, den Text exportieren, chatten etc. Die Software kann selbst gehostet werden. Probieren und benutzen kann man u.a. auf https://pad.riseup.net/ (auch als Tor Onion Service) oder https://pad.systemli.org/. Auf Github gibt es eine Liste von Instanzen.
• Google Docs: ist eine relativ bekannte Möglichkeit, Dokumente gemeinsam zu bearbeiten. Die Oberfläche lehnt sich an die entsprechenden Microsoft-Programme an. Dokumente können nur mit einem Google-Account angelegt werden. Je nach Freigabe kann man diese ohne Account lesen oder bearbeiten.
• Ethercalc: ist eine kollaborative Tabellenkalkulation. Auf der Ethercalc-Seite kann man die Benutzung probieren.
• Firepad: ist recht ähnlich zu EtherPad.  Die Liste an Beispielen macht den Eindruck, dass Firepad wesentlich mehr kann (Code editieren, Rich Text etc.). Ein Spielplatz zum Testen gibt es auf der Demoseite.
• Hiro: bietet Editieren mit oder ohne Login. Im Gegensatz zu EtherPad scheint es keine Möglichkeit zu geben, Rich-Text-Strukturen in den Text einzubringen. Dagegen lassen sich sehr leicht neue Dokumente anlegen und in einer Instanz verwalten. Der Zugriff kann explizit per Mail oder Telefonnummer vergeben werden. Aber innerhalb der Anwendung lässt sich auch ein Link zum Verteilen erzeugen. Ein Testdokument kann man direkt auf der Webseite anlegen.
• Sandstorm: ist eine Lösung mit der sich verschiedene Software betreiben lässt. Das Angebot reicht von Etherpad über Wikis bis hin zu Projektmanagementsoftware uvm. Wer einen Account auf einer Sandstorm-Instanz hat, kann nach Bedarf diese Software mit einem Klick installieren und nutzen. Eine Version zum Probieren ist verfügbar.

Die obigen Lösungen würde ich als allgemein nutzbare einschätzen. Daneben gibt es einige, die spezielle Wünsche befriedigen oder mit denen sich bestimmte Dokumentformate bearbeiten lassen:

• ShareLaTeX bzw. Overleaf: Beide Varianten eignen sich zum Bearbeiten von LaTeX-Dokumenten. ShareLaTeX benötigt einen Login. Bei Overleaf kann man das Editieren vorab testen.
• Fiduswriter: wie oben kann mit dem Programm LaTeX-Dokumente editieren und es wird ebenso ein Login benötigt. Nach meinem Eindruck ist die Eingabe zum Teil etwas komplizierter als oben, aber gerade bei der Literaturverwaltung scheint Fiduswriter mehr zu können. Mit einem Login kann man die Anwendung testen.
• HackMD: eignet sich Bearbeiten von Dateien im Markdown-Format. Die Seite benötigt auch einen Login und ihr könnt ausprobieren.
• Oinker: ist eine Plattform, die sich eher eignet, um Inhalte mit Text, Bildern etc. zu veröffentlichen. Das Einführungsvideo zeigt die Möglichkeiten der Plattform. Um dies zu benutzen, muss man angemeldet sein.
• Smashdocs: ist wie Oinker eher zum Bearbeiten kompletter Texte mit Bildern und mehr Informationen gedacht. Wie bei Word gibt es eine Änderungsverfolgung und anderen Features, die an Textverarbeitungen erinnern. Eine Demo ist nur mit Login verfügbar.
• CryptPad: legt die Dokumente verschlüsselt ab. Der Schlüssel ist Teil der URL. Das heißt, Personen mit einer korrekten URL bekommen Zugriff auf die Datei. Der Betreiber selbst hat nicht notwendigerweise Zugriff. Testen lässt sich die Software direkt bei CryptPad oder auch beim C3W.

Solltet ihr mehr solche Dienste kennen, schreibt es in die Kommentare.

Kürzlich trafen sich Teile der S9Y-Gemeinde im Linux-Hotel zum S9YCamp. Im Rahmen des Treffens wurde unter anderem eine neue Version der Blogsoftware herausgegeben. Ich habe das mal zum Anlass genommen und die Software auf den aktuellsten Stand gebracht. Ein unerwarteter Nebeneffekt war, dass mein bisher verwendetes Theme nicht mehr verfügbar war. Ich habe mich daher entschieden, zunächst RESY einzusetzen. Falls ihr ein anderes oder besseres Theme kennt, schlagt gern etwas vor. Derzeit bin ich für alle Vorschläge offen.

In meiner Inbox fand ich heute dieses nette Stück Spam:

<html>                                                                                                             
<head><title>401 Authorization Required</title></head>                                                             
<body bgcolor=“white”>                                                                                             
<center><h1>401 Authorization Required</h1></center>                                                               
<hr><center>nginx/1.2.1</center>                                                                                   
</body>                                                                                                            
</html>
 

Wenn man das HTML interpretiert, kommt dann sowas raus:

Ich verstehe nicht, warum man sowas als Spam in die Welt hinaus schickt. Die Nachricht wurde von einer IP-Adresse aus Südafrika eingeliefert. Neben der From:-Adresse hat der Spammer keine weiteren Header-Zeilen übermittelt. Vielleicht wollte derjenige einfach, dass ich das blogge.

Die operative Hektik angesichts der Heartbleed-Lücke bei OpenSSL legt sich langsam. Ein Großteil der Server scheint gepatcht zu sein und diverse Zeitungen wie andere Medien bringen zur Prime-Time Warnungen an die Nutzer. Jetzt beginnt die Zeit der Spekulation, woher der Bug kommt, ob der absichtlich eingebaut wurde und es wird auch die Frage diskutiert, ob Open Source sicherer bzw. besser als Closed Source ist.

Auf der einen Seite steht u.a. Linus’ Law als Argument. Der Erschaffer von GNU/Linux wird mit dem Spruch »Given enough eyeballs, all bugs are shallow« zitiert. Das heißt, wenn nur genügend Leute einen Blick in den Quellcode werfen, so wird jeder Bug gefunden und am Ende ist die Software »rein«. Am Beispiel des Linuxkernel ist zu sehen, wie gut das Modell funktioniert. Allerdings gibt es eine Reihe von anderer Open-Source-Software, wo offensichtlich niemand einen Blick in den Quellcode wirft. Dort bleiben dann zahlreiche Fehler unentdeckt. Das ist dann auch gleich das Argument der Befürworter von Closed Source. Denn dort bekommt niemand den Code zu sehen und kann daher auch keine Fehler finden. So lautet die etwas vereinfachte Argumentation.

Forscher vom Lehrstuhl für Betriebssysteme der TU Dresden haben sich dieser Frage im Jahr 2010 genähert. Für ihre Veröffentlichung The Mathematics of Obscurity: On the Trustworthiness of Open Source schufen sie ein Modell, in dem verschiedene Personen versuchen, Schwachstellen in Code zu finden. Wenn die Verteidiger zuerst sind, können sie die Lücke schließen. Die Angreifer haben auf der anderen Seite eine Lücke, über die sie ins System eindringen können.

Das Modell widerspricht dem obigen Gesetz von Linus Torvalds. Das Modell erbringt die Aussage, dass die Angreifer bei Open Source immer leicht im Vorteil sind. So nehmen die Forscher an, dass bei einem Open-Source-Projekt die Verteidiger in 6 von 10 Fällen einen Fehler vor dem Angreifer finden. Je nach den weiteren Modellannahmen braucht das Projekt mehr als Tausend oder gar mehr als Zehntausend Mitwirkende. Für den Fall, dass sogar in 9 von 10 Fällen der Fehler von den Verteidigern gefunden wird, können die Forscher zeigen, dass dies unmöglich ist. Alles in allem erscheint Closed-Source-Software besser aufgestellt zu sein.

Jedoch sagen die Forscher weiter, dass sie hier einen eingegrenzten Aspekt betrachten. In der Realität beheben die Hersteller von Closed Source die Fehler nicht sofort. Außerdem gibt es dort wirtschaftlichen Druck, Programme zu einem festen Datum herauszubringen. Dies führt dann dazu, dass die Programme nicht getestet sind. Alldies bringt die Forscher zu der Meinung, dass Open Source in der Gesamtschau vermutlich doch Vorteile mit sich bringt. Letztlich bringt gerade Freie Software die Vier Freiheiten mit.

Alles in allem kann ich nur nochmal den Aufruf aus meinem letzten Eintrag wiederholen. Nutzt Freie Software, schaut in den Quellcode oder versucht anderweitig zu der Software beizutragen. Damit helft ihr allen!