Föderierte Messenger – Konzeptionelle Probleme am Beispiel Matrix

Föderierte Systeme sind in einigen Kreisen gerade sehr angesagt. Das Konzept ist nicht neu, hat aber mit Matrix (Element), Mastodon und anderen Instanzen des Fediverse inzwischen neue prominente Vertreter. Hinsichtlich Datenschutz und digitaler Privatsphäre haben diese Systeme aber strukturelle Probleme.

Föderiert vs. Zentral

Föderierte Systeme sind das Gegenteil von zentralisierten Systemen, die von ihren Kritikern auch gerne als „Walled Gardens“ bezeichnet werden. Zentralisierte Systeme werden so bezeichnet, da in ihrem Kern eine zentral verwaltete Serverinfrastruktur steht, über welche die beteiligten Clients miteinander kommunizieren. Das System nutzen nahezu alle proprietären Dienste, aber auch freie Systeme wie Signal.

Föderierte Systeme bestehen dagegen aus einem Netz unabhängiger Server, auf denen dieselbe bzw. eine kompatible Software läuft, die miteinander kommunizieren und gewissermaßen ein Netz bilden. Das System kennt eigentlich jeder Anwender, da die E-Mail so funktioniert. Praktisch gesagt: Während man von WhatsApp zu Signal keine Nachricht schreiben kann, geht das von GoogleMail zu Posteo natürlich schon. Im Messenger-Bereich ist es auch nichts wirklich neues, denn XMPP („Jabber“) funktioniert ebenfalls nach diesem System.

Ein föderiertes System ist beim Aspekt der Unabhängigkeit vom zentralen Anbieter unschlagbar. Es wird deshalb vor allem von Befürwortern der digitalen Souveränität gerne hervorgehoben. Bei zentralisierten Systemen wie z. B. Signal hängt alles vom zentralen Betreiber ab. Schaltet Signal seine Server ab, ist das Kommunikationsnetz Signal Geschichte. Die Serversoftware ist zwar quelloffen, aber ein neuer Betreiber könnte nicht automatisch an die Stelle des ehemaligen zentralen Betreibers treten.

Risiken offener Protokolle

Ein grundlegendes Risiko dieser offenen Protokolle zeigt schon ein Blick auf die Geschichte von XMPP. Ist die Entwicklung noch jung, gibt es meist nur einige wenige Clients und eine Serversoftware. Die Zahl der Betreiber und Nutzer ist ebenso noch recht gering. Neue Funktionen und Änderungen am Protokoll werden schnell verteilt und erreichen schnell alle beteiligten Anwender.

Mit der Zeit differenzieren sich die Softwarelösungen aber immer mehr aus. Genau das finden die Befürworter solcher Systeme ja auch gut. Änderungen und sinnvolle Weiterentwicklungen brauchen immer mehr Zeit, um alle Beteiligten zu erreichen. Es wird immer mehr zurückhängende Instanzen geben und Inkompatibilitäten im Netzwerk.

Ein Beispiel dafür ist die Einführung von OMEMO bei XMPP, die bis heute nicht alle Clients erreicht hat. Ein anderes Beispiel ist die klassische E-Mail, wo immer noch nicht alle Server standardmäßig Transportverschlüsselung anbieten. Kunden von Posteo konnten vor einigen Jahren einstellen, dass eine E-Mail nicht verschickt wurde, wenn die Gegenseite keine Transportverschlüsselung gewährleistete. Das waren insbesondere in der Anfangszeit ganz schön viele, ist mit der Zeit aber natürlich weniger geworden.

Systembedingte Probleme

Die Zeit kann aber nicht alle Probleme lösen. Einige Schwierigkeiten sind systemimmanent und können nicht sinnvoll überwunden werden. Sobald man Matrix nutzt, ist man Teil des föderierten Netzwerkes. Die einzelnen Instanzen müssen miteinander Daten austauschen können, da man ansonsten nur mit anderen Anwendern des Servers kommunizieren könnte, auf dem man selbst registriert ist.

Während man bei einem zentralisierten Anbieter wie Signal nur einem Anbieter vertrauen muss, bedarf der Einsatz von Matrix Vertrauen in alle Anbieter von Matrix-Serverinfrastruktur. Das ist umso gefährlicher, weil Metadaten-Vermeidung strukturell bei verteilten Infrastrukturen aufgrund der Einbeziehung vieler Server und Clients schwierig ist.

Ein paar praktische Beispiele: Alle an einer Kommunikation beteiligten Matrix-Server speichern beispielsweise theoretisch unbegrenzt die komplette Kommunikation. Umso bedenklicher, da einige Clients des heterogenen Ökosystems (siehe Nachteile solcher Netzwerke oben) wie KDEs NeoChat nicht mal Verschlüsselung beherrschen. Gleichwohl würde das sowieso nur die Inhalte und nicht die Metadaten schützen. Man kann Nachrichten zwar löschen, aber technisch handelt es sich dabei lediglich um eine Art „Löschwunsch“ an andere Server, ob diese das auch umsetzen, entzieht sich der Kontrolle.

