Darknight Coffee Netzwerk

Carrabelloy ' Meine Hobbys sind so vielseitig

Schlagwort: software

  • AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

    AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

    Wer heute behauptet, AGI sei da, muss zuerst erklären, was mit AGI gemeint ist. Geht es um breite Problemlösefähigkeit, um Leistungen auf menschlichem Niveau, um autonome Zielverfolgung oder schlicht um ein Modell, das in vielen Tests beeindruckt? Ohne diese Trennung wird aus einer technischen Debatte ein Glaubenskampf. Die einen verkaufen Produktreife, die anderen diskutieren Bewusstsein, und am Ende redet niemand über dieselbe Sache.

    Mein Gegenpool richtet sich deshalb gegen zwei bequeme Lager zugleich: gegen den Hype, der aus jeder starken Demonstration einen historischen Wendepunkt macht, und gegen die Blockade, die jede neue Fähigkeit reflexhaft als Täuschung oder Gefahr abtut. Beides nimmt uns die politische Gestaltung aus der Hand.

    Ein Benchmark ist kein Thron

    Die Studie „Levels of AGI“ schlägt vor, Fähigkeiten nach Leistungsniveau, Breite und Autonomie zu unterscheiden. Das ist brauchbarer als ein binäres Etikett. Ein System kann in einzelnen Bereichen übermenschlich sein und bei alltäglichen Aufgaben scheitern. Es kann Texte, Code oder Bilder erzeugen und dennoch keine belastbare Verantwortung für die Folgen übernehmen.

    Auch METRs Forschung zu langen Aufgabenhorizonten misst eine konkrete Fähigkeit unter definierten Bedingungen. Solche Messungen sind wichtig. Sie beweisen aber weder Bewusstsein noch allgemeine Verlässlichkeit und schon gar nicht, dass ein System in einer realen Organisation unbeaufsichtigt handeln sollte.

    Im Serveralltag ist der Unterschied leicht zu sehen. Ein Modell kann eine plausible Nginx-Konfiguration erzeugen. Ob sie zum vorhandenen TLS-Setup, zu Weiterleitungen und zu den tatsächlichen Diensten passt, zeigt erst der Test. Ebenso kann ein Assistent einen Synapse-Fehler erklären, aber einen falschen Homeserver, eine andere Paketversion oder einen unzutreffenden Installationsweg voraussetzen.

    Ein beeindruckendes Ergebnis verdient Anerkennung. Es verdient nicht automatisch Root-Rechte.

    Capability ist noch keine Verantwortung

    Starke Fähigkeiten schaffen keine Haftung. Zwischen Können und verantwortlichem Einsatz liegen Zuständigkeiten, minimale Rechte, Protokolle, Verifikation und ein Rückweg. Genau darauf zielt auch das NIST AI Risk Management Framework mit seinen Bereichen Govern, Map, Measure und Manage.

    Ein Agent mit Schreibzugriff auf eine WordPress-Instanz kann einen fertigen Artikel veröffentlichen. Daraus folgt nicht, dass er ohne eindeutige Freigabe veröffentlichen sollte. Ein Werkzeug mit Zugriff auf Matrix-Tokens kann Räume verwalten. Daraus folgt nicht, dass es alle Tokens sehen oder dauerhaft behalten muss.

    Der vernünftige Weg ist unspektakulär:

    • Aufgaben klar begrenzen;
    • nur notwendige Rechte vergeben;
    • Tokens trennen, befristen und widerrufbar halten;
    • Ergebnisse vor hoher Wirkung vollständig prüfen;
    • vor Änderungen Backup und Rollback festlegen;
    • öffentliche Aktionen an eine eindeutige Freigabe binden.

    Capability ohne Governance ist kein Fortschritt, sondern ein ungesicherter Beschleuniger.

    Drei Lager und ihre blinden Flecken

    Das Rendite-Lager will schnell skalieren und Kosten externalisieren. Es behandelt Beschäftigte, Daten, Energie und gesellschaftliche Risiken als nachgelagerte Probleme. Das Neugier-Lager erkennt reale Möglichkeiten, unterschätzt aber leicht, wie aus einem Experiment ein dauerhafter Prozess mit Zugängen, Abhängigkeiten und Haftungsfragen wird. Das Moralblock-Lager sieht berechtigte Gefahren, kann jedoch Entwicklung und eigenes Wissen so stark bremsen, dass am Ende wieder einige wenige Konzerne die Technik kontrollieren.

    Eine souveräne Position nimmt von allen drei Seiten etwas ernst: die Innovationskraft, die Notwendigkeit von Grenzen und die Frage, wer Kosten und Nutzen trägt. Sie verweigert sich aber ihren Absolutheiten.

    Für eine kleine Community bedeutet das: Automatisierung darf Arbeit erleichtern, aber sie darf das Betreiberwissen nicht auffressen. Wenn ein Assistent jede Konfiguration erzeugt und nur noch ein Senior blind bestätigt, lernt der Nachwuchs weder DNS noch TLS noch Logauswertung. Wenn Moderation vollständig an Klassifikatoren ausgelagert wird, verliert die Community die Fähigkeit, Regeln zu begründen und Konflikte selbst zu bearbeiten.

    Physical AI: Wenn ein Fehler Gewicht bekommt

    Bei Physical AI verlässt der Fehler den Bildschirm. Ein Haushaltsroboter, ein Pflegesystem oder eine autonome Maschine bewegt Masse durch reale Räume. Eine falsche Klassifikation kann dann nicht nur einen unpassenden Text erzeugen, sondern eine Person verletzen, Eigentum beschädigen oder sensible Situationen aufzeichnen.

    Damit verschmelzen Datenschutz, Produktsicherheit und Haftung. Ein System muss nicht bewusst sein, um gefährlich oder nützlich zu handeln. Die Bewusstseinsfrage ist philosophisch interessant; für den Betrieb sind Kräfte, Sensorgrenzen, Abschaltmöglichkeiten, Protokolle und Verantwortlichkeiten unmittelbarer.

    Zwei Prüfungen gehören deshalb zusammen. Technisch muss geklärt werden, welche Zustände, Geschwindigkeiten und Kräfte erlaubt sind und wie ein sicherer Stopp funktioniert. Sozial muss geklärt werden, wer Daten sehen darf, wer Entscheidungen überprüft und wer für Schäden einsteht.

    Sobald KI einen Körper bekommt, bekommt auch ihr Fehler Masse, Geschwindigkeit und Reichweite.

    Europa und Silicon Valley: Die falsche Wahl

    Europa wird gern vor eine falsche Alternative gestellt: entweder schnelles Silicon-Valley-Tempo oder Grundrechte und Regulierung. Tatsächlich braucht Europa beides – Entwicklungskraft und demokratische Kontrolle. Regeln ohne eigene Infrastruktur machen abhängig. Infrastruktur ohne Rechte reproduziert nur das Machtmodell anderer Anbieter unter europäischer Flagge.

    Der AI Act folgt einem risikobasierten Ansatz. Das ist sinnvoll, wenn Regeln nicht beim Papier enden. Kleine Betreiber und Open-Source-Projekte brauchen verständliche Anforderungen, zugängliche Prüfwerkzeuge und klare Abgrenzungen. Große Anbieter dürfen Regulierung nicht als Markteintrittsbarriere benutzen, die sie selbst mit Rechtsabteilungen überwinden, während kleinere Alternativen verschwinden.

    Digitale Souveränität entsteht außerdem nicht durch den Firmensitz allein. Entscheidend sind offene Standards, exportierbare Daten, dokumentierte Schnittstellen, kontrollierbare Schlüssel und eine realistische Wechselmöglichkeit. Ein europäisches Produkt mit geschlossenem Format kann unfreier sein als ein transparent betriebener offener Dienst.

    Öffentliche Beschaffung könnte hier Macht verschieben: nicht nur Funktionen einkaufen, sondern Portabilität, Reproduzierbarkeit, Sicherheitspflege und Exit-Fähigkeit verlangen. Wer öffentliche Infrastruktur liefert, muss erklären können, wie sie ohne ihn weiterbetrieben werden kann.

    Arbeit: Produktivität ist eine Verteilungsfrage

    Die Internationale Arbeitsorganisation unterscheidet bei generativer KI zwischen Exposition, Transformation und vollständiger Ersetzung. Diese Unterscheidung ist zentral. Ein Beruf besteht aus vielen Tätigkeiten. Einige lassen sich automatisieren, andere verändern sich, wieder andere gewinnen an Bedeutung.

    Der gesellschaftliche Ausgang ist nicht technisch vorbestimmt. Wenn Produktivität steigt, können Gewinne wachsen, mehr Leistungen produziert oder Arbeitszeiten verkürzt werden. Welche Mischung entsteht, ist eine Macht- und Verteilungsfrage.

    Frühere Automatisierungswellen haben neue Berufe geschaffen. Das ist kein Trost für Menschen, deren Einkommen heute wegfällt und denen morgen der Zugang zu Qualifizierung fehlt. Übergänge brauchen Zeit, soziale Sicherung und Mitbestimmung. Sonst werden Gewinne privatisiert und Anpassungskosten auf Beschäftigte und öffentliche Haushalte verschoben.

    Auch Bildung darf nicht auf Bedienkompetenz schrumpfen. Wer nur noch Prompts formuliert, ohne Quellen, Code, Logs oder Argumente beurteilen zu können, wird vom Werkzeug abhängig. Der bessere Lernpfad lautet: Vorschlag erklären lassen, im Testsystem ausführen, Ergebnis prüfen, Fehler begründen und erst dann übernehmen.

    Automatisierung verteilt nicht von selbst Wohlstand. Sie verteilt zuerst Macht.

    Sieben Leitlinien für souveräne KI

    Aus der abstrakten AGI-Debatte lässt sich ein konkreter Handlungsrahmen ableiten:

    1. Begriffe vor Behauptungen: Wer AGI sagt, benennt Breite, Leistungsniveau und Autonomie.
    2. Aufgaben statt Magie: Jeder Einsatz erhält klare Ein- und Ausgaben, Grenzen und Erfolgskriterien.
    3. Minimale Rechte: Kein Agent bekommt mehr Zugriff, als die konkrete Aufgabe verlangt.
    4. Verifikation: Quellen werden geöffnet, Konfigurationen getestet und risikoreiche Ergebnisse vollständig geprüft.
    5. Rückweg: Vor Änderungen existieren Sicherung, Rollback und eine verantwortliche Person.
    6. Offene Alternativen: Datenexport, offene Protokolle und dokumentierte Schnittstellen werden vor dem Lock-in geplant.
    7. Gegenpool: Zu großen Behauptungen gehört eine belastbare Gegenposition; Tatsache, Quelle, Analyse und Meinung bleiben getrennt.

    Diese Regeln verhindern weder Innovation noch Fehler. Sie machen Entscheidungen sichtbar und korrigierbar. Souveränität ist kein Alles-oder-nichts-Zustand. Sie wächst durch eigene Domains, getrennte Konten, kontrollierte Schlüssel, exportierbare Daten, dokumentierte Konfigurationen und getestete Backups.

    Vielleicht werden wir später sagen, eine Form kompetenter AGI sei 2025 oder 2026 bereits vorhanden gewesen. Vielleicht werden wir feststellen, dass das Schlagwort mehr verdeckt als erklärt hat. Für die heutige Praxis ist entscheidend: Wir haben leistungsfähige, fehlerhafte Systeme, die Arbeit, Infrastruktur und Macht verändern.

    Wir brauchen deshalb keine neue Religion – weder eine des Heils noch eine des Untergangs. Wir brauchen Betreiberwissen, demokratische Regeln, freie Alternativen und den Mut, einer beeindruckenden Maschine nicht blind die Schlüssel zu geben.

    Quellen

    1. Meredith Ringel Morris et al., „Levels of AGI: Operationalizing Progress on the Path to AGI“:
      https://arxiv.org/abs/2311.02462
    2. METR, „Measuring AI Ability to Complete Long Tasks“:
      https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
    3. NIST, „Artificial Intelligence Risk Management Framework“:
      https://www.nist.gov/itl/ai-risk-management-framework
    4. Europäische Kommission, „Regulatory framework for AI“:
      https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
    5. Internationale Arbeitsorganisation, „Generative AI and Jobs: A Refined Global Index of Occupational Exposure“:
      https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
    Podcast: https://podcast.darknight-coffee.org/pages/startseite
    Blog: https://carrabelloy.darknight-coffee.org/blog/
    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Das Fediverse patcht sich nicht selbst: Souveränität braucht ein Wartungsfenster

    Das Fediverse patcht sich nicht selbst: Souveränität braucht ein Wartungsfenster

    Ein eigener Mastodon-Server ist ein starkes Stück digitaler Handlungsfähigkeit. Die Domain bleibt unter eigener Kontrolle, Regeln können in der Community entstehen, und ein Plattformkonzern kann den Kommunikationsraum nicht per Geschäftsentscheidung abschalten. Doch dann kommt die Sicherheitsmeldung: Mastodon aktualisieren, FFmpeg prüfen, Backup anlegen.

    Genau hier endet die romantische Erzählung und beginnt digitale Souveränität in der Praxis. Freiheit besteht nicht nur darin, Software installieren zu dürfen. Sie besteht darin, Abhängigkeiten zu erkennen, einen sicheren Patchpfad zu wählen, einen Rückweg vorzubereiten und nach dem Neustart den vollständigen Dienst zu prüfen.

    Der aktuelle Anlass: Drei Patchstände und eine Frist

    Das Mastodon-Projekt hat am 17. Juli 2026 die Versionen 4.6.3, 4.5.13 und 4.4.20 als aktuelle Stände der unterstützten Zweige genannt und allen Administratoren ein Update empfohlen. Gleichzeitig endet die Unterstützung für Mastodon 4.4 am 17. Dezember 2026. Versionen vor 4.4 sind laut Sicherheitsrichtlinie bereits nicht mehr unterstützt.

    Damit entstehen zwei Aufgaben, die nicht vermischt werden dürfen. Wer in einem unterstützten Zweig arbeitet, muss kurzfristig den korrekten Patchstand erreichen. Wer noch Mastodon 4.4 betreibt, braucht zusätzlich einen geplanten Weg auf einen neueren Zweig, bevor die Sicherheitsunterstützung endet.

    Das ist mehr als Versionspflege. Die dokumentierten Mindestanforderungen steigen zwischen 4.4 und 4.6: Ruby von 3.2 auf 3.3, PostgreSQL von 13 auf 14, Redis von 6.2 auf 7 und Node von 20 auf 22. Diese Tabelle sagt nicht, dass jedes System alle Komponenten gleichzeitig austauschen muss. Sie zeigt aber, warum ein Minor-Upgrade kein blindes Ersetzen eines Mastodon-Pakets ist.

    Die Lücke sitzt in FFmpeg, nicht in der Timeline

    Teil der Sicherheitslage ist CVE-2026-8461. Nach dem Datensatz der National Vulnerability Database betrifft die Schwachstelle den MagicYUV-Decoder in FFmpegs libavcodec. Beschrieben ist ein Out-of-bounds-Write, der einen Denial-of-Service und unter bestimmten Bedingungen die Ausführung fremden Codes ermöglichen kann.

    Zur belastbaren Einordnung gehören die Grenzen der Aussage. Die NVD führte den Fall beim Abruf am 21. Juli noch als „Awaiting Analysis“. Der veröffentlichte CVSS-v3.1-Wert 8,8 stammt aus einer Sekundärbewertung. Mastodon bezeichnet die Lücke in seinen Release Notes als kritisch und hat FFmpeg in den offiziellen Container-Images aktualisiert. Die ausgewerteten Quellen belegen jedoch keinen zuverlässig ausnutzbaren Angriffsweg über einen gewöhnlichen Mastodon-Medienupload.

    Warum betrifft FFmpeg überhaupt einen sozialen Server? Weil Mastodon hochgeladene Medien nicht nur speichert. Bilder und Videos werden analysiert und verarbeitet. Hinter der sichtbaren Timeline arbeitet deshalb eine technische Kette aus Mastodon, Ruby, PostgreSQL, Redis, Node, Webserver, Mail, Speicher und Multimedia-Bibliotheken. Wer nur die Versionsnummer der Webanwendung beobachtet, übersieht einen Teil dieser Lieferkette.

    Für Nutzer der offiziellen Mastodon-Container-Images hat das Projekt FFmpeg mit den genannten Releases aktualisiert. Bei einem systemweit installierten FFmpeg ist dagegen der Paketlieferant der Distribution zuständig. Debian, Ubuntu oder YunoHost können Sicherheitskorrekturen zurückportieren. Deshalb ist ein bloßer Vergleich mit einer Upstream-Versionsnummer kein verlässlicher Sicherheitscheck; Paket-Changelog und Security Tracker des tatsächlich eingesetzten Systems sind entscheidend.

    Patch und Migration sind zwei verschiedene Baustellen

    Ein Patch innerhalb des Zweigs 4.4 kann eine aktuelle Sicherheitskorrektur liefern. Er beseitigt aber nicht die Frist für den gesamten 4.4-Zweig. Wer bis kurz vor dem 17. Dezember wartet, bündelt mögliche Änderungen an Datenbank, Laufzeiten und Anwendung in einem hektischen Störfall.

    Die Mastodon-Dokumentation verlangt, die Hinweise aller übersprungenen Releases zu lesen. Einzelne Patchstände dürfen übersprungen werden; mindestens ein Release jedes Minor-Zweigs soll jedoch durchlaufen werden. Der Grund ist simpel: Zwischenstände können Datenbankmigrationen oder besondere Arbeitsschritte enthalten.

    Ein sauberer Migrationsplan beginnt daher mit einer Bestandsaufnahme:

    • Welcher Mastodon-Zweig und welcher Patchstand laufen tatsächlich?
    • Ist die Installation klassisch, containerisiert, über Kubernetes oder über eine Distribution beziehungsweise Plattform verwaltet?
    • Welche Versionen von PostgreSQL, Redis, Ruby, Node und FFmpeg sind eingebunden?
    • Welche Release-Hinweise gelten genau für diesen Weg?
    • Unter welchen Bedingungen wird das Update abgebrochen und zurückgerollt?

    Konkrete Universalbefehle wären hier unseriös. Ein Docker-Befehl gehört nicht auf eine YunoHost-Installation, und ein Git-Upgrade nicht auf ein distributionsverwaltetes Paket. Die Host- und Installationsart muss zuerst feststehen.

    Ein Datenbankdump ist noch kein vollständiges Backup

    Die Release Notes fordern vor dem Upgrade ein Datenbank-Backup. Die offizielle Backup-Dokumentation nennt zusätzlich die Anwendungsschlüssel, Nutzermedien und Redis.

    Diese Bestandteile haben unterschiedliche Folgen. Geht PostgreSQL verloren, verschwinden Accounts, Beiträge und Follower-Beziehungen. Fehlen die Anwendungsschlüssel, können Nutzer abgemeldet, Zwei-Faktor-Anmeldungen unbrauchbar und Web-Push-Abonnements zerstört werden. Fehlt die Medienablage, bleiben möglicherweise Texte erhalten, während Bilder und Videos verschwinden. Mastodon empfiehlt deshalb auch Offsite-Kopien.

    Ein realer Betriebsfehler sieht oft harmlos aus: Der nächtliche Datenbankdump meldet Erfolg, aber die Schlüssel liegen nur auf dem produktiven Server. Oder Datenbank und Medien werden auf denselben Datenträger gesichert, dessen Ausfall beide Kopien trifft. In beiden Fällen existiert formal ein Backup, praktisch aber kein vollständiger Rückweg.

    Technische Bewertung: Ein vorhandener Dump beweist noch keine Wiederherstellbarkeit. Erst ein dokumentierter Restore-Test zeigt, ob Datenbank, Schlüssel, Medien, Redis und Konfiguration gemeinsam wieder anlaufen. Diese Schlussfolgerung ist eine betriebliche Bewertung; sie wird nicht als wörtliche Zusage der Mastodon-Dokumentation ausgegeben.

    Der Neustart ist der Anfang der Prüfung

    Für eine klassische Installation von Mastodon 4.6.3 nennt das Projekt die erneute Asset-Kompilierung und den Neustart der Mastodon-Prozesse. Bei Docker sollen alle Mastodon-Prozesse neu gestartet werden. Die allgemeine Upgrade-Dokumentation weist darauf hin, dass ein Neustart des Streaming-Dienstes verbundene Clients trennt und durch Wiederverbindungen zusätzliche Last auslösen kann.

    Ein grüner Prozesszustand reicht deshalb nicht. Eine belastbare Abnahme prüft reale Nutzerwege:

    • Login und Zwei-Faktor-Authentisierung;
    • Textbeitrag und Medienupload;
    • Hintergrundjobs und Mailzustellung;
    • eingehende und ausgehende Föderation;
    • Last, Fehlerrate und Warteschlangen nach dem Neustart.

    Nginx, DNS und TLS können vollständig korrekt sein, während Medienjobs hängen. Die lokale Timeline kann funktionieren, während Föderation zu einer zweiten Instanz ausfällt. Ein Testbeitrag ohne Bild entdeckt keinen Fehler in der Medienverarbeitung. Monitoring muss deshalb nicht nur Prozesse, sondern den Zweck des Dienstes abbilden.

    Mastodon 4.6 bringt auch organisatorische Arbeit

    Mastodon 4.6 enthält neue Funktionen wie Collections, E-Mail-Abonnements, eine alternative Landingpage für institutionelle Server, Rollenpflichten für Zwei-Faktor-Authentisierung und Verbesserungen der Barrierefreiheit. Das sind keine Sicherheitsargumente für das Update. Sie berühren aber Kosten, Moderation und Datenschutz.

    E-Mail-Abonnements werden nicht automatisch für jedes Konto freigegeben. Administratoren können sie nach Rollen steuern, weil Newsletter-Versand Kosten erzeugen kann. Eine Community muss also entscheiden, wer senden darf, welches Volumen tragbar ist und wie Missbrauch behandelt wird.

    Collections respektieren laut Mastodon vorhandene Discovery-Einstellungen, informieren aufgenommene Personen und erlauben ihnen, das eigene Profil zu entfernen. Trotzdem braucht eine Instanz Regeln dafür, welche Sammlungen ihrem Zweck entsprechen. Die alternative Landingpage kann lokale Informationen stärker hervorheben, verlangt aber redaktionelle Pflege.

    Der technische Erfolg eines Upgrades ist somit nur eine Hälfte. Die andere lautet: Sind neue Funktionen bewusst konfiguriert, erklärt und organisatorisch getragen?

    Bewertung: Wartung ist der sichtbare Preis der Freiheit

    Meine Bewertung: Regelmäßige Sicherheitsupdates sind kein Gegenbeweis zur digitalen Souveränität. Sie zeigen ihren realen Preis.

    Zentrale Plattformen nehmen Betreibern die sichtbare Wartungsarbeit ab. Dafür behalten sie Kontrolle über Daten, Reichweite, Regeln und Konten. Selbsthosting dreht dieses Verhältnis um: Die Kontrolle kann lokal bleiben, aber Zuständigkeit und Kosten werden sichtbar. Das ist anstrengender als ein fremdes Konto. Es schafft jedoch die Möglichkeit, Code, Abhängigkeiten, Paketquellen und Migrationswege zu prüfen und den Kommunikationsraum notfalls zu übertragen.

    Das Gegenargument bleibt ernst: Ein ungepflegter eigener Server ist kein Gewinn. Ehrenamtliche Teams können nicht beliebig viele Sicherheitsmeldungen, Migrationen und Moderationsaufgaben stemmen. Genau deshalb müssen Wartungszeit, Dokumentation und Infrastruktur finanziert werden. „Open Source ist kostenlos“ ist die falsche Erzählung. Open Source macht Abhängigkeiten prüfbar und Wechsel möglich – wenn Betrieb und Recovery gemeinsam getragen werden.

    Fazit

    Der aktuelle Mastodon-Hinweis ist ein konkreter Handlungsanlass, aber kein Grund für blinden Aktionismus. Der richtige Ablauf lautet: tatsächlichen Stand feststellen, Installationsweg identifizieren, zuständige Paketquelle prüfen, vollständiges Backup erzeugen, Restore-Fähigkeit nachweisen, Release-Hinweise lesen und anschließend jeden Schritt verifizieren.

    Für Mastodon 4.4 kommt ein klarer Planungshorizont hinzu: Der Support endet am 17. Dezember 2026. Wer die Migration jetzt strukturiert, behält die Kontrolle. Wer sie verdrängt, lässt aus technischer Schuld einen Störfall werden.

    Die konkrete Version, Installationsart, FFmpeg-Paketlage und Backup-Konfiguration von treff.darknight-coffee.eu wurden für diesen Entwurf nicht geprüft. Es wird daher keine konkrete Verwundbarkeit behauptet.

    Digitale Souveränität beginnt nicht beim Download. Sie zeigt sich im Wartungsfenster – wenn eine Community ihren Server patchen, prüfen und ohne fremde Erlaubnis wieder hochziehen kann.

    Quellen

    1. Mastodon Blog, „Trunk & Tidbits, June 2026“, 17. Juli 2026:
      https://blog.joinmastodon.org/2026/07/trunk-tidbits-june-2026/
    2. Mastodon Releases 4.6.3, 4.6.2, 4.5.13 und 4.4.20:
      https://github.com/mastodon/mastodon/releases/tag/v4.6.3
      https://github.com/mastodon/mastodon/releases/tag/v4.6.2
      https://github.com/mastodon/mastodon/releases/tag/v4.5.13
      https://github.com/mastodon/mastodon/releases/tag/v4.4.20
    3. Mastodon, Sicherheitsrichtlinie:
      https://github.com/mastodon/mastodon/blob/main/SECURITY.md
    4. Mastodon-Dokumentation, „Upgrading to a new release“:
      https://docs.joinmastodon.org/admin/upgrading/
    5. Mastodon-Dokumentation, „Backing up your server“:
      https://docs.joinmastodon.org/admin/backups/
    6. Mastodon Blog, „Mastodon 4.6“:
      https://blog.joinmastodon.org/2026/06/mastodon-4.6/
    7. FFmpeg Security:
      https://ffmpeg.org/security.html
    8. NIST NVD, CVE-2026-8461, beim Abruf Status „Awaiting Analysis“:
      https://nvd.nist.gov/vuln/detail/CVE-2026-8461

    CTA

    Wie organisiert ihr Updates und echte Restore-Tests? Diskussion:
    https://treff.darknight-coffee.eu/@carrabelloy

    Podcast:
    https://podcast.darknight-coffee.org/pages/startseite

    Blog:
    https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Lebensmittel retten – aber nur mit App?

    Lebensmittel retten – aber nur mit App?

    Wie Too Good To Go digitale Ausgrenzung normalisiert
    Lebensmittel retten klingt nach Fortschritt.
    Nach Nachhaltigkeit.
    Nach Verantwortung.

    Doch was passiert, wenn genau dieser Anspruch an eine Bedingung geknüpft wird, die längst nicht alle erfüllen wollen – oder können?

    Die Antwort liefert Too Good To Go selbst:
    Ohne App keine Teilnahme. Keine Ausnahme. Keine Alternative.

    Die App-Pflicht als Eintrittskarte zum Essen

    Nach mehrfacher Nachfrage hat Too Good To Go unmissverständlich klargestellt:

    Die Reservierung und Abholung von Lebensmitteln ist ausschließlich über die App möglich.
    Eine Web-Oberfläche existiert nicht und ist nicht vorgesehen.

    Das bedeutet im Klartext:
    Wer keine App nutzt, bleibt draußen.

    Egal ob aus Datenschutzgründen, technischer Überzeugung, aus Prinzip digitaler Selbstbestimmung oder schlicht, weil man kein kompatibles Gerät besitzt.

    Das ist keine technische Notwendigkeit.
    Das ist eine bewusste Entscheidung.

    Digitale Selbstbestimmung ist kein Luxusproblem

    Ich nutze keine Apps.
    Nicht aus Trotz, sondern aus Überzeugung.

    Meine Smartphones sind bewusst ohne proprietäre App-Ökosysteme betrieben. Open Source, selbst geflasht, kontrollierbar. Diese Entscheidung ist legitim – und sie betrifft längst nicht nur „Technik-Nerds“, sondern immer mehr Menschen, die sich mit Datenschutz, Abhängigkeiten und digitaler Souveränität auseinandersetzen.

    Doch Too Good To Go sagt:
    Dann bekommst du keine Lebensmittel.

    Das ist digitale Ausgrenzung.

    Nachhaltigkeit darf nicht selektiv sein

    Wenn nachhaltige Projekte nur noch für jene zugänglich sind, die:

    ein modernes Smartphone besitzen,

    proprietäre Apps akzeptieren,

    Tracking und Abhängigkeiten hinnehmen,

    dann ist das keine soziale Nachhaltigkeit, sondern digitale Selektion.

    Besonders problematisch wird das, wenn man den größeren Kontext betrachtet:

    Tafeln arbeiten am Limit.

    Lebensmittelarmut nimmt zu.

    Gleichzeitig werden Zugänge verengt, statt erweitert.

    Ein Projekt, das vorgibt, Lebensmittel zu retten, sollte niemanden vom Zugang ausschließen, nur weil er oder sie nicht Teil einer App-Infrastruktur sein will.

    App-Zwang ist kein Naturgesetz

    Eine responsive Web-Oberfläche wäre technisch trivial:

    Reservieren

    Abholen

    Anzeigen
    alles problemlos im Browser möglich.

    Doch genau das wird verweigert.

    Warum?
    Weil Apps kontrollierbarer sind.
    Weil Datenflüsse sauberer zu lenken sind.
    Weil Nutzerbindung leichter funktioniert.

    Aber das ist ein Unternehmensinteresse, kein Gemeinwohl.

    Digitalministerium, EU-Wallets und der falsche Weg

    Parallel dazu wird politisch darüber diskutiert, Alltagsprozesse weiter zu digitalisieren:

    digitale Identitäten

    Wallets

    App-basierte Zugänge zu immer mehr Lebensbereichen

    Doch Deutschland ist nicht Skandinavien – und will es auch nicht flächendeckend sein. Es gibt hier keinen gesellschaftlichen Konsens, das komplette Leben an Apps zu koppeln.

    Wer diesen Weg dennoch erzwingt, verliert Menschen, statt sie mitzunehmen.

    Warum ich darüber öffentlich schreibe

    Ich habe Too Good To Go mehrfach sachlich kontaktiert.
    Ich habe Alternativen vorgeschlagen.
    Ich habe begründet, warum eine App-Pflicht problematisch ist.

    Die Antwort war eindeutig: Nein.

    Deshalb mache ich das öffentlich.

    Nicht, um zu „bashen“,
    sondern um zu zeigen, wohin wir steuern, wenn Nachhaltigkeit an technische Konformität gebunden wird.

    Lebensmittel retten darf kein Privileg für App-Nutzer sein.

    Haltung statt Hormon

    Digitalisierung ist kein Selbstzweck.
    Nachhaltigkeit kein Marketinglabel.
    Und soziale Verantwortung endet nicht beim App-Download.

    Wer wirklich retten will, muss Zugänge öffnen, nicht schließen.

  • Was bei Hetzner, DNS und YunoHost wirklich passiert ist

    Was bei Hetzner, DNS und YunoHost wirklich passiert ist

    In den letzten Tagen hatte ich massive Probleme mit meinem YunoHost-Server bei Hetzner.
    Das Admin-Panel war teilweise erreichbar, teilweise nicht. Zertifikate liefen aus, Firefox blockierte Zugriffe wegen HSTS, und Dienste wie Mastodon, WordPress, Matrix, Diaspora,Screensa verhielten sich instabil oder sehr träge. Oder waren nicht aufrufbar. Wie E-Mail-Verkehr.

    Das Entscheidende vorweg:
    Das Problem lag nicht bei YunHost, nicht bei Firefox und nicht bei meinem Server.
    Die Ursache ist die laufende DNS-Migration bei Hetzner.

    1. Die Ausgangslage

    Mein Setup:

    Hetzner VPS

    YunHost

    mehrere Domains (example.org, .eu, Subdomains wie srv, cloud, netz, treff, mastodon ,wp,dia,)

    automatische Let’s-Encrypt-Zertifikate

    DNS bisher über die alte Hetzner DNS-Konsole

    Hetzner hat angekündigt:

    Die alte DNS-Konsole (dns.hetzner.com) wird abgeschaltet.
    Bestehende Zonen müssen in die neue Hetzner Console migriert werden.

    👉 Klingt harmlos – ist es aber nicht, wenn man Server betreibt.

    2. Das sichtbare Problem (Symptome)

    Folgende Dinge traten gleichzeitig auf:

    Firefox zeigt bei https://example.org/yunhost/sso: dns dmg

    HSTS-Fehler

    keine Möglichkeit, eine Ausnahme hinzuzufügen

    Server YunHost meldet:

    „DNS records are different to this server’s IP“

    Zertifikate lassen sich nicht erneuern

    Mastodon:

    Föderation instabil

    Verbindungsprobleme

    dig zeigt:

    intern: 1000.0.0.1

    extern: andere IPs als erwartet

    👉 Klassisches Zeichen für inkonsistente DNS-Quellen.

    3. Warum das so kritisch ist (HSTS erklärt)

    example.org nutzt HTTP Strict Transport Security (HSTS).

    Das bedeutet:

    Browser dürfen nur HTTPS

    abgelaufene oder falsche Zertifikate = kompletter Zugriff gesperrt

    kein „Ich vertraue trotzdem“-Button

    💡 Das ist kein Bug – das ist Sicherheit.

    Wenn DNS → falsche IP
    dann Zertifikat → falsch
    dann Browser → blockiert

    Kette geschlossen. Ende.

    4. Der entscheidende Hinweis: Zwei DNS-Welten gleichzeitig

    Was wirklich passiert ist:

    Alte Hetzner DNS-Konsole existiert noch

    Neue Hetzner Console existiert schon

    Domains sind teilweise migriert

    Teilweise zeigen Records noch auf alte IPs

    Teilweise schon auf neue IPs

    Ergebnis:

    Je nach Resolver (Server intern, Cloudflare, ISP, Browser)
    bekommst du unterschiedliche Antworten.

    Das ist der Worst Case für:

    Zertifikate

    Mail

    Föderation (Mastodon und weitere Anwendungen)

    Admin-Portale

    5. Warum Hetzner-Support mir nicht helfen konnte

    Ich habe:

    ein Ticket eröffnet

    telefonisch nachgefragt

    Antwort (ehrlich & wichtig):

    Der aktuelle Telefonsupport ist nur für Hardware & Rechenzentrum zuständig.
    DNS-Migration = anderes Team.
    Konkrete Hilfe zur neuen DNS-Console: aktuell kaum möglich.

    👉 Das ist keine böse Absicht – die Migration läuft noch.

    6. Warum der „Workaround“ keine Lösung ist

    Ja, man kann:
    yunhost domain cert renew DOMAIN –no-checks

    Das funktioniert kurzfristig.

    ❌ Aber:

    DNS bleibt falsch

    Zertifikate brechen beim nächsten Renew

    Mail bleibt fehleranfällig

    Mastodon und weitere Programme bleiben instabil.

    Das ist Flickschusterei – keine Lösung.

    7. Die saubere Lösung (kein Workaround) ✅
    Schritt 1: Eine einzige DNS-Quelle

    👉 Entscheiden:

    Entweder neue Hetzner Console

    oder externer DNS (z. B. deSEC, Cloudflare)

    ❌ Nicht beides gleichzeitig

    Da bei mir Cloudflare genauso vorhanden ist, bin ich erst spät darauf gekommen.

    Schritt 2: Alle A / AAAA Records korrekt setzen

    Für jede Domain & Subdomain:

    A → 1000.200.100.10

    AAAA → 2e001:4a9:122:39001::3

    Keine alten IPs mehr (987.201.222.100, …259d::3).

    Schritt 3: Wildcards & Mail sauber nachziehen

    * A / AAAA setzen

    MX setzen

    SPF / DKIM / DMARC aktualisieren

    CAA für Let’s Encrypt setzen

    (YunHost sagt dir exakt, was fehlt – das ist Gold wert.)

    Schritt 4: Warten (leider ja)

    DNS braucht:

    Minuten bis Stunden

    manchmal 24–48 Stunden

    Erst danach:

    Zertifikate erneuern

    Dienste testen

    Mastodon stabilisieren

    8. Warum jetzt plötzlich wieder manches geht

    Du hast es selbst beobachtet:

    Zertifikat für example.org geht wieder

    Admin-Panel über ddd.example.org funktioniert

    Probleme treten nur über das Portal / SSO auf

    👉 Das bestätigt:
    DNS-Inkonsistenz, nicht Serverfehler.
    Per Terminal kommt man weiter partiell

    9. Fazit

    Das hier ist wichtig – für alle mit Servern:

    DNS-Migrationen sind kein Detail.
    Sie sind kritisch für alles darüber.

    YunoHost funktioniert korrekt.
    Firefox reagiert korrekt.
    HSTS schützt korrekt.

    Nur DNS muss einmal sauber, vollständig und einheitlich gemacht werden.
    Und danach sollte Ihr Server wieder sauber laufen.

  • Der Mythos vom unabhängigen Chaos Computer Club: Wenn kritisches Denken zum Feigenblatt verkommt

    Der Mythos vom unabhängigen Chaos Computer Club: Wenn kritisches Denken zum Feigenblatt verkommt

    **Der Mythos vom unabhängigen Chaos Computer Club: Wenn kritisches Denken zum Feigenblatt verkommt

    **Von „Carrabelloy“ – Stimme für digitale Souveränität und kritisches Denken**

    **Einleitung**
    Es gab eine Zeit, da war der Chaos Computer Club (CCC) das Sprachrohr für digitale Freiheit, Datenschutz und kritische Netzpolitik. Heute scheint vieles davon nur noch Fassade. In diesem Beitrag geht es nicht um bloße Polemik, sondern um klare Beobachtungen, dokumentierte Entwicklungen und die berechtigte Frage: **Wie viel Unabhängigkeit ist vom CCC eigentlich noch übrig?**

    —

    **1. Der CCC im politischen Drift: Von Unabhängigkeit kaum noch eine Spur**

    Der CCC war einst eine kritische Stimme gegen Machtmissbrauch – egal von welcher Seite. Heute wirkt vieles davon angepasst, glattgebügelt, vorauseilend konsensbereit.

    Ein Beispiel: Während Plattformen wie Mastodon als „dezentrale Hoffnungsträger“ gehandelt werden, bleibt die politische Einseitigkeit dieser Netzwerke unausgesprochen. Der linke Aktivismus dominiert, andere Perspektiven werden schnell als „toxisch“ ausgegrenzt oder blockiert. Wer also wirklich Meinungsvielfalt sucht, wird dort oft enttäuscht.

    **Fazit**: Eine kritische Institution, die nur noch eine Richtung toleriert, ist keine freie mehr.

    —

    **2. Datenschutz? Nur wenn er ins politische Bild passt**

    Der eigentliche Skandal liegt jedoch tiefer: Der CCC schweigt laut, wenn es um wirklich heikle Themen geht. Zum Beispiel die Nutzung von **Palantir-Software** durch deutsche Polizeibehörden in mittlerweile fünf Bundesländern (Hessen, NRW, Bayern, Hamburg und Bremen).

    Palantir steht seit Jahren wegen seiner engen Verbindungen zum US-Militär und Geheimdiensten wie der NSA in der Kritik. Die Software ermöglicht umfassende Datenanalyse – mit weitreichenden Überwachungsmöglichkeiten. Doch vom CCC? Kaum ein Wort.

    Dabei wäre genau das ihr Thema: Machtmissbrauch durch digitale Technologien, intransparent eingeführte Überwachungssysteme – und das alles auf europäischem Boden.

    **Fakt**: Die Software „Gotham“ von Palantir wird ohne öffentliche Ausschreibungen und mit geheim gehaltenen Verträgen in den Landesbehörden eingesetzt. Datenschützer schlagen Alarm – der CCC schweigt.

    —

    **3. Die öffentlich-rechtliche Framing-Maschine**

    Wer sich zu diesen Themen Informationen bei öffentlich-rechtlichen Medien wie **ARD Mediathek** oder **ARDAudiothek** sucht, wird schnell enttäuscht. Wenn über digitale Themen berichtet wird, geschieht das oft einseitig und mit starker ideologischer Rahmung (Framing).

    Beispiel: In einem ARD-Beitrag zum Thema Datenschutz in sozialen Netzwerken wurde Mastodon lobend hervorgehoben – Kritiker kamen nicht zu Wort. Die Palantir-Problematik wurde nicht einmal erwähnt.

    **Frage**: Wo bleibt der journalistische Anspruch auf Vollständigkeit? Wo ist der Wille zur echten Kontroverse?

    —

    **4. CCC als Feigenblatt? Der Verlust des digitalen Gewissens**

    Statt klarer Kante sehen wir heute beim CCC oft weichgespülte Kompromissrhetorik. Kritische Stimmen innerhalb des Clubs wurden leiser oder gingen ganz. Der einstige Ruf als „digitale Opposition“ wird von Jahr zu Jahr unglaubwürdiger.

    Selbst Szene-Größen wie „Leinis“ wirken heute angepasst. Das kreative, anarchische Element, das den CCC früher ausmachte, scheint verloren.

    —

    **Fazit: Zeit für einen neuen digitalen Realismus**

    Es braucht neue Räume für echte Diskussion, für unabhängiges Denken und für digitale Selbstbestimmung. Plattformen wie Mastodon, Projekte wie Nextcloud und Akteure wie Palantir sollten nicht verklärt, sondern hinterfragt werden – mit Haltung, aber auch mit offenen Augen.

    **Carrabelloy** steht für genau das: dezentrale Freiheit, kritisches Hinterfragen, digitale Verantwortung – ohne ideologische Scheuklappen.

    —

    **Verweise und Quellen:**

    * [https://www.tagesschau.de/investigativ/ndr-wdr/polizei-palantir-datenanalyse-100.html](https://www.tagesschau.de/investigativ/ndr-wdr/polizei-palantir-datenanalyse-100.html)
    * [https://netzpolitik.org/2023/palantir-in-der-polizei-bundeslaender-im-ueberwachungsrausch/](https://netzpolitik.org/2023/palantir-in-der-polizei-bundeslaender-im-ueberwachungsrausch/)
    * [https://www.heise.de/news/Mastodon-und-der-Diskurs-Problem-7417221.html](https://www.heise.de/news/Mastodon-und-der-Diskurs-Problem-7417221.html)

    Weitere Quellen und Analysen auf meinem Blog: **[carrabelloy.wordpress.com](https://carrabelloy.wordpress.com)**