Der Homeserver, auf dem man sein Konto angelegt hat, speichert zudem noch deutlich mehr: Kontaktliste, Mitgliedschaften in Gruppenchats, Nachrichtenverläufe usw. Diesem Betreiber muss man extrem vertrauen. Allerdings hat man hier wenigstens ein wenig Steuerungsmöglichkeit.

Nicht das Ende der Probleme

Dabei handelt es sich noch nicht mal um das Ende der Fahnenstange. Es gab im Gegensatz zu Signal oder Threema keinen Audit der kompletten Infrastruktur, sondern nur 2016 der E2E-Verschlüsselungslösung. Die Implementierung von E2E-Verschlüsselung in den Clients steht noch auf einem ganz anderen Papier. Oft ist ja nicht die Verschlüsselung das Problem, sondern die Umsetzung im Client. Ein Problem das vor allem bei so heterogenen Ökosystemen natürlich zum Problem wird, weil man nicht weiß was die anderen Beteiligten für Software nutzen.

Die Finanz- und Entwicklungsstruktur der zentralen Bausteine sind auch kein Beispiel für Transparenz. Matrix bzw. Element (ehm. Riot) wird primär von der New Vector Ltd. entwickelt. Eine Firma, die nicht gerade die transparenteste Finanzsituation hat. Hier ist man gegenüber Signal oder auch Telegram nicht im Vorteil.

Alles schlecht? Nein, aber die falsche Außendarstellung

Sind föderierte Kommunikationssysteme im Allgemeinen und Matrix im Speziellen deshalb schlecht? Nein! Zumindest wenn man die richtige Perspektive wählt und keine falschen Erwartungen weckt.

Zentrale Systeme haben Nachteile, weil man sich abhängig von einem Betreiber macht. Im Hinblick auf eine digitale Souveränität des Individuums, kleiner Gruppen, Firmen oder gar Staaten können föderale Systeme einen Ausweg bieten. Je nach Anforderungen und Wünschen ist das ein interessantes Angebot.

Das hat aber alles nichts – wirklich gar nichts – mit Datenschutz und digitaler Privatsphäre zu tun! Wer bei dieser langen Liste von Defiziten und Problemen zum aktuellen Zeitpunkt Matrix als Privatsphären- und Datenschutz-freundliche Alternative zu Signal oder Threema bewirbt, hat ganz gewaltige Scheuklappen auf. Ich finde es erschreckend wie viele Kommentatoren sich hier vom Begriff der digitalen Souveränität und dem Open Source-Charakter blenden lassen.

Der Artikel Föderierte Messenger – Konzeptionelle Probleme am Beispiel Matrix erschien zuerst auf [Mer]Curius






Hallo ubuntuusers Planet!

Das Ikhayateam von ubuntuusers.de hat mein Blog im Planet aufgenommen. Vielen Dank für die Ehre.
Mein Name ist Andreas und ich nutze Ubuntu GNU/Linux seit 2005 auf meinen Computern. In der Linux-Community bin ich auch als waldstepper bekannt.

Ich schreibe unregelmäßig über Meine Erfahrungen mit Linux in meinem Blog. Ich wünsche euch viel Spaß beim Lesen meiner Artikel.






wop: team back in action

Über World of Padman las man lange nichts hier bei Zockertown.

Aus gegebenen Anlaß will ich das hier nachholen.

Wann war eure letzte Lan Party? Sicherlich einige Jahre her, oder?​

Auf meiner lezten Lan Party war auch die eine oder andere WoP Session drin.

Schön zu lesen, dass sich das alte Team wieder aufgerafft hat und wieder an die Arbeit geht!

worldofpadman.net/news/wop-team-back-in-action

Ich liebe diesen Fun Shooter über alle Maßen. Wenn es hier Neues gibt, schreibe ich das hier.






Postfix: From-Adresse beim Relay über Smarthost erzwingen

In diesem Beitrag dokumentiere ich eine Lösung für die Meldung: „554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Umgebung

Ich betreibe einen Virtual Private Server (VPS) im Internet, sowie einige Raspberry Pis und weitere Geräte, die man heute wohl am ehesten dem Internet der Dinge zuordnen würde.

Diese Systeme sollen mir Systemmeldungen per E-Mail senden. Dafür habe ich mir ein günstiges E-Mail-Postfach bei Mailbox.org gebucht und auf den betroffenen Systemen Postfix installiert und zum Versand über einen Smarthost konfiguriert. Die Konfiguration erfolgte über die Ansible-Rolle relaymail von Yannik. Diese dient jedoch nur als Werkzeug. Die Konfiguration kann selbstverständlich auch manuell durchgeführt werden.

Problembeschreibung

Bei einer Systemüberprüfung fielen mir einige Fehlermeldungen der folgenden Art ins Auge (einige Werte durch <Platzhalter> ersetzt):

„<Hostname und IP-Adresse> said: 554 5.7.1 id=<ID> – Rejected by next-hop MTA on relaying, from MTA(smtp:[<IP-Adresse>]:10025): 554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Weitere Informationen zu dieser Meldung und deren Ursache finden sich im Mailbox.org-Benutzerforum in: „mailbox.org als smtp Relay nutzen“

Während meine Raspberry Pis mit Raspbian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 sich wie erwartet verhalten und lediglich meine E-Mail-Adresse in das Header-Feld „From“ eintragen, fügt mein VPS mit Debian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 den Namen des jeweiligen Benutzers bzw. Dienstes mit ein, welcher die E-Mail versenden möchte. Diese Informationen nimmt der VPS aus dem Kommentarfeld der /etc/passwd. Während die Kommentarfelder auf meinen Raspberry Pis leer sind, sind diese auf dem VPS entsprechend gefüllt.

Im E-Mail-Header stellt sich das dann wie folgt dar.

Header-Auszug bei E-Mail von Raspberry Pi

Date: Mon, 10 May 2021 04:56:32 +0200 (CEST)
From: no-reply@example.com

Header-Auszüge bei E-Mails vom VPS

From: no-reply@example.com (Cron Daemon)
To: root
Date: Mon, 10 May 2021 04:44:12 +0200 (CEST)
From: Jörg Kastning <no-reply@example.com>
Date: Mon, 10 May 2021 04:44:36 +0200 (CEST)
From: root <no-reply@example.com>

Lösung

Um das Problem aufzulösen, lasse ich nun Postfix das Header-Feld „From“ umschreiben und explizit auf den Wert no-reply@example.com setzen. In der /etc/postfix/main.cf müssen dazu folgende Zeilen vorhanden sein:

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps =  regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check

Inhalt der /etc/postfix/sender_canonical_maps:

/.+/    no-reply@example.com

Dies sorgt dafür, dass Postfix das Feld „Envelope-From“ explizit auf no-reply@example.com setzt.

Inhalt der /etc/postfix/header_check:

/From:.*/ REPLACE From: no-reply@example.com

Hiermit wird der Wert des Header-Felds „From“ explizit auf no-reply@example.com gesetzt. Die Lösung habe ich hier gefunden. Damit läuft der Versand meiner Systembenachrichtigungen wieder.

Weitere Artikel zu Postfix und Smarthosts in diesem Blog






Metadaten – Immer noch zu wenig beachtet

Wir erheben nur Metadaten“ – Wie oft hat man diesen Satz in den letzten Jahren gehört. Dabei sind Metadaten das wahrlich interessante und Metadaten-Vermeidung, die hohe Kunst. Dieser Aspekt ist leider in der Praxis oft immer noch im toten Winkel der Debatte.

Definition: Metadaten oder Metainformationen sind strukturierte Daten, die Informationen über andere Daten enthalten. Das kann ganz unterschiedliche Bereiche umfassen. Im hier behandelten Kontext meint es Informationen wie Wer, wann, wo, mit wem, worüber usw.

Ein lange bekanntes Problem

Bei jeder Novelle der Überwachungsgesetze und bei jedem Skandal um Telemetrie-Datenerhebung durch Firmen kommt zuverlässig das Argument, dass man nur Metadaten sammeln würde und die Inhalte nicht tangiert wären. Die meisten Menschen sind dann beruhigt, weil sie glauben, ihre wahrhaft sensiblen Daten wären weiterhin geschützt. Weit gefehlt!

Für einen Einstieg in die Materie empfiehlt sich immer noch ein Artikel auf netzpolitik.org von 2014: Wie dein unschuldiges Smartphone fast dein ganzes Leben an den Geheimdienst übermittelt. Ergänzend dazu ein Bericht der SZ von 2014 was sich aus Telefonüberwachung ableiten lässt: Die Lüge von den Metadaten. Wohin die Sammlung von Metadaten führen kann, hat die ZEIT 2015 eindrücklich dargelegt: BND speichert 220 Millionen Telefondaten – jeden Tag.

Die Berichte entstammen der Hochphase der Globalen Spionage- und Überwachungsaffäre, aber der Sachverhalt hat sich seitdem kaum geändert. Immer noch sammeln Firmen und Geheimdienste systematisch Metadaten, immer noch beschwichtigen Politiker und immer noch glauben die meisten Menschen, ihre Kommunikationsinhalte wären das wirklich schützenswerte.

Das ist verständlich, weil die Inhalte vermeintlich unsere Vorlieben, Interessen, Ziele, Wünsche und Träume enthalten, aber unsinnig, denn die Kommunikationsinhalte sind bei den meisten Menschen völlig uninteressant und ohne Kontext auch meistens wenig aussagekräftig. Wirklich interessant für Firmen und den westlichen Überwachungsstaat sind die Metadaten. Denn sie geben Auskunft über Bewegungsprofile, Netzwerke und Verbindungen.

Zumindest gegenwärtig lassen sich Metadaten auch immer noch leichter automatisiert auswerten als Video-, Sprach- oder Textinhalte. Wobei angesichts der Fortschritte in der automatischen Spracherkennung und Inhaltserschließung das bald hinfällig sein könnte.

Wir erzeugen mehr und nicht weniger Metadaten

Die oben referenzierten Artikel sind alle 6-7 Jahre alt. Damals wurde nur das Bewegungsprofil, Internet, WhatsApp und E-Mail berücksichtigt. Smart Watches, intelligente Fitness-Armbänder, Smarte Lautsprecher, Smarte Autos – all diese Entwicklungen waren noch nicht so weit wie heute. Das Ausmaß der genutzten Dienste und die Zahl der Sensoren im Smartphone hat seitdem somit definitiv noch zugenommen.

Im Unterschied zu den Inhalten kann man Metadaten nicht vermeiden, indem man selbst ein bisschen verschlüsselt und ein wenig sensibler im Umgang mit seinen Daten ist. Möglicherweise ist das Thema auch deshalb so wenig im Fokus, weil es ein Ohnmachtsgefühl auslöst. Bei den Inhalten kann der Einzelne aktiv werden und zu wirkungsvoller Verschlüsselung greifen. Dabei gibt es erfolgversprechende Verfahren, bei denen wir mit großer Wahrscheinlichkeit davon ausgehen könnten, hinterher unsere Inhalte effektiv geschützt zu haben.

Um Metadaten zu reduzieren, hilft es nur Dienste zu nutzen, die genau diese Daten vermeiden. Mit ein bisschen Verschlüsselung seiner Dateien im kommerziellen Cloud-Dienstleister oder der Inhalte seiner E-Mails beim gleichen Anbieter kommt man da nicht weiter.

Umdenken nicht in Sicht

Eine komplette Änderung alle Gewohnheiten und Dienste kann man von niemandem verlangen. Bei neuen Diensten oder Geräten sollte man diesen Faktor aber endlich berücksichtigen. Die Erkenntnis wie wichtig und gefährlich Metadaten sind, ist schließlich alt genug.

Es gibt gute und verbreitete Dienste, die sich zumindest des Problems angenommen haben. Die Signal-Entwickler beschäftigen sich seit Jahren mit der Reduzierung und Vermeidung von Metadaten. Bei Threema hat man dieses Problem auch immer beachtet. Wer freie Software bevorzugt, hat ebenfalls Alternativen: Die Vermeidung von Metadaten als Konzept gilt auch für den besonders sicheren Messenger Briar.

Viele andere Dienste tun dies nicht. Einerseits weil die Vermeidung von Metadaten kompliziert ist, andererseits weil es bei vielen Entwicklern keine Priorität hat. Das gilt natürlich für viele kommerzielle Dienste, aber auch für die neuen Lieblinge der verschränkten FOSS/Datenschutz-Community.

Die neuen föderierten Messenger (z. B. Delta Chat / Matrix) sind strukturell bedingt genau so ungeeignet für die Vermeidung von Metadaten wie XMPP und E-Mail vor ihnen. Die Vernetzung eines föderierten Systems benötigt einfach systembedingt Metadaten und bringt einen Kontrollverlust mit sich, weil man den Serverbetreibern vertrauen muss.

Vor allem den Hype um die neuen föderierten Protokolle kann ich unter diesem Gesichtspunkt nicht verstehen. Hier werden zu offensiv Konzepte vermischt, die sich nicht immer vertragen: Digitale Souveränität und Datenschutz. Man mag auf die alten Protokolle, wie beispielsweise die E-Mail, nicht verzichten können, aber muss doch nicht sehenden Auges im Bewusstsein der hier beschrieben Problematik neue Protokolle etablieren, die genau die gleichen strukturellen Probleme haben.

Zusammengefasst

Metadaten sind das wirkliche Problem. Sie sind für alle Feinde unserer digitalen Sicherheit und unserer Privatsphäre interessant, wir erzeugen immer mehr davon und das Problem steht zu wenig im Fokus. Verschlüsselung ist nett und so lange sie mit wenig Aufwand zu realisieren ist, auch ratsam – sie geht aber am Kernproblem vorbei. Das gilt auch für die neuen gehypten Dienste.

Der Artikel Metadaten – Immer noch zu wenig beachtet erschien zuerst auf [Mer]Curius






Gesperrte Fail2ban IP-Adresse entsperren

Fail2ban kann genutzt werden um Server gegen unbefugte Logins zu sichern. Dabei durchsucht Fail2ban die entsprechenden Logs und blockiert böswillige Versuche in das System einzubrechen. Damit gehört Fail2ban zu den Intrusion Prevention Systemen.

Manchmal kommt es allerdings vor das eine IP-Adresse gesperrt wird, welche nicht gesperrt werden sollte. Problematisch ist dies z.B., wenn es die eigene IP-Adresse ist. Der Fail2ban-Client bietet hierfür eine Operation an um IP-Adressen wieder zu entsperren:

fail2ban-client unban 192.168.1.2

Damit wird die entsprechende IP-Adresse von der Sperrliste gelöscht und die Firewall-Regel entfernt. Anschließend ist besagte IP-Adresse wieder in der Lage auf den Server zuzugreifen.






Audacity, eine Übernahme und Telemetriefunktionen

Audacity soll nach der Übernahme durch die Muse Group Telemetriefunktionen erhalten. Ein Kommentar über den Sinn und Unsinn solcher Funktionen, Diskussionen und Übernahmen von Open Source-Projekten.

Vor einigen Tagen ging die Meldung durch den Ticker, dass die Audiobearbeitungssoftware Audacity (Link zu audacityteam.org) durch Muse Group gekauft wurde. (LinuxNews und heise.de berichteten). Ich war über diese Meldung etwas überrascht, weil es etwas seltsam ist, ein OSS-Projekt zu „kaufen“. Die Software an sich ist GPLv2-lizenziert und ansonsten lässt sich lediglich eine US-Wortmarke finden. Ich konnte nicht einmal eine deutsche/europäische Marke hierzu ausfindig machen. Es geht bei dem Vorhaben der Muse Group sicherlich eher darum, den Einfluss auf die Entwicklung von Audacity auszubauen, um das eigene Produktportfolio zu erweitern.

Tantacrul hat diesbezüglich ein 15-minütiges Video zu seinen neuen Aufgaben erstellt, das auf YouTube verfügbar ist.

Es ist sehr zu begrüßen, dass ein Unternehmen die Mittel bereitstellt, eine Software wie Audacity weiterzuentwickeln. Ein Vorteil von kommerziell getriebener Entwicklung ist es, dass Leute dafür bezahlt werden, die unschöne, aber nötige Arbeit zu erledigen, um die Qualität beim Gesamtprodukt zu steigern. Auf der anderen Seite tauchen natürlich bei einer solchen „Übernahme“, die sich bei so einem Projekt immer noch ungewohnt anhört, Befürchtungen auf, dass Interessenkonflikte zu einer Strategieänderung bei der Entwicklung führen. Darüber hinaus ändert sich mitunter die Kultur der Entwicklung und die Gemeinschaft wird mit neuen Vorstellungen konfrontiert.

Dass es irgendwann Krach gibt, habe ich nicht ausgeschlossen. Dass es aber so schnell geht, hätte ich auch nicht gedacht. Am Dienstag, dem 04. Mai wurde ein Pull Request eröffnet, der den Namen „Basic telemetry for the Audacity“ trägt. Zum Zeitpunkt, an dem ich diesen Artikel hier schreibe, umfasst der Diskussionsthread schon über 850 Beiträge und wurde als „Draft“ zurückgestuft. Bei diesem offenbar kontrovers diskutierten Thema geht es darum, Audacity Telemetriefunktionen zu verpassen.

Ich könnte jetzt mit euch die konkreten Änderungen Stück für Stück auseinander nehmen, aber die dort verknüpften GitHub-Kommentare (besonders die Emojis) sprechen für sich. Alle, die einen C++-Hintergrund haben und CMake kennen, können sich die Implementierung zu Gemüte führen. Ich werde an geeigneter Stelle vereinzelt darauf eingehen.

Ein Glaubenskrieg

Telemetrie ist immer ein heikles Thema, besonders in der Open-Source-Welt. Hierbei geht es darum, die Nutzungsweise der Software an eine zentrale Stelle, dem Hersteller, zu melden, damit dieser Schlüsse daraus ziehen kann. Geht man noch einen Schritt weiter zurück, geht es darum, die Nutzung der Software messbar zu machen. Dies ist besonders im Management beliebt, da es Außenstehenden die Möglichkeit gibt, die Nutzung der Software zu analysieren und die Entwicklung zu regeln. Fragen wie „Entwickle ich an der richtigen Stelle?“, „Wollen die Nutzer das?“ oder „Haben wir genug Nutzer?“ sollen damit beantwortet werden.

In der vollen Ausbaustufe gleicht die Telemetrie einer Bildschirmaufnahme, bei der jeder Klick, jede Eingabe und jede Ausgabe an den Hersteller versendet werden. Das alles ist bei dem oben genannten Pull Request nicht der Fall, wie das Team nachdrücklich beteuert. Datenschutzrechtliche Aspekte lasse ich in dieser Betrachtung erst einmal außen vor, weil diese Diskussion das eigentliche Problem verschleiert.

Das Problem an diesem gesamten Umstand mit der Telemetrie ist, dass FOSS, also freie, offene Software, vom „mündigen Anwender“ ausgeht. Ich habe dieses Thema schon mal im Blog thematisiert. Dabei wird eine sehr aufgeklärte Weltanschauung vertreten: hat ein Anwender ein Problem, meldet er sich in einem Issue Tracker oder der Mailing Liste. Nur hat dieses Wunschdenken nichts mehr mit der Realität zu tun, vor allem, wenn die Zielgruppe nicht größtenteils aus Softwareentwicklern besteht, die diese Verfahrenswege kennen. Jetzt gibt es zwei Möglichkeiten: entweder auf das Feedback verzichten oder andere Wege finden, die Metriken zu erheben. Die Metriken sind zudem nur dann aussagekräftig, wenn sie eine repräsentative Nutzermenge abbilden - ergo: man müsste sie bei allen erzwingen.

Erschwerend kommt bei Audacity dazu, dass wir es hier mit einer Offline-Anwendung zu tun haben. Ist man es bei Webseiten gewohnt, dass die Inanspruchnahme von solchen zwangsläufig Verkehrsdaten erzeugt (seien es die Browserhistory, Logfiles auf dem Server, Analytics, o. ä.), so erwartet man bei lokaler Software nicht, dass diese „nach Hause telefoniert“. Zumindest früher.

Genau das soll bei Audacity jetzt allerdings passieren. Hierzu wurde extra die cURL-Bibliothek in den Source Tree eingefügt, was nebenbei noch eine komplett neue Abhängigkeit mit sich bringt. Diese Abhängigkeit wurde sogar sehr brachial hinzugefügt, wie aus dem diff hervorgeht, da während des Bauens sich Inhalte aus dem Git-Repository heruntergeladen werden sollen.

Die Telemetriedaten werden an ein zentrales Konto bei Google Analytics und Yandex geschickt.

FOSS-Prinzipein

Hier ergibt sich teilweise ein Bruch mit den üblichen FOSS-Prinzipien. Bei FOSS gibt man seinen Quelltext nicht frei, damit andere in diesem lediglich Lesen können, sondern, damit andere ihn in ihre Systeme integrieren können. Nutze ich z. B. den NetworkManager, der einen Connectivity Check durchführt, um zu erkennen, ob ich in das Internet komme, wird als Endpunkt meist ein von meinem Distributor bereitgestellter Server genutzt. Der Distributor ist es auch, dem ich mein ultimatives Vertrauen schenken muss, da dieser oft vorkompilierte Pakete bereitstellt. Ist ein Build nicht reproduzierbar, kann ich als Anwender nicht zweifelsfrei feststellen, ob lediglich die Inhalte ausgeführt werden, die auch angegeben sind. Unter diesem Aspekt ist der Umstand, dass der Distributor durch oben genannte Connectivity Checks meine IP-Adresse erfahren kann, fast zu vernachlässigen.

Freie Open Source Programme sind somit nur Bausteine, die von einem Intermediär aufbereitet und zur Verfügung gestellt werden. Somit sollte es aus meiner Sicht faktisch keinen Durchgriff von FOSS-Maintainern auf die Endnutzer geben, sofern nicht ein triftiger Grund dafür spricht.

Ein solcher triftiger Grund wären in meinen Augen Crashdumps: stürzt ein Programm ab, bieten einige Programme die Möglichkeit an, hilfreiche Daten zur Crash-Ursache (Tracebacks, Umgebungsvariablen, etc.) an die Hersteller zu melden. Oftmals wird dem Nutzer hier die Wahl gelassen, ob er diese Informationen mit den Entwicklern teilen möchte.

FOSS-Geschäftsmodelle

Freilich ist es schwierig, Geschäftsmodelle bei einer solch schwierigen Beziehung zwischen Softwarehersteller und -anwender zu etablieren. Dabei ist die „letzte Meile“ zwischen Distributor/OEM und Endkunden am attraktivsten, da dort Support verkauft werden kann. Beste Beispiele sind hier Red Hat und SUSE. Red Hat wurde für 34 Milliarden US-Dollar an IBM verkauft und der in Deutschland ansässigen SUSE GmbH steht am 19. Mai ein mit 5,7 Milliarden Euro bewerteter Börsengang bevor. Das bloße Schaffen und (entgeltliche) Zurverfügungstellen von Softwarequelltext und den Binaries wird heutzutage immer unattraktiver.

Fazit

Was Audacity angeht, bin ich optimistisch. Am Ende kann der Anwender nur gewinnen: entweder wird die Software verbessert oder es bildet sich ein Fork (wie schon geschehen), der die Nutzerschaft übernimmt.

Audacity ist eine Software, die ihren Zweck erfüllt. In meinen Augen kein Anwärter für Designauszeichnungen, aber plattformübergreifend und funktional.

Trotzdem muss man schauen, wie sich Audacity nun weiterentwickelt. Meine Prognose ist, dass die nächste Änderung, die ähnliche Kritik hervorruft, ein Auto-Updater wie bei MuseScore sein wird. ;-)






E-Book Reader: Onyx BOOX Note3 im Einsatz

Lesen ist etwas, was ich generell viel zu wenig mache. Auf gedruckten Papier habe ich seit Ewigkeiten nicht mehr gelesen. Schon seit einigen Jahre besitze ich zwar einen Kindle Paperwhite von Amazon, aber die Nutzung variierte stark. Mal mehr, mal gar nicht.

Ein paar Gründe führten zu dem Umstand, dass ich das Kindle weniger genutzt habe:

Die letzten beiden Use-Cases sind speziellere Funktionen die ich nicht so häufig brauche. Als Autor und somit bei der Arbeit an der dritten Auflage meines Git Buches muss ich mehrfach vor der Drucklegung die Fahne Korrekturlesen. Ich weiß, dass beim Verlag sehr viel gedruckt wird, weil es sich einfach besser liest als auf einem Bildschirm und dann mit Stift Anmerkungen gemacht werden. Ich hatte das eine Weile lang auf einem Android Tablet gemacht, das war aber wegen des Displays eher auf der Kategorie „nicht so geil zum Lesen“. Notizen für Korrekturen waren auch eher umständlich und zudem besitze ich gar kein Tablet mehr.

Ich wollte also mehr Lesen und wollte auch die Möglichkeit haben, Notizen machen zu können, idealerweise mit Stift.

Zur Wahl standen letztendlich drei Geräte:

Alle drei Geräte sind E-Book-Reader mit guter Funktionalität um Notizen machen zu können. Das reine Lesen von Büchern ist ja eher der langweilige Part. Alle Geräte besitzen ein 10,3" großes Display. Die Größe war wichtig, damit das Machen von Notizen auf einem nicht ganz so kleinem Gerät erfolgen muss. Ich hatte zwar Angst, dass es zu groß sein könnte, aber das war dann doch passend.

Gekauft habe ich letztendlich das Onyx BOOX Note 3. Und hab mich im Wesentlichen gegen ein reMarkable entschieden, was die eher bekanntere Marke ist. Meine Gründe sind folgende:

Der Preis war natürlich nicht ganz so klein, aber man gönnt sich ja sonst nichts.

Grundsätzlich hat sich der Kauf gelohnt, es tut genau das, was es soll und es kommen auch Updates mit weiteren Funktionen. Die Notiz-Funktion habe ich nicht nur für die Korrekturen an meinem Buch genutzt, sondern auch für generelle Notizen, um ablenkungsfrei Nachdenken zu können. Die App dafür hat sehr viele Funktionen, wovon ich für meinen Zweck nicht so viel brauche.

Diejenigen die sich für richtig tiefe Reviews für solche Geräte interessiert, denen kann ich den YouTube-Kanal My Deep Guide empfehlen, wo der Herr die verschiedensten E-Book-Reader miteinander vergleicht. Es gibt einen sehr guten Eindruck was die Geräte können und in welchen Aspekten die Geräte besser als die anderen sind.

Die Anzahl an Android Apps hab ich gering gehalten. Über den F-Droid Store habe ich lediglich einen anderen Browser und den Nextcloud-Client für Datentransfers installiert und das klappt wunderbar.

Ein Use-Case den ich beim Kauf noch nicht im Blick hatte, ist, dass ich über meinen Arbeitgeber Zugang zur O’Reilly Learning Platform bekommen habe. Da gibt es nicht nur Bücher zu lesen, sondern auch Video-Kurse sind dort enthalten. Und das sind nicht nur Bücher von O’Reilly, sondern auch deutsche Verlage wie dpunkt oder mitp sind vertreten, sodass ich da auch mein Buch entdeckt habe. Die Inhalte lassen sich entweder im Browser lesen oder über die eigene App, ansonsten bekommt man die Daten da nicht so einfach raus, da es quasi eher dem Netflix-Modell entspricht. Die App konnte ich mir also auf mein E-Book-Reader geladen und konnte so schon einige Bücher lesen, die ich auf jeden Fall nicht im Browser am Bildschirm gelesen hätte. Vertraut mir, ich habs versucht…

tl;dr: Onyx BOOX Note 3 für relativ viel Geld gekauft. Ich lese jetzt deutlich mehr. Es deckt meine Use-Cases gut ab. Es nervt nicht. Notizen machen per Stift fühlt sich erstaunlich „echt“ an. Gerne wieder.






openSUSE geht auch ohne YaST

OpenSUSE und YaST sind in vielen Artikeln und Meinungsäußerungen untrennbar miteinander verbunden. Man braucht aber kein YaST und kann es sogar komplett deinstallieren.

OpenSUSE ist meine präferierte Distribution. Das hat vermutlich viel mit Gewohnheit zu tun, aber auch damit, dass Leap oder Tumbleweed meistens für meine Einsatzzwecke reichen. Momentan bin ich mit Tumbleweed unterwegs, da meine Hardware durch den alten Leap-Kernel nicht unterstützt wird. Eigentlich hatte ich vor, schnellstmöglich wieder auf eine LTS zu wechseln, aber daraus wird wohl nichts werden.

OpenSUSE gilt bei seinen Kritikern immer als fett und behäbig. Diese Ausdrücke sprechen für ein Gefühl, denn im Grunde genommen unterscheiden sich die Speicherplatzbedarfe der meisten Linux-Distributionen kaum und vieles hängt von der installierten Software ab. Zypper ist auf der Kommandozeile zudem viel schneller als beispielsweise die behäbigen Routinen von APT.

Nur YaST ist wirklich langsam. Das ist auch der Grund, weshalb ich so gut wie nie mit YaST arbeite. Man muss auch schon sehr lange nicht mehr zwingend irgendetwas in YaST konfigurieren, weil alle Einstellungen in den üblichen Konfigurationsdateien geschrieben werden.

Puristen stören sich zudem oft an den vielen doppelten Funktionen. Drucker kann man z. B. in den Einstellungen von KDE/GNOME konfigurieren und in YaST.

Das Schöne ist: Bei openSUSE hat man aber nicht nur die Freiheit YaST nicht zu nutzen, man kann es auch komplett deinstallieren. Man setzt bei openSUSE nämlich keine unnötigen harten Abhängigkeiten (man kann bei der GNOME-Variante z. B. auch Nautilus oder das GNOME Terminal entfernen ohne die Kern-Metapakete zu brechen) und ermöglicht so wirklich schlanke System. Voraussetzung für den schlanken Betrieb ist bei openSUSE natürlich, dass man die automatische Installation empfohlener Abhängigkeiten deaktiviert hat.

Kleiner Exkurs: Hier darf man sich als Anwender nicht täuschen lassen von vermeintlich kleinteiliger Paketierung oder einem wie auch immer gearteten Ruf in der Community. Das ist ein Irrtum, dem schon viele aufgesessen sind. Debian ist ein Beispiel für ein pseudo-schlankes System, das durch die Unterteilung in viele Subpakete und eine systematische Benennung selbiger schlanke Strukturen vorgaukelt. Das Gleiche mit dem vermeintlichen Ruf als schlankes System. Hier hat aus irgendeinem Grund Arch Linux einen guten Ruf. Dabei sind dort Abhängigkeiten oft viel zu großzügig gesetzt. Ein gutes Negativbeispiel ist bei Arch Linux Digikam.

Mit einem beherzigten Befehl auf der Kommandozeile kann man alle YaST Module entfernen. Die Liste sollte man vorab prüfen. Der Befehl entfernt die Module und die Pattern-Metapakete.

# zypper rm yast*
# zypper rm libyui*

Danach hat man ein YaST-freies System und kann entweder mit der Kommandozeile arbeiten oder die grafischen Einstellungsmöglichkeiten der jeweiligen Desktopumgebung nutzen.

Der Artikel openSUSE geht auch ohne YaST erschien zuerst auf [Mer]Curius






Schnitzeljagd für Netzwerkprobleme

Heute bin ich auf eine interessante Webseite gestoßen: https://mysteries.wizardzines.com/. Hier sind momentan vier „Fälle“ verfügbar, die sich allesamt mit typischen oder weniger bekannten Netzwerkproblemen beschäftigen. Das wären:

Ich habe mir die Puzzles heute angeschaut und bin begeistert, weil es Netzwerkthemen auf eine Art und Weise abseits von Lehrbüchern und Q&A-Seiten einem näher bringt.

Man wird vor ein Problem gestellt, das es zu lösen gilt. Dabei stehen einem verschiedene Mittel zur Verfügung, die interaktiv aufgerufen werden können. Das ganze Spiel ist geführt gestaltet, sodass man nicht alleine gelassen wird und man gleichzeitig verschiedene Werkzeuge kennenlernt, die zur Problemlösung herangezogen werden können. An einigen Stellen wird man selber nach Problemlösungen, Kommandozeilenprogrammaufrufen (strace, tcpdump, ...) gefragt, die allerdings in vielen Fällen nur informativ sind und keinen großen Einfluss auf das Spiel haben.

Wie so oft führen viele Wege nach Rom, so auch bei den hier angesprochenen Fällen. An vielen Stellen ist Zusatzwissen zu finden, das über den Hintergrund aufklärt. Am Abschluss eines jeden Falls wird die Ursache erläutert.

Ich werde nicht weiter die konkreten Fälle spoilern, sie sind auf jeden Fall ganz nett. Besonders in der Netzwerkwelt ist es schwierig, zu debuggen, weil es keine klassische statische Analyse wie aus der Softwareentwicklung gibt. Gerade erst habe ich wieder einen Fall gehabt, bei dem ein Port an einem VLAN-fähigen Switch konfiguriert werden sollte. Access Port konfigurieren reichte scheinbar nicht aus, denn seltsamerweise kam nur ein Teil der Pakete durch. Die Lösung war, dass noch die PVID für den Port konfiguriert werden muss. Das Debugging wird dahingehend erschwert, dass Dinge gerne mal einfach „nicht funktionieren“ und keine Fehler werfen. Um Probleme zu lösen ist es wichtig, Muster zu erkennen und diese zu bewerten. Und genau darauf zielen die Mysteries ab.

Aus diesem Grund ist es wichtig, immer in der Übung zu bleiben, und da kann ich mir solche Spiele gut als Lernwerkzeug vorstellen, auch, wenn sie nicht aktiv auf einem System arbeiten.

Der Source für das Projekt ist auf GitHub verfügbar.